One IDE in 31 Days: What 19,599 MCP Handshakes Actually Contain

2026-10-24 · data report

Every MCP client is supposed to open with an initialize request, and that request carries an optional clientInfo block naming the client. We log that name. Over 31 days of retained gateway logs, our x402 server received 19,599 initialize handshakes from 316 distinct self-reported client names, and exactly one of them identified itself as an IDE client.

This is a report from the server side of the MCP discovery layer. It is not a criticism of any crawler — being indexed is the reason we can be found at all. It is a warning about a number that looks like adoption and is not.

1. What we measured

• Source: our own gateway's process log, [mcp] initialize clientInfo=… lines. Nothing external.
• Window: 2026-09-24 00:02 UTC → 2026-10-24 23:13 UTC (the retained log span). Older lines have rotated away, so this is a floor, not a census of all time.
• What counts: one line per initialize handshake. We do not count bare HTTP requests to /mcp as handshakes, and we do not count a session's later calls.
• What we are not publishing: IP addresses, and per-client attributions beyond aggregates. A self-reported clientInfo string is unverified and is not evidence about who operates it.

2. The numbers

The distribution is steep, and the top of it is not human. The most frequent name opened 5,564 sessions in 31 days — 179 a day, or one every eight minutes on average, and 571 of those in the last 24 hours alone. The next two names account for another 6,078 sessions between them. Together the top three are three fifths of every handshake we received.

Reading the names as a description of the tail — probes, heartbeat checks, registry crawlers, trust-score vendors, security scanners, agent directories — is an inference from strings clients chose for themselves, not a verified account of who operates them. The one part of that tail we can vouch for is our own: our first-party guard scripts account for 529 handshakes (2.7%). We subtract them and say so, rather than publish a number that quietly includes ourselves.

The single IDE handshake arrived on 2026-10-13. There were three further handshakes from a client naming itself a copilot probe. That is the entire end-user population of the MCP surface for a month.

3. Requests per handshake, and why that ratio misleads

Over the same retained window the gateway served 138,143 POST /mcp requests against 19,599 handshakes — about 7.0 requests per handshake. In the last 24 hours: 17,633 requests against 2,024 handshakes, about 8.7.

It is tempting to read 17,633 requests as seventeen thousand acts of interest. It is not, for two reasons. First, a well-behaved MCP session spends several requests before doing anything: initialize, notifications/initialized, tools/list, then one request per call. Second, many requests never handshake at all, so the ratio is an upper bound on per-session work, not a measure of it.

The number of agents that connect to your server is a measure of how many directories can reach you. It is not a measure of how many agents want what you sell.

4. The catalog tax

One measurement from the same surface is worth publishing because it is easy to get wrong. Our tools/list returns the whole catalog: 1,773 tools in a 461,152-byte response, with no nextCursor.

At a rough 4 bytes per token that is about 115k tokens for the privilege of knowing what is for sale — before a single call, on every session. The obvious fix is pagination, and the MCP spec supports it via nextCursor. But pagination mostly does not reduce that cost: the mainstream SDK client fetches pages until the cursor is exhausted, so a session still loads all 1,773 tools. Pagination buys you protection from single-response size limits and timeouts. It does not buy you a smaller context.

The only levers that actually shrink the number are catalog scope and lazily exposing tools — and hiding a tool generally makes it uncallable by a model that can only invoke declared tools. We keep the full list for that reason, and pay the tax honestly rather than hide services behind a discovery step that the model cannot act on.

5. What we changed in how we report

We have been quoting handshake and request counts in internal dashboards for weeks. After this measurement, three rules apply to our own numbers:

1. Handshakes are not agents. A registry crawler that opens a session is a distribution event, not a user event.
2. Requests are not demand. Our public stats note already says request totals are inflated by bots and self-polling; the same applies here, and the ratio of 8.7 requests per handshake is not 8.7 calls.
3. First-party probes are disclosed. Guards we run against our own server appear in the census. We subtract them and say so, rather than reporting a number that quietly includes ourselves.

6. Method and limits

Client names are self-reported, unverified, and trivially forgeable; anything could call itself anything. The window is what the process logs still hold, not a complete history, and a restart or rotation shortens it. The classification "IDE / desktop client" is our own reading of a handful of name strings, not a verified capability claim. Counts were taken at 23:13 UTC on 2026-10-24 and will drift.

What we think generalises, for anyone operating a pay-per-call MCP server: expect your handshake count to be dominated by infrastructure, expect a long tail of one-shot registry checks, and do not let either number into a growth chart unlabelled.

minia2a sells pay-per-call x402 endpoints in USDC on Base, with 5 free trial calls per signed wallet and no registration. The measurements above come from our own gateway logs; the tools/list figures were taken live from the running server on the same day.

Originally published at minia2a.uk.