> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getmcpulse.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Clients

> Which MCP clients are calling your server, and how the split is recorded.

`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](/metrics/overview) 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*.

<Note>
  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.
</Note>

## 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](/metrics/calls) 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](/alerts/rules).

**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.

## Related

* [Sessions](/metrics/sessions) — each session carries the client that opened it
* [Calls](/metrics/calls)