We Logged Every Visit to Our MCP Server for Eighteen Days

In an earlier note we read 55 live agent cards before publishing our own, and found that every directory measures reachability and nobody measures whether a card leads to work. This is the same question from the opposite side. We are the server being checked, and the log tells us who arrives, what they ask for, and whether anything happens next.

The measurement only a server can make

Consider what each party can see. A crawler visits many servers and learns whether each one answers; it cannot see who else visited, and it cannot see whether real clients ever call. A registry sees submissions, not traffic. A client platform sees its own calls to many servers. The operator of a server sees every party that connects and whether any of them used anything.

That last position is the only one from which the ratio between being watched and being used is measurable at all. What follows is one server over eighteen days, from 20 August to 7 September 2026.

What arrived

The median day is the number we would quote first. On a typical day roughly one request in 430 was somebody using something. The period figure is higher than the median because two days out of eighteen carried bursts, and a mean across days of very different sizes hides that.

The shape of a single day makes it concrete. On 8 September the server answered 485 initialize requests, completed 408 handshakes, served 438 tools/list responses, and received 32 tools/call. Connections are plentiful and cheap. What follows a connection is rare.

The monitors keep their word

This was the finding we did not expect, and it is a good-news finding.

An industry of MCP monitoring services has formed, and it is well behaved. The services identify themselves in the User-Agent, most of them carry a contact URL, and several state their purpose in plain words. Six of them were large enough to appear in our fifteen busiest clients.

Those six alone are 15,786 of 27,093 requests, which is 58 percent of everything the server answered in eighteen days, with no tool calls between them. Smaller ones sit below the cut, so the true monitoring share is higher than 58 percent.

Several go further than being identifiable. One writes liveness-only, never invokes tools into its User-Agent. Across the period, 88 separate service-days carried a declaration of that kind. On all 88, the service called nothing. Not one broke its word.

Real use is small, and very concentrated

The 302 genuine tool calls are not spread across a user base. One client, a Java 25 HTTP client, made 132 of them in a single day. That is 44 percent of three weeks of use inside 24 hours, and the day it happened is the 8.96 percent spike in our daily figures.

What remains is a thin, steady trickle from a handful of returning integrations.

The tools they reach for are the small ones: the current time, a UUID, a short link. Named agent platforms appear, Microsoft Copilot Studio among them, but as single calls rather than as traffic.

What we subtracted, and why

The first number this measurement produced was 15.57 percent. It was wrong four separate ways, and each correction is worth stating, because anyone measuring their own server will meet all four.

Our own traffic. 330 requests and 134 tool calls came from our own address. Among them, curl/7.88.1 appeared in the client listing with 113 tool calls, which would have made us the second busiest caller of our own server. The other was claude-code, a string a real Claude Desktop user would also send, so User-Agent could not separate us from a genuine client and the address could. Both sides of the ratio now drop the same traffic.

Scanners. 24 calls named a tool the server does not offer, such as one asking for __verifymcp_auth_probe_265dac185c04244f__. Those are probes testing whether the server accepts an undefined name. They belong in the connection funnel and not in a count of people using something.

One load test. On 4 September a single client made 12,872 requests and 5,734 tool calls, which is 93 percent of every tool call in nineteen days. Left in, it moved the headline from about 1 percent to 15.57 and left the median untouched. It is excluded here and named rather than quietly dropped.

One day we cannot read. On 20 August, 202 of 496 requests carried no User-Agent, because our own logger did not record it yet. That day shows 3.63 percent, the second highest of the period, and the split behind it means nothing. It stays in the totals and carries a warning.

What we are not claiming

This is one server. It says what arrives at ours, not what arrives at MCP servers in general, and the crawlers that found us did so partly because we are in a public registry, which biases who shows up.

Eighteen days is short. Three hundred and two tool calls is a small number to build percentages on, and a single busy client moves it a long way, as the Java client did.

We also cannot see intent. A monitor that never calls a tool may be exactly as valuable as it claims to be, keeping a directory honest about which servers still answer. Nothing here says the monitoring layer is waste. It says it is most of the traffic.

What would change our mind

A named agent runtime, rather than a directory, discovering servers at call time and routing real work by capability. We have not seen one. If tool calls start arriving from a framework's user agent on many days rather than from four HTTP clients, that is the signal, and we will publish it here.

The measurement continues. One record is written per day and the raw logs are kept for two years, so the same questions can be asked again with a longer window, and asked differently if these definitions turn out to be wrong.