"We did 4,000 calls yesterday" sounds like a measure of how many people use your MCP server.
It isn't, and the gap between what it sounds like and what it is turns out to be the most interesting thing about the chart.
What it actually counts
Every tool call that reached the server and was recorded, bucketed by the hour it started in UTC. A call is one tool, invoked once. That's all.
Why calls aren't people
Calls per conversation vary enormously. One user asking one question can produce one call or fifteen, depending on how many tools the model chains and how many times it has to reword and try again.
Which produces a genuinely perverse result: a server that gets better — clearer descriptions, fewer retries, fewer round trips — makes fewer calls for the same number of users. On this chart, improvement looks like decline.
If you've just rewritten an ambiguous tool description and your call count fell, that might be the fix working.
One heavy user looks like many light ones. An agent running a loop overnight can out-call every human user you have, combined.
Your own testing is in there. In the first weeks of a server, a large share of calls are its author.
The deliberate absence
The obvious response is to count users instead. We don't, and the reason is a design constraint rather than an oversight.
Nothing on the wire identifies a person. A call carries the tool name, the client name, a session ID, the timing, the outcome, the response size, and a hash of the arguments. That's the whole payload. No user ID, no IP stored against a call, no account name.
The session ID is generated by the SDK and means nothing outside your own data.
Adding a user field would make a nicer chart and a worse product. A user identifier is personal data, and MCP servers sit on email, calendars, CRM records — exactly the places where a security review stops being a short conversation.
The principle is the same one that keeps arguments out: if there's no field for it, there's nothing to leak and nothing to configure. A privacy guarantee you can switch off isn't one.
What to read instead
Sessions. Closer to a working period than a call is. Still not a person — one user opens many — but it moves with usage rather than with chattiness.
One implementation note if you're building this: count sessions from their own rows, not by grouping calls by day. A session that crosses midnight is one session, and a naive daily grouping counts it twice.
The client split. How many distinct clients connect, and what share each makes, says more about who your audience is than any total. It also tends to be the thing that actually surprises people.
Calls per tool. The total going up is less informative than which tools it's going up on. Growth concentrated in one tool is a workflow someone has found.
Read the shape, not the height
The height is ambiguous. The shape isn't:
- A cliff — calls dropping to near zero across every client at once — is an outage, a broken deploy, or a key that stopped working. Worth an alert.
- A cliff in one client only usually means that client changed something. A model, a config, how it lists your tools. Not your bug, and you'd never have attributed it correctly from a blended total.
- A step up after a directory listing, a post or a release tells you which of those actually moved anything. This is the cheapest marketing attribution you'll get.
- A weekly rhythm tells you whether people use the server for work.
The useful framing
Treat it as a pulse. It tells you the server is alive and roughly how hard it's working.
Everything else people want from it — how many users, whether they're happy, whether the tools are understood — is a different measurement, and reading it off this chart produces confident wrong answers.
The specific trap is the one at the top: a server that improves makes fewer calls. Any metric where the number going down can mean the thing is working needs a second number beside it before you act on either.
I build MCPulse — two lines inside your server, never your arguments or your results.
Originally published at getmcpulse.com.
Top comments (1)
the overnight-loop agent out-calling every human user is the scenario that breaks most mental models of server traffic. one question: does per-client session counting survive that, or does the agent just show up as one very dedicated user?