Skip to main content
client_name is read from clientInfo.name on the initialize request — claude-desktop, cursor, claude-code, or whatever the client calls itself. The overview gives each client a row of its own: calls, first-call rate, retries, the four outcomes, p95 and average response. Not a share of the total — a client is a way of reading your server, and the interesting thing about it is how well it reads.

​
How it is stored

client_name is part of the primary key of tool_hours, beside the hour and the tool. So is tool_pairs, and sessions carries it too. That is the whole design, and it replaced two tables: one counted calls by tool and forgot who called, the other counted by client and forgot which tool. Both were written from the same calls, so the information existed — it was simply in two rows that could never be re-joined, and the sharpest question this product has could not be asked. So a client filter and a tool filter compose. ?tools=search_orders&clients=cursor is one tool as read by one model. On our own sample, search_orders reads 76% first-call for claude-desktop and 22% for cursor — a 54-point gap on one tool, where the server-wide figure is a flat 64%. Under a tool filter the clients panel narrows rather than blanking, which changes what it is for: with one tool selected, those rows answer who cannot read this description.
A payload arriving without clientInfo.name is bucketed as unknown before anything is grouped, so every client’s calls sum to the call total. ?clients=unknown selects them.

​
Every client name is a button

The question after “Cursor is thirty points behind” is always “behind on what”, and that answer is the tool table with a client filter on. So clicking a client name narrows the whole page to it.

​
What it is useful for

Deciding what to optimise for. Clients differ in how they present tool descriptions, how aggressively they retry, and how much context they have to spend. A server used almost entirely from one client can be tuned for it; one split evenly cannot. Explaining a change you did not make. A first-call rate that moves without a deploy is often a client shipping a new model or a new prompt. The clients panel next to the calls per day chart is usually where that becomes visible. Scoping an alert to the client it is actually about. A rule reading first-call on search_orders, for Cursor, below 60% fires on a real 23% where a server-wide rule at 70% stays silent, because the average across every client is 81%. See Alerts. Confirming an integration landed. A new client name appearing is the clearest signal that a directory listing or a partnership is live.

​
It is what the client says it is

The name is self-reported and unverified — it is a string on a request. Capped at 128 characters on the way in, along with every other free-text field, because ingest is a public endpoint and unbounded text would end up in the metrics tables and on every dashboard reading them. A client that reports nothing usable is recorded as unknown, and its calls still count everywhere else.
  • Sessions — each session carries the client that opened it
  • Calls