We connected to every public MCP server. Half of them hand over their entire tool list with no key.
A nightly measurement of every remote server in the official MCP registry: how many list their tools with no key, how many addresses are already dead, and what the descriptions tell the model to do.
The official MCP registry tells you a server's name and address. It does not tell you
what that server exposes. The only way to find out is to connect and call tools/list.
So we did — to every remote server in the registry, and again every night since. This page reports what came back. measured 2026-08-07, 1 day(s) of history
What came back
| Servers in the registry | 20,493 |
|---|---|
| Remote addresses actually probed | 10,656 |
| Enumerable with no credential at all | 5,638 — 52.9% of addresses, 48% of distinct hosts |
| Asked us for a key | 2,979 |
| Tool definitions archived | 109,940 |
| Addresses listed but permanently gone | 1,128 — 10.6% |
1. Half the registry is open to anyone
Roughly half of publicly registered MCP servers will describe their entire tool surface — names, descriptions, input schemas — to an anonymous HTTP client. That is not a vulnerability; a catalogue is meant to be readable. It is a fact worth knowing before you assume a listed server is gated.
We publish the number two ways on purpose. Per address it comes out higher, because a single multi-tenant gateway can register hundreds of addresses. Per distinct host it comes out lower. Neither number alone is honest, so both ship.
2. A tool description is prompt text — and it can change after you approve it
This is the part that has no equivalent in ordinary API security. In MCP, a tool's
description is handed to the model as context. It is not documentation about the tool; it is
instructions the model reads.
Which means a server can be harmless on the day the user approves it, and ship different instructions the next day. The registry publishes only today. Nobody who starts measuring tomorrow can tell you what a description said yesterday.
We keep every version, content-addressed. When a description changes, that is an event:
curl -s "https://api.temsor.com/v1/mcp/index?view=changes&type=tool_description_changed&days=30"
3. What the descriptions actually say
Every archived tool carries a review score. The score is a hint, not a verdict — and it is useless without evidence, so every flag returns the matched text:
curl -s "https://api.temsor.com/v1/mcp/index?view=search&minRisk=60&limit=5"
Real flags found in the live index, with their matched fragments:
| Flag | What it matches |
|---|---|
tool_shadowing | A description telling the model to use this tool instead of another named tool. |
credential_access | Instructions about keys, tokens or private key material. |
mandatory_precall | "Always call this before any other tool" — a description claiming priority over the host's own ordering. |
secrecy | "Do not mention this to the user." |
hidden_unicode | Invisible characters inside a description. |
Two false-positive classes were tuned out against thousands of real descriptions: ordinary docs saying "silently ignored", and security tools that quote attack patterns to explain them. A quoted match still counts, at reduced weight — quoting is also a way to hide.
4. The registry does not check its own entries
1,128 registered addresses — 10.6% — are permanently gone: the domain no longer resolves, the deployment was deleted, the path returns 410. They stay listed. If your agent config was built by browsing the registry, some fraction of it points at nothing.
We separate this from transient failure on purpose. A timeout, a reset connection or a TLS handshake error is our network noise, not registry rot, and a single bad DNS minute must never be published as "this server disappeared". A death is only reported after two consecutive days.
5. One host is 40% of the index
gateway.pipeworx.io alone accounts for 41.5% of every tool we index. The obvious correction — count each host once — is the wrong one, and our own data says so: those 1,311 addresses serve 1,265 distinct tool surfaces. It is a genuine multi-tenant gateway, not one product registered a thousand times.
So we publish the concentration instead of hiding it: share of the top host, an HHI of 1,730, and for each operator both its address count and its distinct-surface count — so you can decide which it is. Any aggregate over the MCP registry that does not disclose this is being quietly shaped by one operator.
How to query it
Free tier needs no key. The change feed is fully keyless and CORS-open, because a dataset nobody can read is not a dataset:
curl -s https://api.temsor.com/mcp/changes.json
curl -s "https://api.temsor.com/v1/mcp/index?view=search&q=invoice&limit=5" curl -s "https://api.temsor.com/v1/mcp/index?view=server&server=com.temsor/api" curl -s "https://api.temsor.com/v1/mcp/index?view=stats"
How we measure, and what we will not do
- Only
initializeandtools/list. Nevertools/call— the probe reads catalogues and triggers nothing, on any server. This is enforced by a test, not a promise. - One measurement per server per day, one sequential queue per host. Different hosts run in parallel; the same host never does.
- An identifying user agent with a contact address. If you operate a listed server and want out, mail the address in the agent string.
- Both transports are spoken — Streamable HTTP and the 2024-11-05 HTTP+SSE transport — because a client that only speaks the new one records healthy servers as broken.
- Private and loopback addresses are skipped without being contacted.
Frequently asked
Does this mean half of MCP servers are insecure?
No. It means half will list their tools to an anonymous client. Listing a catalogue is not the same as letting someone use it — calling a tool may still require auth. The finding is that you should not assume a registered server is gated.
What is a "rug pull" in MCP?
A tool description is part of the context handed to the model, so it is prompt text. A server can present a harmless description when the user approves it and a different one afterwards. Detecting it requires yesterday's copy, which the registry does not keep.
Is the risk score a verdict?
No, it is a hint that something is worth reviewing, and it is never published without the matched text as evidence. A score you cannot check is a score you should not trust.
Do you ever call the tools you find?
Never. The probe calls initialize and tools/list and nothing else. A test in the suite asserts that tools/call is absent from every code path.
How far back does the history go?
Measurement started 2026-08-07 and runs nightly. The archive only grows forward — nobody, including us, can reconstruct a tool description from before the first measurement.