Research

Published 2026-08-22 · Basis: 9.8% systematic sample of the remote-transport corpus (1,347 of 13,708 servers)

Live data, not a re-run of this snapshot: this report is a dated analysis and is never silently updated. For current, queryable numbers behind Vouch’s scores, see the methodology.

The MCP census — August 2026 (9.8% sample)

Superseded. This is an early, partial look at the registry — a 9.8% systematic sample run on 2026-08-22. It is kept unchanged as the dated record. A full-corpus census — every remote-transport server probed, no sampling — is at The MCP census — September 2026. Where the two disagree, the September numbers are current.

The probing rules are on the probing standard. This report asks one question: how many MCP tools can actually be probed — reached, handshaken, and called read-only without credentials?

Basis: a systematic sample of 1,347 remote-transport servers (9.8% of the 13,708 that existed then), spread evenly across the whole registry rather than a prefix. The tool and server counts here are a measured sample plus a labelled extrapolation, not an exhaustive count. The full census has since been run — see the September 2026 report above.


The short answer

11,322 probeable tools measured directly in the sample — before any extrapolation. Naively scaling by sample coverage (9.8%) suggests roughly 115,000 across the full probeable universe. Either number is far more than enough to build a behavioural index on; the full census (September) puts the counted figure at 85,496.

1. The registry — a correction worth stating plainly

The registry's GET /v0.1/servers listing returns one row per published version, not one row per distinct server — confirmed by inspection (e.g. ac.inference.sh/mcp alone has four version rows: 1.0.0, 1.0.1, 2.0.0, 2.0.1). A full sync returned 79,250 raw rows. After deduplicating by a version-independent identity key, that's 29,590 distinct servers.

This matters for anyone citing "size of the registry": the raw row count overstates the distinct-server count by roughly 2.7x. Every figure below uses the deduplicated count.

2. Transport split — exact, full corpus

TransportDistinct servers%
stdio only15,88253.7%
Remote only12,28941.5%
Remote + stdio fallback1,4194.8%
Total29,590100%

53.7% of the registry is stdio-only — reachable only by executing third-party code locally, categorically out of scope until sandboxed local probing exists. The probeable universe here is the remote-transport slice: 13,708 distinct servers (46.3% of the corpus), not the full registry.

No prior public figure existed for this split. This corrects that. (The September full census puts remote transport at 55.5% — now the majority.)

3. Credential class — sampled

Coverage: 1,347 of 13,708 remote-transport servers probed (9.8%), via systematic sampling (every Kth server across the full corpus — see Method). All 29,590 distinct servers were walked through; stdio-only ones were classified instantly with no network call, and remote-transport servers outside the sample are recorded not-probed, never dropped.

ClassCountAutomatable?
A — open234Yes
B — self-provisionable (candidate)384No — needs manual review
C — gated375Mostly
Unreachable354 (26.3% of probed)
Not probed (stdio, or outside sample)28,243

Probeable (A+B): 618 servers, 11,322 tools, measured directly in the sample.

A secondary finding worth its own line: 15 servers had tools/list succeed fully unauthenticated but then hit an auth challenge on the one sample call — auth enforced inconsistently between listing and calling. Recorded as Class C (the call is what's gated), but it's the kind of declared-vs-enforced discrepancy the shallow probe battery is meant to surface. (The September census found this at scale — 691 servers.)

4. Schema quality — sampled

Of the 644 probed servers that returned at least one tool:

This is measured against servers that responded successfully; it says nothing about the unreachable or gated ones, which couldn't be checked by construction.

5. Unreachable

354 of 1,347 probed remote servers (26.3%) were unreachable — connection failures, timeouts, or 5xx after a single-attempt probe (see Method: no retries against third-party servers, by design). Over a quarter of the "remote" corpus, as sampled, is registered but not actually alive. (The September full census: 31.1%.)

6. Method

Registry sync. Full pagination via cursor/metadata.nextCursor, limit=100 per page, no updated_since filter (a from-scratch full sync). Every raw page archived before parsing.

Identity key. Package coordinates (registry type + identifier, version-independent) where available, falling back to repository URL, never the registry's own name+version row alone — the registry ID is in preview and may reset, so it is not treated as the stable identity. This is what collapses the 79,250 raw rows to 29,590 distinct servers.

Transport classification. Pure function on each registry record: remotes[] present → remote; packages[] only → stdio; both → remote with stdio fallback. No network calls — this is why the transport split is exact rather than sampled.

Credential classification. For each remote-transport server: initializetools/list, unauthenticated, no credentials of any kind sent. A 401/403 or declared auth challenge → Class C. On success, the probe looks for exactly one tool that is unambiguously read-only — a conservative name/description heuristic (safe leading verb, mutating-verb denylist, no unsynthesizable required parameters) that does not trust the self-reported readOnlyHint alone — that signal is exactly what this project distrusts. An eligible tool plus a successful sample call → Class A. tools/list open but no tool safely auto-sampleable, or an inconclusive sample call → Class B candidate, flagged for manual review, never guessed into A.

Sampling. The registry returns servers in alphabetical-by-name order (confirmed by inspection — consecutive pages cluster ac.*ad.*ag.*agency.*ai.*). A prefix sample would only ever cover early-alphabet namespaces. Systematic sampling — every Kth remote-transport server across the entire deduplicated corpus — was used instead: deterministic, reproducible, unbiased with respect to naming.

Rate limiting and prober identity. Every request carries Vouch-Census/0.1 (+mailto:probing@vouch.tools; read-only census probe; see https://vouch.tools/probing-standard) in the User-Agent from the first request. At most 4 requests in flight globally, never more than one against a single host concurrently. 429 is retried with backoff honoring Retry-After; a timeout or 5xx from a third-party server is recorded on the first attempt and not retried — at ~30,000-independent-host scale, retrying every failure was the difference between finishing in hours versus weeks. The registry itself is the one exception (a single trusted host the whole run depends on), so transient errors there are retried.

Opt-out. Checked per server before probing: a manual deny-list (the actual channel right now — email the contact in the User-Agent), /.well-known/mcp-probing.json, and robots.txt. 22 servers were opted out via robots.txt during this run and are recorded as opted out, not folded into any other bucket.

7. What this method could not determine

8. Reproducibility

The census method — the identity key, transport classification, the read-only heuristic, credential classification, systematic sampling, 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.