Luzmo MCP: what it is for, and when to use it instead of the API or agent skills

Your users are starting to ask data questions inside tools like Claude instead of logging into your product. Luzmo built an MCP for exactly that. Here's what it does, the use cases it opens up, how authentication works, and how to choose between the MCP, the API, and our agent skills.

Two patterns keep showing up with our customers. Their users want to ask a quick data question without logging into yet another app, often from a tool like Claude Code that they already have open. And product teams are building their own agents, and they want those agents to answer data questions alongside everything else they do.

Luzmo's MCP exists for both. It's a model context protocol server, but built specifically for embedding, which makes it behave differently from most MCPs you've used. This guide covers what it is, what you can build with it, how the authentication works, and when to reach for the MCP versus our API or our agent skills.

MCP in one minute

If you already use MCP, skip ahead. A model context protocol server is a communication layer that lets an agent talk to an outside tool or API. The version most people meet first is personal: you connect Google Docs or Notion to Claude, and instead of opening the app you tell Claude to write something and save it there. That's you, as a user, reaching another product through your agent.

Luzmo's MCP points the other way.

Built for embedding

Most MCPs serve that personal use. Luzmo's is built around embedding, because that's what Luzmo does: it gets data and insights to your customers, inside your product. So the MCP assumes you are not the end user. Your users are.

That assumption shows up in two shapes. If you're building an agent for your users and want it to answer data questions, you plug Luzmo's MCP in as the data layer. If you already offer your own MCP to your users, you add Luzmo's inside it as one more capability. Either way, Luzmo's MCP is a building block in something you own, not a standalone tool your users connect to on their own.

To make that work, it carries two things a generic MCP doesn't. The first is flexible authentication. When a user logs into your platform, you can pass their exact data access, rights, and settings straight through to Luzmo's MCP, so it behaves the way that user already expects and shows only the data they're allowed to see. Your end users never handle an API key. The second is context: styling, theming, prompting, tone of voice, all set programmatically, down to the individual user or even a single conversation. Embedded inside your agent, the MCP looks and acts like part of your product rather than a bolt-on.

What you can build with it

Give your own agent data skills

A lot of teams are building an in-house agent for their product. A sales tool's agent might answer questions from a knowledge base and handle real tasks: onboard a new rep, add an account, send a welcome package. For a data-heavy product, you also want it to answer data questions, and that's the piece Luzmo's MCP supplies.

If you're building on the OpenAI Agents SDK or the Claude Agent SDK, adding it is close to one line of configuration that points the agent at Luzmo's hosted MCP. From there the agent decides, per question, whether to reach for Luzmo or another tool. In one demo, Jasper van Nistelrooy, VP Product at Luzmo, wired up three MCP servers at once, Luzmo alongside Astral and Cloudflare documentation, and let the agent route each question to the right one.

Data questions went to Luzmo; infrastructure questions went elsewhere. Adding a serious data-analysis capability to an agent you already have turns out to be a small amount of work.

Let users work with their data from the tools they already use

Inside Luzmo's demo app, Sales Compass, users get the usual embedded dashboards plus a chat powered by Luzmo IQ that answers questions like "who are my main competitors" against their own data. That works well in the product. But more and more, people don't open the product for a quick question. They ask wherever their agent already is, which is often Claude.

The MCP covers that, and an extension called an MCP app makes it genuinely good. An MCP app lets the MCP render real UI, not just text. Connect the Sales Compass MCP to the Claude desktop app, ask for sales over time, and you get a live, interactive Luzmo chart, the same chart component that runs in the product's own dashboards, drawing live data each time you open it. Because it's the same component, you can add a button that saves it straight back into a Sales Compass dashboard.

The result is a two-way flow. A user can start in your app and continue in Claude to pull in third-party data, or build something in Claude and save it back to your app. For a real customer, almost none of this is custom work. You expose Luzmo's MCP under your own brand and settings, and the live charts and data answers come with it.

Offer Luzmo IQ in a UI you control

If you already offer Luzmo IQ, the data analyst behind that Sales Compass chat, the MCP is one way to deliver it. The quickest route is Luzmo's prebuilt front-end component, but it gives you limited control beyond styling. When you want your own UI, or you want Luzmo IQ to live inside an agent you're building, the MCP exposes it as a tool, along with a few helpers: generate a chart without the written analysis, or list the available datasets so the agent knows what it can be asked. Luzmo IQ's capability is embeddable in any AI environment you like, from Claude to Cursor.

Authentication is the part that makes embedding real

The reason to use the MCP, rather than just point an agent at the API, comes down to authentication. Every Luzmo API call needs an access key and token, because the system has to know who the user is and what they're allowed to do. For a developer that's routine. For an end user inside your product, generating and juggling keys is a non-starter.

The MCP handles it through your own login. When a user connects, they see a native login screen, your login screen, and authenticate as themselves. A proxied MCP passes that identity through to Luzmo's MCP, which then scopes itself to that user with the right data access. In a demo above, Jasper connected the Sales Compass MCP, logged in as a user named Sarah, and the underlying Luzmo MCP came up already scoped to Sarah. No keys, no tokens, no asking an admin to generate credentials. It's the flow users expect from any MCP, which is exactly the point.

MCP, API, or agent skills: how to choose

This is the question that came up most, so it's worth being precise.

Luzmo is API-first. Anything you can do in the Luzmo UI, you can do through the public API, which makes it friendly to agents: point a capable agent at Luzmo's developer docs and it can often work out how to build something with no MCP at all.

If your goal is to build with Luzmo yourself, connecting datasets, adding formulas, building dashboards from a tool like Claude Code, Cursor, or Codex, the right tool is Luzmo's agent skills. Skills are guidelines: best practices and the common pitfalls Luzmo has run into, layered on top of the API so your agent works with it more reliably. They're deliberately lightweight, because they point your agent at the API and the docs rather than loading a heavy MCP into its context.

Jasper's reasoning for choosing skills over a full build-everything MCP is worth repeating. Over the past half year, agents have gotten smart enough that, with a strong API underneath, they don't need an MCP sitting in between to get the work done. Skills plus the API reach the same result with less weight. Install the skills as a Claude plugin and the MCP comes along too, so you're not giving anything up.

The MCP is for the other job: giving your users data capabilities, inside your product or in the tools they already use, with authentication and visualizations that stay consistent with your app. It earns its place when the work is embedded and customer-facing, which is precisely where pointing an agent at the raw API would fall short on auth and on visual consistency.

A rough rule. If you're building with Luzmo, reach for agent skills and the API. If you're giving your users data capabilities, reach for the MCP. And in plenty of setups you'll use both.

The fastest way to start: proxy our MCP

You don't have to build an MCP to offer one. The Sales Compass MCP in every demo above is a thin proxy of Luzmo's hosted MCP, running under the Sales Compass name with nothing changed underneath. If you'd like to give your users a data-analysis MCP but don't have an agent or an MCP of your own yet, proxying is the quick path to value. Luzmo stands up the server, and you add the one piece that has to be yours: a login page so your users can authenticate. It can be your first MVP, and it may be all you need.

Getting started with skills is similarly low-effort. Install them in your terminal with a single command that walks you through it, or hand your agent the docs link and tell it to install the skills for you. It will handle the rest. If you'd rather not touch a terminal at all, that second route means you never have to.

The recap

Your users are going to work with their data wherever they already are, more and more inside an AI tool rather than your UI, and the teams that do well treat that as a place to meet them. Luzmo's MCP is built so you can meet them there without giving up the things that make the product yours: who can see what, how it looks, and where the work lands when they're done.

Then pick the lightest tool for the job. Agent skills and the API when you're building with Luzmo, the MCP when you're embedding it for your users, and a proxied MCP when you want to put something real in front of them this week. If you want to walk through your own use case, the Luzmo developer docs cover the MCP, agent skills, and the API, and the team runs these office hours every Wednesday.