An MCP server is only as good as what sits behind it.

Every analytics platform is shipping an MCP server right now, and we are already seeing it as a line item on RFPs, the way "has an API" was a decade ago. That is genuinely good, because it means your AI agents can finally reach your analytics directly instead of through some brittle export.

But the checkbox is close to meaningless on its own. An MCP server is just a doorway. What actually matters is what your agent finds when it walks through, and there the products all converging on the same three letters are wildly different underneath. Two vendors can both say "we support MCP" and hand your agent completely different levels of capability. The acronym tells you a door exists. It tells you nothing about the room.

Other MCP servers could be a wrapper on an API built years ago.

Here is the fastest way to ship an MCP server, and the reason so many of them look alike. Take the API you already built, the one your developers have leaned on for years, and wrap its endpoints as MCP tools. A few days of work and you can put out a press release about agent support. It demos beautifully.

The catch is what that API was built for, and when. Most analytics APIs were designed a long time ago to do a narrow job: let a developer pull a known report, grab a predefined metric, push a fixed object into some other system. They hand you a menu of endpoints, each one answering a question somebody already thought to ask. Wrap that in MCP and your agent inherits every limit baked in years ago. It can call the endpoints that exist, and when you ask it something with no endpoint behind it, a metric nobody created, a segment that does not exist yet, it just stalls. The protocol is new. The ceiling is a decade old.

We have a name for a system that can only return what someone pre-built. It is a fetcher, and it is the whole subject of Is your AI analyst actually a fetcher. Wrapping a legacy API in MCP produces a very polite fetcher that happens to speak the latest protocol. The rest of this post is about why we refused to build that, and what it took not to.

We had no legacy API to inherit limits from.

We never built a public analytics API for developers to pull reports from. And that’s not a positioning choice, it’s just how our history played out. So when it came time to build an MCP server, there was nothing old to wrap, and no shortcut to be tempted by.

To be clear, everything has an API layer underneath, ours included. The point is that ours was built for this, at the same time, for agents, instead of inherited from a decade ago and repurposed. We got to design backward from one question: what does an agent need in front of it to reason like an analyst. Then we pointed it at the richest thing we have, the full experience data Quantum Metric captures.

Most of what follows is what we are seeing inside private customer partnerships, not a generally available launch. Teams are wiring this up now, and it is early, but the shape of it is clear.

In practice it comes down to three things a wrapped API cannot give an agent, no matter how many endpoints you bolt on.

The first is composition over the actual model, not a report about it. An agent connected through our server can compose arbitrary queries across the full event and metric-definition model, and drill down to the session level and into replay, so it can answer a question when the metric it needs has never been created. This is not row-level SQL against a warehouse. It is free composition over the structured experience model, which is both more useful to an agent and much harder to hit a wall with than a fixed set of reports.

The second is discovery. The agent can explore that model and find what actually exists rather than needing the exact metric name handed to it up front. There are catalog and concept tools built specifically so an agent can find what is there on its own. A wrapped API assumes you already know what to ask for, and an agent that has to be told the name of everything before it can use anything is not much of an analyst.

The third is a path to the work Felix does, not just the data it works with. Today, an agent connected through our server uses the same tools Felix does, and it can kick off the monitoring agents and workflows a team has set up in Quantum Metric. Where this is heading is more interesting. With a small group of customers, Felix now runs investigations on its own schedule, on our side, and hands the findings straight to their agents over MCP. One example: watching session replays for each error segment, separating the users who were truly blocked from the ones who re-entered a card and carried on, and pricing what the real failures cost. Your agent doesn’t have to know where to look. It starts from what Felix already found.

Put those together and a customer’s own agent, connected through our MCP server, works with the same tools and experience data Felix uses. That is a different thing entirely from a thin pipe to last quarter's reports.

Why this is the whole ballgame for agents.

Here is why it matters more for MCP than almost anywhere else. The entire reason you connect an agent to your analytics is to ask the questions you did not script ahead of time. If you already knew every question, you would have built the dashboard and moved on. You reach for an agent for the messy, unplanned ones, the "why did this one segment fall off a cliff after Tuesday's release" that no report was ever going to have waiting.

That is exactly where a wrapped API gives out, because the unplanned question is the one with no endpoint behind it. An agent-native server is built for that moment instead of tripping over it. And you will not catch the difference in a demo, where every question is quietly chosen to line up with an endpoint that already exists. You catch it three weeks in, the first time somebody asks the thing nobody planned for.

This is also what we are hearing from customers, and it is the part I did not expect. Plenty of teams have already wired an agent into their stack, into Splunk and Dynatrace, into Jira, into their logs and their source control. The agent can see what the system did in exhaustive detail. What it cannot see is what happened to the actual user, the friction, the struggle, the moment someone gave up. That is the missing input they keep coming back for, and it happens to be the one thing our data is made of. The thesis of this whole post shows up on its own, from the buyer's side, before we ever pitch it.

The questions to ask any analytics MCP.

The checkbox tells you nothing, so when a vendor says they support MCP, ask what is actually behind the door. Two questions cut fastest, because they are the ones a wrapped API cannot fake.

Can the agent query the raw underlying data and discover what exists on its own, or does it only pull predefined metrics it already knows the names of? Bring a genuinely novel question to the evaluation, one no one would have built an endpoint for, and watch whether the agent investigates or freezes. That single test tells you which side of this line the server is on.

And does your agent only get data back, or can it get the platform’s own analysis too? Findings from investigations that are already running are a real step up from a read-only feed, and a data pipe can never grow into that.

Any vendor will happily say yes to "do you support MCP." These are how you find out what that yes is worth.

The honest part.

Handing an agent this much analytical power raises the stakes on getting it right, and it would be dishonest to skip past that. An agent that can build any query can build a wrong one just as easily, which is why the foundation underneath matters as much as the access. Ours sits on first-party experience data captured in real time, and the work an agent does through it is grounded in that data and visible, so you can see the queries it ran and the data it used rather than taking the answer on faith. Give an agent raw power without that grounding and you have just built a faster way to be confidently wrong. The value is not only that the agent can do more. It is that you can see what it did.

What it comes down to.

The MCP server anyone can stand up in a weekend is the one wrapped around an API built for a different era and a different user. It works, it demos well, and it quietly saddles your agent with the same ceiling your integrations have had for years.

The one worth having is built for the thing actually using it. When your agent walks through the door, it either finds a short menu of yesterday's reports or the raw material and the tools to answer whatever you think to ask next. That gap is the difference between checking a box and giving your agent something real to work with.

See what an agent can do when it is built on rich experience data instead of a legacy API: explore Felix AI Agentic.