The 30-server number is a pagination artifact
A bare GET /v0/servers returns exactly 30 entries and a metadata.nextCursor. Miss the cursor and you conclude the official registry is nearly empty, which is the comparison a lot of write-ups have been making against Glama’s tens of thousands. I made that mistake myself in a piece two weeks ago and am correcting it here.
Paged to exhaustion on 2026-08-29 the same endpoint returns 2,500 version records covering 759 unique servers. I cannot tell you how fast that grew, because I do not have a trustworthy earlier count to compare against, and neither does anyone else who stopped at page one. What I can tell you is what is in it today.
# every page of the official registry, 2026-08-29 curl -s "https://registry.modelcontextprotocol.io/v0/servers?limit=100" # followed metadata.nextCursor to exhaustion: 25 pages, 2,500 version records # deduplicated by server name, keeping the latest version: 759 unique servers
The numbers
| Metric | Count | Note |
|---|---|---|
| Unique servers | 759 | 2,500 version records before dedupe |
| Expose a hosted remote | 637 (83%) | 633 streamable-http, 20 SSE |
| Ship an installable package | 164 (21%) | 136 npm, 24 PyPI, 10 OCI, 2 MCPB |
| Both remote and package | 46 | Run it yourself or use theirs |
| No public repository | 374 (49%) | Nothing to read before you trust it |
| Hosted remote, no repository | 359 of 637 (56%) | The number that matters |
Point-in-time snapshot, 2026-08-29. Re-run it and the counts will have moved, probably up.
MCP is now a remote protocol, not a local one
83% of registered servers expose a hosted remote endpoint, and 633 of those speak streamable-http. Only 21% ship a package you can install and run yourself. The mental model most teams still carry, a local stdio process reading a config file on their own machine, now describes a minority of the ecosystem.
That flips the threat model. A local server is a supply-chain question: what did I install, what can it read. A remote server is a third-party-processor question: whose infrastructure is my agent talking to, what does it retain, what happens to my token when their logs get breached. Same protocol, completely different review.
The 56%
Of the 637 servers exposing a hosted remote, 359 list no public repository. You point an agent holding your credentials at their endpoint, and there is no source to read first. Not a vulnerability, and not an accusation about any specific operator. It is an accountability gap, and it sits under more than half of the hosted ecosystem.
For a local package you can at least read the code before running it. For a closed remote you are extending trust on the strength of a description field. That is a normal thing to do with a vendor you have a contract with. It is a strange thing to do with an entry in a public directory you found this afternoon.
What the registry gets right
Worth stating plainly, because the interesting finding here was a negative one. I checked every manifest for the two failures I expected to find and found neither.
- Zero servers declare a plaintext
http://remote. All 653 declared endpoints are https. - 119 environment variables have names that look like credentials. Every one of them is flagged
isSecret. Not one leaks a value into the manifest. - 160 of 172 declared package versions are exact-pinned.
The registry schema is doing real work. I went looking for embarrassing findings to publish and the hygiene held up, which is more than I can say for most package ecosystems at this size. The gap is not in what the registry validates. It is in what it cannot validate: whether the thing on the other end of that https URL deserves your token.
The stragglers
20 servers still declare the deprecated SSE transport, superseded by streamable-http. 16 declare two or more remote endpoints, which doubles the surface a reviewer has to reason about and is worth a second look when one of them is a staging host nobody meant to publish.
What to actually do about it
None of this needs a consultant to check. Point the free scanner at your own configs and read the output:
npx mcp-scan@latest
No install, no account, no telemetry. It reads the AI tool configs already on your machine and tells you what your agents can reach. If you are wiring a remote MCP server into something that touches customer data, the three questions worth answering before launch are: can I read this server’s source, what does my token let it do if it is hostile, and would I notice.
If you would rather have a person answer those against your real setup and hand back something you can forward to a customer or an auditor, that is what the MCP Risk Review is. Fixed price, 48 hours, one report.
Method and reproducibility
Data pulled 2026-08-29 from registry.modelcontextprotocol.io/v0/servers, paged via metadata.nextCursor until exhaustion, 25 pages, 2,500 records. Deduplicated by server name keeping the latest version, giving 759 unique servers. Every figure above is a count over published manifest fields only. No server was contacted, probed, or scanned. Anyone can reproduce it with the curl command near the top of this piece.
Fair disclosure on the 56%: ThynkQ runs a read-only MCP server of its own, publishing services and pricing. It answers the same three questions I just asked of everyone else, which is the only reason I think they are fair to ask.