Measuring MCP Server Adoption: Analytics With No Sessions

Your product may be about to grow a surface you have never had to measure. The Model Context Protocol — the open standard that lets AI agents call your tools and APIs without ever touching your UI — has gone from a curiosity to something enterprise software is expected to ship. By one 2026 account MCP had "crossed 97 million monthly SDK downloads" with "10,000+ active servers," and Forrester predicts "30% of enterprise app vendors ship their own server this year" (Advisable). If you are in that 30%, you now have a product surface with no page views, no sessions, and no funnel — and your entire analytics stack was built to measure exactly those things.

This is not the problem of exposing your analytics to an agent, which is the MCP-as-a-query-interface angle, and it is not the problem of agents polluting your existing human metrics, which is the agents-as-users blind spot. It is the inverse: the tool-call surface you shipped is the product, and you have to define events, activation, and retention for it from scratch. This post lays out what to log, how to define an active user when the actor is software, what activation means with no onboarding screens, and how to keep agent data separable from human usage.

Why your existing analytics does not fit

Start by naming what breaks, because it is more than a cosmetic difference. Product analytics as most SaaS teams practice it is built on three primitives — the page view, the session, and the funnel — and an MCP server produces none of them. An agent connects over the protocol, authenticates with a credential, and calls tools; there is no screen to render, no session to open and close, and no click path to trace. Every session-based retention metric, every pageview-per-visit number, and every funnel-completion rate you rely on is undefined here. The atomic unit of behavior is the tool call, and if your instrumentation cannot represent an invocation as a first-class event, it cannot measure this surface at all.

The second break is the actor. On your UI the actor is a human, and your DAU, conversion, and engagement numbers quietly assume that. On the MCP surface the actor is an agent acting on behalf of a human or an account, and one account may drive thousands of calls from several client applications with no human watching in real time. That distinction between the immediate actor and the entity that carries value is the same one that already forces B2B teams into account-level versus user-level analytics, except now the user-level actor is not even a person. Measure the surface without resolving that, and your adoption numbers count processes instead of customers.

What to log: the tool-call event schema

The good news is that everything you need is observable at the call boundary, and the vendors building MCP observability already converge on the same fields. Practitioner guidance is consistent: track "call volumes, success and failure rates, tool usage, active users, client distribution" from the invocation stream (Embeddable). Concretely, every tool-call event should carry the tool name, the calling client or host application, a caller identity that resolves to one of your accounts or API keys, a success/error outcome with an error type, latency, the arguments' shape or size where safe to record, and a timestamp. That is the MCP analogue of a well-formed product event, and it is governed by the same discipline as any other stream — it needs a real tracking plan and event taxonomy, not ad-hoc log lines.

Design the schema around invocations rather than navigation, and one property earns its place above all others: the caller identity. A tool call is worthless for product analysis if you cannot say which account it belonged to, because without that you can count volume but not adoption, retention, or value. Tag each event with the authenticated account or key, the specific tool invoked, and the host client so you can answer both "which of my tools get used" and "which clients and accounts drive that usage." Ranking tool calls by volume tells you which capabilities to deepen next — it is product analytics for a surface you cannot watch users navigate, so the telemetry has to carry the context the missing UI would otherwise have given you.

Defining an active user when the actor is an agent

Report adoption in accounts, not agents. The temptation is to count distinct agent processes or connections because they are what your logs see first, but that number tracks infrastructure, not customers — a single account can spawn many agents, and a burst of retries can look like a spike in "users." The defensible definition of an active user for a shipped MCP server is the authenticated account or API key that made at least one successful tool call in the period. Compute that daily, weekly, and monthly the way you would any DAU/WAU/MAU stickiness ratio, and you get an adoption curve that means something to the business rather than to your ops dashboard.

Keep the agent-level count too, but label it as what it is: an operational metric about load and client mix, not a growth metric. The cleanest reporting separates three layers — accounts (the unit of value), agents or connections (the unit of load), and tool calls (the unit of work) — and never conflates them in a single "users" number. Insist on the successful-call qualifier as well, because an agent that connects, lists your tools, and then errors on every real invocation is not an active user by any honest definition. That qualifier is what stops connection noise from inflating adoption the same way bot traffic inflates web metrics.

Activation and retention for a surface with no onboarding

Activation still exists here; it just has no screens. The signup equivalent for an MCP surface is the connection-and-authorization step, and the first-value equivalent is the first successful, non-trivial tool call — an agent completing a real task through your server, not merely enumerating the tools it could call. Define that success event explicitly and measure the time from connection to first successful call. Accounts that connect and never complete a useful invocation are un-activated, and they are exactly as much a leak as a human who signs up and never reaches first value. This lets you carry your existing time-to-first-value discipline onto a surface that has no onboarding funnel to instrument.

Retention is where the account-based definition pays off. Because there are no sessions, forget session-based retention entirely and measure it as returning tool-call activity per account across N-day windows: of the accounts that made a successful call this week, how many make one next week. That is a clean, computable retention curve for the surface, and it answers the question that actually matters — whether the agents wired to your server keep doing useful work or connect once and go quiet. Pair the activation rate (connected accounts that reach first successful call) with this retention curve and you have the two numbers that tell you whether a shipped MCP server is a real product surface or a checkbox feature nobody keeps using.

Keep agent data separable from human usage

Send MCP telemetry into the same warehouse or product-analytics tool as your UI events — one place to analyze usage is a feature, not a bug — but tag every event with its origin so the populations never silently merge. The recommended pattern from teams already doing this is blunt: "tag queries by origin (UI / API / MCP) to answer 'how much of our query volume is AI-driven now' and price accordingly" (Tinybird). Add that origin property to your tracking plan as a required field, and where you can infer it, an agent-versus-human flag as well. Without the tag, your conversion and engagement rates drift as agent traffic grows and you cannot untangle it after the fact.

This is the mirror image of the pollution problem: rather than agents contaminating human dashboards, you want the option to look at either population cleanly and at the blend deliberately. The same separation also feeds the commercial question, because an MCP surface is a new cost and usage center much like an embedded AI feature — you will eventually want to know which accounts drive agent volume, what it costs to serve, and whether that usage correlates with expansion or with support load. Get the origin tag and the account resolution right on day one and every one of those questions becomes a query. Skip them, and you will be re-instrumenting a surface you cannot see, after the numbers already stopped making sense.

A starting checklist

If you are shipping an MCP server this quarter, instrument it before the traffic arrives, not after. Log every tool call as a first-class event with tool name, caller account, host client, outcome, and latency. Define your active-user metric as accounts with a successful call, not agent connections. Name an explicit first-successful-call activation event and measure time-to-first-value from the connection step. Compute retention as returning account activity across N-day windows rather than anything session-based. And tag every event with a UI/API/MCP origin so agent usage stays separable from human usage in the same analytics tool.

None of this requires a new category of tooling — it requires treating the tool-call stream as product data and applying the instrumentation discipline you already use elsewhere to a surface whose defining trait is that no human ever sees it. The vendors selling MCP dashboards will give you call volume and error rates out of the box, which is the operational half. The product half — activation, retention, adoption per account — is the half that tells you whether the surface is worth deepening, and it is yours to define. Do it while the schema is still small, the same way a good tracking plan is cheapest to enforce before the events start flowing.