MCP server observations, October 2026
This is the first of a monthly series. Each month we publish the same handful of numbers about the public MCP servers we observe, read from our production database on a stated date, with the definitions at the end. This issue covers 1 October to 21 October 2026, 20:00 UTC.
The list
On 21 October our list held 5,916 remote MCP endpoints. 2,284 of them were already on it on 1 October, so 3,632 were added during the month. None has opted out. Three have been claimed by their maintainers, one of them during October.
Between 1 October and 21 October, 20:00 UTC, the probe completed 159,573 runs against these endpoints. Homepage trials are not in that number: a trial run is never stored.
What the latest run found
For each endpoint we take its most recent run in the seven days before the cut-off. 5,912 endpoints had one.
| latest run | endpoints | share |
|---|---|---|
| signed, full: the server answered without credentials and every check ran | 3,566 | 60.3% |
| signed, auth-gated: the server asked for sign-in, and we signed what is observable without credentials | 1,900 | 32.1% |
| not signed | 446 | 7.5% |
Of the 446 unsigned runs, 409 did not reach a protocol revision: the server did not complete the MCP handshake, for example because it did not answer, or answered with something other than an MCP response. 35 completed the handshake but gave us no tool list we could fingerprint. 2 were unsigned for other reasons.
Signing for servers that ask for sign-in
This is the change of the month. Until 20 October, a server that answered our probe with HTTP 401 got no signed attestation at all, because most of our checks need a tool list and an anonymous client does not get one. Since 20 October, when the 401 carries a valid authentication challenge, we sign the four checks that are observable without credentials: reachability, redirect policy, transport type and authentication metadata. Every other check in that attestation is marked UNVERIFIED, with a reason, and the signed payload records that its coverage is auth-gated, so it cannot be mistaken for a full attestation.
The effect shows in the table above: 1,900 endpoints whose latest run would have been unsigned a few days ago now carry a signed attestation of what they show the public. A 403 is not yet treated this way. What a signed attestation proves describes what the signature covers.
Protocol revisions
3,603 of the latest runs completed the handshake, and the server told us which protocol revision it speaks. The other 2,309 did not: the 1,900 auth-gated servers asked for sign-in before the handshake, and the 409 above never reached it.
| revision the server declared | servers | share |
|---|---|---|
| 2025-11-25 | 1,805 | 50.1% |
| 2026-07-28 | 1,042 | 28.9% |
| 2025-06-18 | 595 | 16.5% |
| 2024-11-05 | 85 | 2.4% |
| 2025-03-26 | 75 | 2.1% |
| other | 1 | under 0.1% |
The directory can be browsed by revision, for example servers declaring 2025-11-25.
Tool lists
3,770 servers have given us a tool list at least once; those are the servers with a tool list in the directory. The median server among them exposes 7 tools in its latest list, the same as on 8 October (how many tools an MCP server exposes). 227 of them, 6.0%, have at least one tool description in their latest list that our hygiene checks flagged; tool descriptions that give orders explains what those checks look for.
Between 1 October and 21 October, 20:00 UTC, we recorded 1,487 tool-list changes on 752 servers. A change is a new tool list whose fingerprint differs from the server's previous one.
| changes in the period | servers | changes |
|---|---|---|
| 1 | 455 | 455 |
| 2 or 3 | 193 | 443 |
| 4 to 10 | 98 | 513 |
| more than 10 | 6 | 76 |
In 1,335 of the changes the new list had more tools than the previous one; in 106 it had fewer; in 46 the count stayed the same and the tools differed. The daily count of changes rose from 30 to 50 in the first days of the month to about 100 by the end of the period, while the list grew from 2,284 to 5,916 endpoints. How often MCP toolsets change looks at changes in more detail.
How we counted
All numbers come from read-only queries against our production database, run between 20:20 and 20:45 UTC on 21 October 2026. The period is 1 October 2026, 00:00 UTC, to 21 October 2026, 20:00 UTC.
- The list: remote endpoints in our target table, by the time each was added. Claimed and opted-out counts are taken at the cut-off.
- Runs: probe runs started in the period. Trial runs are not stored, so they cannot be counted.
- Latest run: for each endpoint, the most recent run that started in the seven days before the cut-off. Signed means the run has a signed attestation that is not disqualified; full and auth-gated are the coverage recorded in the signed payload. The unsigned reasons are the reasons stored with the run.
- Protocol revision: the revision the server returned in its initialize response in that latest run.
- Tool lists, median and hygiene flags: each server's most recent stored tool list, as shown in the directory at the time of the query.
- Changes: consecutive stored tool lists of the same server whose fingerprints differ. We have not separated changes caused by a server returning a different first page of a paged list, so some changes may come from paging rather than from a server adding or removing tools.
Every observation here was made without credentials. A server may show a signed-in user different tools, or behave differently from another region. The methodology page describes the probe and the checks.