The MCP census — September 2026

This report covers a full census run on 30 August 2026, published 2 September. Each census report is named for the month it is published and is a dated snapshot — the registry keeps changing, and so do these numbers.

The probing rules are on the probing standard; how the behaviour scores themselves are produced is on the methodology page. This report answers the same question as the August 2026 sample — how many MCP tools can actually be probed? — but against the whole registry rather than a 9.8% slice.

Basis for this report: a full census of every distinct server in the MCP registry as of 30 August 2026 — 24,813 servers after deduplication — with every one of the 13,781 remote-transport servers probed, no sampling. The August sample's headline figures were a measured sample plus a labelled extrapolation; the figures here are a direct count. The reproducible artefact is the method plus the live corpus itself, queryable at vouch.tools and vouch.tools/api/stats.

What changed since the August sample

Three of these are worth stating plainly:

1. The distinct-server count went down while the registry grew. This is not a shrinking ecosystem — it is a better identity key. In late August the server identity key was revised to derive from package coordinates first (then repository URL, then registry name), collapsing servers that the earlier name-based key had double-counted — one server published under two registry entries, or under a package and a bare repo listing. The registry itself added rows over this period. Because the two runs use different identity-key derivations, absolute-count deltas between this report and the August sample are directional, not exact like-for-like. Within-run proportions are unaffected.

2. Remote transport is now the majority. The August sample put the corpus at 53.7% stdio-only and 46.3% remote-reachable. The full corpus is 44.5% stdio-only and 55.5% remote-reachable. Some of that shift is the identity-key change (it merged more stdio-heavy namespaces), but the direction is consistent with what the registry looks like quarter over quarter: new MCP servers increasingly ship a hosted endpoint rather than a npx command. No prior public figure tracked this over time.

3. The real probeable number is below the naive extrapolation. Scaling the sample by coverage suggested ~115,000 probeable tools. The counted figure is 85,496. The gap is two deliberately conservative choices: a read-only heuristic that is a lower bound by design, and an unreachable rate that came in higher at full scale (31.1% vs 26.3%).

1. The corpus

24,813 distinct servers, deduplicated by a version-independent identity key. The registry's GET /v0.1/servers listing still returns one row per published version, not per server; the ~2.7× overstatement the August sample documented has not gone away, and every figure below is against the deduplicated count.

The live corpus tracked on vouch.tools carries 24,719 servers and 119,771 tools as of 2 September 2026, with 1,500 servers marked delisted (their identity key fell out of the registry since it was last seen — retained and flagged, never deleted). The tool count is higher than this census's 108,416 because tool records are kept when a server drops a listing between sweeps rather than deleted; reconciling that is a known, tracked gap.

2. Transport split — exact, full corpus

Transport is a pure function of the registry record — no network call — so this split is exact, not sampled. 55.5% of the corpus is now remote-reachable (12,495 + 1,286), up from 46.3% in the August sample. stdio-only servers remain out of scope until sandboxed local probing exists.

3. Credential class — full, not sampled

Every one of the 13,781 remote-transport servers was walked. 359 were opted out (via robots.txt or the manual deny-list) and are recorded as opted out, never folded into another bucket. The remaining 13,422 were probed — initialize → tools/list, unauthenticated, with no credentials of any kind sent:

Probeable (A+B): 5,326 servers, 85,496 tools — measured directly, no extrapolation. That is the answer to the question this census exists to ask.

Class B came in at 3,440 candidates, close to the August extrapolation of ~3,900. Each needs a human to look at the evidence bundle before it becomes a final classification; the queue is a visible, non-blocking backlog, not a gate.

The declared-vs-enforced gap, now at scale. 691 Class C servers returned a full tools/list with no authentication and then gated the sample call — 22,920 tools listed by servers that will not let you call them anonymously. Auth enforced inconsistently between listing and calling is exactly the kind of discrepancy the shallow probe battery exists to surface.

4. Schema quality — full corpus

Across the 108,416 tools returned by the 6,011 servers that listed at least one:

• 100% declared well-formed input schemas (type: object with a valid properties shape). Unchanged from the sample — this is not where MCP tools are sloppy.
• 20.1% of tools declare an outputSchema (31.8% of servers declare at least one). The August sample put the server figure at 35.7%; at full scale it is a little lower. Still a meaningful minority, still well short of "most."
• 59.4% of tools declare a readOnlyHint annotation. Vouch records this and does not trust it — a self-reported "I don't have side effects" flag is precisely the signal this project was built to distrust. That nearly 60% of tools now set it is a measure of how load-bearing the annotation has become, and of how much manual side-effect classification a full behavioural corpus still requires.

5. Unreachable

4,180 of 13,422 probed remote servers (31.1%) were unreachable — connection failures, timeouts, or 5xx after a single-attempt probe (no retries against third-party servers, by design). Nearly a third of the registered remote MCP corpus is listed but not answering. The sample put this at 26.3%; the full corpus is worse, which is the direction sampling bias would predict (a systematic sample slightly over-weights the servers that respond fast enough to be classified cleanly).

6. Method — what is the same, what changed

Same as the August sample: registry sync via full cursor pagination with every raw page archived; transport classification as a pure function; credential classification by unauthenticated initialize → tools/list with a conservative read-only heuristic that does not trust readOnlyHint; a global concurrency ceiling of 4 with never more than one request in flight per host; 429 retried with Retry-After backoff, first-attempt-only for third-party timeouts and 5xx; opt-out checked per server before probing.

Changed since the sample:

• No sampling. Every remote-transport server was probed.
• The identity key derives from package coordinates first, then repository URL, then registry name. This is why the distinct-server count is not directly comparable to the August sample's.
• The registry client requests version=latest. The August sample, collected before this fix, classified whichever version row it encountered first — in practice the oldest. This run classifies the current published version.
• Parallelised per-server (same per-host ceiling), cutting wall-clock roughly 3.3×.
• Contact address. Every request carries Vouch-Census/0.1 (+mailto:probing@vouch.tools; read-only census probe; see https://vouch.tools/probing-standard).

7. What this method still could not determine

• Credential class for stdio-only servers. 44.5% of the corpus cannot be handshaken without executing third-party code — the job of sandboxed local probing.
• Class B resolution. 3,440 candidates is a count of servers that need a human to look at the evidence bundle, not a final classification into A or C.
• Deep behaviour for most of the probeable universe. 85,496 tools are reachable for probing. The published deep-behaviour corpus is far smaller — the census says what can be measured, not what has been.
• No published, stable IP range. The probing standard calls for probing from a published range; this run was invoked from local infrastructure. A real gap before recurring probing.
• The read-only heuristic is still a deliberate lower bound. Genuinely read-only tools whose names do not lead with a safe verb fall into Class B, not A. Class A is a measured floor, not a precise count.

8. Reproducibility

The census method — the identity key, transport classification, the read-only heuristic, credential classification, the rate-limiter policy — is described above and its decision functions are individually unit-tested. Re-running against the live registry will not reproduce byte-identical output — the registry changes continuously — but reproduces the method, which is the thing that has to hold up. The raw per-server output of this run is not published as a file; the reproducible artefact is the method plus the live corpus, which is the census result and is queryable at vouch.tools.