We Run a Public MCP Server: 67 Days of Who Calls It, and How

We run a public MCP server, and for 67 days we have been counting who uses it. Between 26 August and 1 November 2026, AI assistants asked it for scans 375 times, which is 10.1% of the 3,723 scans AIScan ran. The people who call it are mostly a single kind of client: Claude acting on behalf of a signed-in person, 387 of the 388 requests we could attribute to a named AI user agent.

This is a first-party case study. Every figure comes from AIScan's own database, read on 1 November 2026. It describes people who chose to scan a site with AIScan, not the web, and it is not a market share claim.

Quick summary

Direct answer: If you are deciding whether to ship an MCP server, our numbers say the audience is real but small and steady, and the most useful thing you can log is the HTTP status of the first request. On our server, 52 of the 53 Claude requests to the authenticated endpoint since 11 October were answered 401, and that is the normal first step of an OAuth sign-in, not a failure. Count it separately or you will misread your own traffic.

Best for: anyone running, building or planning an MCP server who wants real usage numbers from a small product, and anyone wondering what an agent's first request looks like in a log.

If you want to know whether your own site exposes an MCP server card and tool list in a way agents can find, run the scan first: npx aiscan-cli yoursite.com, or paste the address at aiscan.site. It is free and needs no account. Look at P2 and P4 in the capabilities group. AIScan cannot see who calls your server or how often. That needs your own logs, which is most of what this article is about.

What we measured, and what each surface means

AIScan accepts a scan from six places. The developer guide describes them, and the wording below follows it.

The table comes from scan_request_stats, which holds one row per scan request with the surface, outcome, device type, scope and whether the result was served from the five-minute cache. It has 3,723 rows, the first dated 26 August and the last 1 November. The second source is ai_crawler_hits, our log of requests from known AI user agents, filtered to two paths: /mcp and /api/mcp. The developer guide says /mcp is the authenticated endpoint (OAuth 2.1 with dynamic client registration) and /api/mcp is the legacy endpoint that accepts a bearer key and lets anonymous callers use the read-only scan tools.

Three limits matter before any number is read.

1. The api surface is a mix. It includes CI gates, scripts and other programs. We do not know which of them are agents, and we do not guess. That is why this article never adds api and mcp together and calls the total "agent traffic".
2. Only some clients identify themselves. Claude-User sends a user agent, so we can name it. Most other MCP clients send none, so they appear in scan_request_stats under mcp but not in the crawler log. The two sources count different things.
3. A tool call is not always a scan. A client that asks for the tool list, or reads a rubric guide, leaves a request in the crawler log and no row in the scan table. The 375 is completed scans, not conversations.

No country, user or email is published. The mcp rows carry no country at all, which is a gap in our own instrumentation and is covered in the lessons section.

How the mix shifted month by month

The three months are not equal. August starts on the 26th for scan data, and November holds one scan.

Two things stand out.

The web form lost its lead. In the first week and a half, the web form was the largest surface at 46.7%. By October it was 16.6%, and the REST API carried 70.2%. Most of that shift is volume on api, which went from 178 scans in the opening stretch to 1,105 in October. The web count also fell in October, from 534 to 261, so this is not only a denominator effect.

MCP held its place while everything around it grew. Its share dipped from 13.9% to 8.3% in September as api took off, then recovered to 10.8%. In absolute terms it ran 65, 139 and 170 scans. That is the shape of a feature with a small, loyal group of users rather than one riding a launch spike.

The error column answers a question builders ask. Of 28 errors in the whole period, 23 were on api, 4 on web and 1 on telegram. The MCP surface recorded none. We do not read that as proof that MCP is more reliable. We have not tested why. One plausible reason is input quality: a scan that fails for a malformed URL is an input problem, and a surface that takes raw script input can show more of them. The error_kind column would settle it and we have not grouped it here.

Who calls the server: Claude-User, almost alone

The crawler log holds 388 requests to the two MCP paths. 387 are from Claude-User. One is from OAI-SearchBot, a single request to /mcp in October that was answered 401.

Claude-User is the user agent Anthropic says it uses when individuals ask Claude questions and it accesses websites on their behalf, as opposed to bulk crawling. It matches the pattern in our earlier piece on crawler traffic: assistants act on a user's behalf, one request at a time. If you want the broader picture of which AI user agents reach a site, the AI crawler user agent list covers it.

Across both paths and the whole period, the 387 requests come from 48 distinct hashed addresses. The hash is not an identity. One person on a changing mobile address can appear several times, and several people behind one corporate gateway can appear as one. Read 48 as "a few dozen sources", not "48 people".

The count of distinct addresses on /api/mcp rose each month, 15 then 20 then 31, while requests rose more slowly, 42 then 58 then 85. More sources each making a similar number of calls looks like a slowly widening audience, not a few heavy users.

The 401 is the handshake, not the failure

This is the part of the data most worth knowing before you build your own dashboard.

Until 11 October, every Claude-User request we logged on /mcp was answered 200. The first 401 we logged came on 11 October at 08:49 UTC, and since then Claude-User has made 53 requests to /mcp: 52 were answered 401 and 1 was answered 200. Over the same stretch, /api/mcp kept answering 200 on every request.

A reader's first reaction is that 98% of requests to the authenticated endpoint failed. That reading is wrong, and the MCP specification explains why. Under the authorization section of the MCP specification, a protected server answers an unauthenticated request with 401 and points the client at its authorization server, and the client then runs the OAuth flow. The 401 is how a client learns where to sign in. The metadata document that makes this discoverable is defined in RFC 9728.

So the question is whether the sign-in then finished. We can answer part of it.

• 13 of the addresses that received a 401 also received a 200 from /mcp at some point. Because the 200s come before 11 October, that overlap shows the same sources used the endpoint before and after it was gated. It is not evidence that they signed in afterwards.
• MCP scans did not collapse after the gate. From 26 August to 10 October, 268 scans ran through mcp, about 5.8 a day over 46 days. From 11 October to 1 November, 107 ran, about 4.9 a day over 22 days. That is a fall of roughly 16% in the daily rate, a small number to attribute to any single cause.
• We cannot see the sign-in itself. Our crawler log records the first request. Whether an authenticated follow-up lands under the mcp surface in the scan table, under /api/mcp, or in neither depends on the client. That is a hole in what we log, and no number in this article closes it.

The practical lesson for anyone shipping a protected server: log the 401 as its own event and give the sign-in a completion event. If you only count 200s you will think the gate cost you nearly all your traffic. If you only count requests you will think the gate is invisible. The honest picture needs the funnel from first request to a completed tool call, and we do not yet have it.

Does gating the endpoint cost you users?

The data allows a cautious answer and no more.

The scan rate dipped and the request rate did not move. Requests alone cannot show a blocked sign-in, because a client that fails to sign in still sends its first request, but scans would fall sharply if most people were blocked. They did not. A modest dip is consistent with a few people giving up at the sign-in screen, and we cannot separate that from the ordinary day-to-day variation in a series this small. At five scans a day, a single quiet weekend moves the average.

What we can say is narrower and more useful. Putting OAuth in front of a read-only scanner did not stop the people who wanted to use it. If your tools write data or spend money, you need the gate anyway. If they only read public information, the legacy bearer or anonymous path is a lower-friction option, and it is the one that still carries most Claude-User requests in our log.

What this means if you are deciding whether to ship a server

Four points follow from the numbers, and none of them is a forecast.

1. Expect a small audience that grows slowly. Our server serves a few dozen sources and about five scans a day. A server for a narrower tool will see less. Do not judge success against web analytics.
2. Most of your calls will not be scans. Listing tools and reading guidance leave requests and no outcomes. Build the log around requests first.
3. The agent is acting for a person. A named user agent such as Claude-User means a human asked a question and the assistant came to your server to answer it. That is closer to a referral than a crawl.
4. Publish a card so agents can find the server at all. Our guide to publishing an MCP server card covers the file. AIScan grades whether it exists and whether the tool list is reachable under P2 and P4 in the capabilities checks.

What to log from day one

This is the short list we wish we had on 26 August.

Two of those gaps are ours to fix, and we will not make up the missing numbers in the meantime. If you are starting a server today, the guide to checking an agent-readiness audit from the terminal shows how to wire the same scan into your own checks, and the CI gate for GitHub Actions shows the pattern for failing a build on a regression.

Method, dates and limits

• Source: AIScan production database. scan_request_stats (3,723 rows, 26 Aug to 1 Nov 2026) and ai_crawler_hits filtered to /mcp and /api/mcp (388 rows, 25 Aug to 1 Nov 2026).
• Queries: counts grouped by month, surface and outcome; counts of requests, status codes and distinct hashed addresses by path and user agent. Read on 1 November 2026.
• Exclusions: the table does not hold a column that identifies our own test scans, so none were removed. Our own tests would raise the mcp count if they used that surface.
• Population: people and programs that chose to scan a site with AIScan. It says nothing about how the wider web uses MCP.
• Not published: any user, email, plan, revenue figure or country below 30 requests.
• Known gaps: no country on mcp rows, no record of OAuth completion, and no way to tell which api callers are agents.

Next step

Run npx aiscan-cli yoursite.com or paste your address at aiscan.site, then read P2 (an MCP server card and tool list that agents can find) and P4 in the report. The capabilities check page explains each result and the fix. If a scan says your server is discoverable, your own logs are the only place that will show whether anyone then calls it. The full set of walkthroughs is in the AIScan guides.

If you want the same view of your own server, the how-to is Log the requests to your MCP server: which fields to record, and why tool failures show up as HTTP 200.

To try the same server yourself, connect it to Claude and run a scan from a chat.