Calls per day does not tell you who your users are
The first chart everyone reads, and the easiest to over-read. It counts calls, not people — and by design nothing in MCPulse counts people.
Calls per day is the first chart on the overview, and it is the one people quote. “We did 4,000 calls yesterday” sounds like a measure of how many people use the server.
It is not, and it is worth being exact about what it is.
What it counts
Every tool call that reached your server and was recorded, bucketed by the hour it started in UTC. Ask for a single day and you get the hours. Ask for a range and you get the days. A period with no calls is drawn flat at zero, never left blank, because a gap and a zero are different facts.
That is all. A call is one tool, invoked once.
Why calls are not 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 retry. A server that gets better — fewer retries, fewer round trips — makes fewer calls for the same number of users. On this chart, improvement can look like decline.
One heavy user looks like many light ones. An agent running a loop overnight can produce more calls than every human user put together.
Your own testing is in there. In the first weeks of a server, a large share of calls are its author.
Why we do not count people instead
Because nothing on the wire identifies one, and that is on purpose.
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 is the whole payload. There is no user ID, no IP address stored against a call, no account name from your side. 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 it would turn every security review from a short conversation into a long one. The design choice is the same one that keeps arguments out: if there is no field for it, there is nothing to leak, and nothing to configure.
What to read instead
If the question is how much your server is used, these are closer:
Sessions. A session is closer to a working period than a call is, and it is counted from its own rows, so one that crosses midnight counts once. It is still not a person — one user can open many — but it moves with usage rather than with chattiness.
The client split. How many distinct clients connect, and what share of calls each one makes, says more about who your audience is than any total.
Calls per tool. The total going up is less informative than which tools it is going up on. Growth concentrated in one tool is a workflow people have found.
What the shape is good for
Read the shape, not the height:
- A cliff — calls dropping to near zero across every client at once — is an outage, a broken deploy, or a key that stopped working. That is worth an alert.
- A cliff in one client only usually means that client changed something: a model, a config, how it lists your tools.
- A step up after a directory listing, a post or a release tells you which of those actually moved anything.
- A weekly rhythm tells you whether people use the server for work.
The chart is a pulse. It tells you the server is alive and roughly how hard it is working. Who is doing the work was never something it could say.