The protocol, in one paragraph
The Model Context Protocol is a standard way for one program to offer tools to an AI assistant. The server publishes a list — each tool with a name, a description of what it does, and the details it needs — and the assistant picks one and fills in the blanks. The server runs it and hands back the result. That is the whole idea. It has nothing to do with training a model, and it is not a chatbot bolted onto your dashboard: the assistant is calling a specific, named thing that you decided to publish.
What makes this interesting for analytics specifically is where the friction actually sits in analytics work.
The barrier was never reading the chart
Most questions people have about their product data never get asked. Not because the answer is hard to interpret, but because getting to it means knowing which insight type applies, which event to filter on, which property key exists in this project, and what the date window should be. That is four decisions before you see anything, and each one is a chance to give up and go back to what you were doing.
An agent with tool access collapses those four decisions into one sentence. The value is not that the model is clever about your data — it is that it will actually go and look.
That is also the honest limit of it. Once a chart is in front of you, exploration is still faster by hand. The questions that benefit are the small specific ones: did that funnel move after Tuesday’s release, what has this one customer done since they upgraded, which property should I even break this down by.
What a useful analytics MCP server exposes
Finding out what exists, before asking anything
This is the tool nobody thinks to ask for, and the one that decides whether the whole thing works. Property names
are yours, not the tool’s: your events carry plan_tier and mine carry tier. An assistant
guessing a name does not get an error, it gets an empty result — and “no users matched” looks exactly like “that
property does not exist” unless it can check what is real first.
So a serious server ships tools that list the events, the property names and the values seen against them, and tells the assistant to call those before anything else. Everything downstream depends on it.
One aggregate query tool, not twenty
Trends, funnels, retention, user flows and top lists are the same question asked in different shapes, and they are better published as one tool with a setting than as twenty near-identical ones. A long tool list makes the assistant choose between options that barely differ, which is exactly when it chooses badly.
The raw event list
Totals answer “how many”. Debugging answers “what actually arrived”, and that needs the events themselves, with filters and a way to page through them. This is the one you want while adding tracking: ship the event, then ask whether it landed and what came with it.
Per-person lookup, kept separate
Looking up one person by id and reading their timeline is a different mode from asking a project-wide question, and conflating them is the most likely way for an agent to go wrong — reaching for a single-user tool to answer “how many users did X”. The tools should be named and described so the distinction is obvious, and the server’s instructions should say it outright.
The more important question: what is not a tool
A tool list is a list of permissions. Once a server publishes an action, the assistant can decide to take it, and models have no reliable sense of what “permanent” means. So what a server refuses to publish tells you more about it than what it does.
- Deletion and erasure. A GDPR erasure is permanent and unrecoverable. It should not be callable by a language model at all, however well-phrased the confirmation prompt.
- Ingest. A tool that writes events lets an agent pollute the dataset it is reading — and fabricated events are indistinguishable from real ones afterwards.
- Project and member management. Nothing about answering a question requires changing who has access.
Ask how that exclusion is enforced, too. “We didn’t add that one” is a habit somebody can break in the next release. A list of every possible tool, each either published or held back with the reason written next to it, and a server that refuses to run if the two disagree, is a guarantee.
Authentication, and the key you must not use
Most analytics products have two kinds of credential: a public key that ships in your website snippet and can only write events, and a private key for server-side use. An MCP server must use the private one, and that has consequences worth being deliberate about.
- Scope. Prefer a credential that resolves to a single project over one that spans an account. If the key picks the project, a misconfigured client cannot read a different one.
- Storage. MCP client config files are ordinary files, and they end up in dotfile repos. A private key with read access to all of a project’s analytics belongs in a secret store or an environment variable, not in a committed config.
- Sessions are the wrong shape. A dashboard login token expires and usually spans your whole account. MCP clients hold a static credential, so a server accepting session tokens is either forcing constant re-auth or granting far more scope than the task needs.
Transport: local versus remote
Servers come in two flavours. A local one is a program you install and run on your own machine. A remote one is just a URL you point your client at. Analytics is naturally remote — the data already lives on a server — which means nothing to install, but also that your client has to support remote servers in the first place. Not all of them do, so check before planning a workflow around it.
What it will not fix
An agent reading your analytics inherits every problem your analytics already has, and states them more fluently.
- A bad tracking plan produces confident nonsense. If two events mean the same thing under different names, the agent will pick one and answer from it. See designing an event schema.
- Defaults shape the answer silently. Whether the tool excludes automated traffic, how it treats cookieless identifiers, what timezone it buckets in — all of it changes the number, and none of it is visible in a sentence-shaped reply.
- Correlation still is not causation. A model asked why a metric moved will produce a plausible narrative from whatever it can query. It has no access to your release history, your ad spend or the outage last Thursday unless you tell it.
The mitigation is boring: ask the agent to state the query it ran and the window it used, and check the answer against the surface you would have used yourself the first few times.
How to evaluate one
- Are there schema-discovery tools, and do the instructions tell the agent to call them first?
- Is the surface read-only, and is erasure structurally excluded rather than merely absent?
- Does the credential scope to one project, and is it a private key rather than a session?
- Is there one aggregate query tool, or twenty overlapping ones?
- Can it browse raw events, or only aggregates? Instrumenting needs the raw stream.
- Do the tools apply the same defaults as the dashboard, so two surfaces do not disagree about the same question?
Pug’s implementation
Pug serves a read-only MCP server with twelve tools: four for schema and property discovery, one aggregate query tool covering every insight type, a raw event explorer, five for looking up and reading one person, and one that reports the status of an erasure request. Authentication is a private key that resolves to a single project, so no project id appears in the config, and public keys and dashboard sessions are both rejected.
The three withheld tools are listed in the same place as the published ones, each with the reason beside it: the two erasure tools are permanent and stay a human decision, and one unfinished insight is held back until it ships. Anything that turns up without an entry stops the server from starting at all — which is the point, because the thing being guarded against is someone forgetting.