Report · Q4 2026

State of MCP Reliability — Q4 2026

We connected to every remote MCP endpoint in the official MCP Registry, listed its tools, and called none of them. Here is how many actually work, how they break, and what that means for agents and the people who run servers.

By Pavel Osadchuk · October 20, 2026 · 12 min read · Read as Markdown

On 20 October 2026 we connected to every remote MCP endpoint in the official MCP Registry: 30,516 URLs. We completed the MCP handshake, asked each server for its tool list, and called no tools. 15,697 servers (51.4%) answered correctly without credentials. 9,517 (31.2%) were up but asked for a key. 3,337 (10.9%) were broken.

The handshake is the easy part, though. For 41% of the servers that passed, no tool says whether calling it is safe, so neither an agent nor a monitor can tell from the server's own description which tool it may call.

TL;DR #

• Snapshot: one inspect (connect + tools/list) of all 30,516 remote endpoints in the official registry, from one vantage point, without credentials. No tool calls.
• Status: 51.4% healthy, 31.2% up behind auth, 10.9% broken. The rest were rate-limited by one gateway (4.9%) or asked for payment, HTTP 402 (1.6%).
• Rot: listings that were last updated in April 2026 or earlier are broken 40% of the time. Listings updated in October: 4%.
• Hosting: Cloudflare Workers endpoints are broken 6% of the time, while Railway and Render endpoints are broken 50% and 39% of the time. Every one of the 190 server.smithery.ai URLs in the registry returns 404.
• Auth: 78% of the servers that require a key do not say so in their registry entry.
• Safety: one distinct tool in three has no safety hint. Only 7,716 working servers (49%) have a read-only tool that can be called without arguments.
• Speed: a healthy server finishes the handshake and the tool list in a median of 1.2 s (p90 3.0 s).
• Context: the median tool list is about 2,000 tokens. 741 servers need more than 25,000 tokens before the agent does anything.
• Protocols: five protocol versions are in production at the same time. 18.8% of servers already run 2026-07-28.

We will run the same scan every quarter and track the same servers over time.

Why this report exists #

The official MCP Registry grew fast. 64% of its remote listings got their latest version in September or October 2026. A listing says that a server exists. It does not say that the server answers, which tools it has today, or whether those tools still work.

Directories and agent platforms show these listings to users as if they all work. Server authors rarely hear about a failure, because an agent that cannot connect does not open an issue. It tries the next server.

So we measured it. This is a baseline: the first of a series that will show how the same population changes from quarter to quarter.

Method #

flowchart TD
    R[Official MCP Registry: 46,227 active servers] --> U[30,832 unique remote URLs]
    U -->|316 URL templates skipped| P[30,516 endpoints probed]
    P --> I[Connect: Streamable HTTP, then legacy SSE]
    I --> L[tools/list, no tool calls]

Three decisions to note:

1. Remote endpoints only. A local stdio server has no URL that anyone can probe. We took every active, latest-version entry with a remotes URL and removed duplicates by URL. 316 URLs contain template variables such as {tenant}, so we skipped them.
2. A real MCP client, inspect only. The probe is the inspect step of MCP Canary, built on the official MCP C# SDK. It tries Streamable HTTP first and falls back to the legacy HTTP+SSE transport on an HTTP 4xx. It negotiates whatever protocol version the server supports. It sends no credentials and never calls a tool: an unknown tool on a stranger's server can send an email or delete a record.
3. Polite load. At most 2 connections at a time per domain, in random order. An endpoint that timed out or could not be reached got one more try 60 seconds later. 32 endpoints recovered on that retry.

What this method misses: it is one snapshot from one place. A server that was down for ten minutes that day counts as broken. And "healthy" means only that the server finished the handshake and listed its tools. It does not mean that the tools work.

The headline numbers #

Why this is not the 9% you may have seen #

An April 2026 scan of 2,181 endpoints from six directories found 9% healthy. It counted servers that ask for credentials as dead, and it required three passes over three days. Both choices answer a fair question: "can an anonymous agent use this server today?"

We answer a different one: "is this server running and speaking MCP?" A server that answers HTTP 401 is running. It wants a token we did not send. Counting it as dead would hide the 9,517 servers that are probably working products behind a login.

Bulk publishers do not change the result #

The registry has bulk publishers. The ten largest namespaces hold 22% of all endpoints. The largest has 2,365 endpoints, all healthy. Others have hundreds of endpoints that fail in the same way.

When we count each of the 18,892 publishers once, the healthy share moves from 51.4% to 49.7%, and the auth share rises from 31.2% to 39.4%. The headline holds. Small publishers put their server behind auth more often.

Silent rot: old listings break #

The registry stores when each listing's latest version was published. Group the endpoints by that date, and the pattern is clear:

Listings that nobody has touched since April are broken 40% of the time. The registry keeps them, marked active, next to servers that work. Two notes: this is the date of the latest version, not of the first release, and active publishers both republish often and keep servers alive. The table shows that untouched listings rot. It does not show how fast a single server dies. The next quarterly scan will measure that directly.

Where MCP servers run #

Grouped by the hostname of the endpoint:

Two groups stand out:

• Container platforms with free or credit-based tiers break most often. Half of the Railway endpoints and 39% of the Render endpoints are broken: dead origins (502/503), deleted apps (404), and expired hosts. The pattern fits a project deployed on a trial and then forgotten.
• Old hosted URLs stay in the registry. All 190 broken Smithery entries return HTTP 404 at server.smithery.ai. The listings still point there.

Workers looks very healthy partly because the largest bulk publisher (2,365 endpoints) runs there and is fully healthy.

The seven ways MCP servers break #

The 3,337 broken endpoints fail in a few repeating ways. Ranked by count:

1. Wrong path: HTTP 404 (948). The host is alive, the MCP route is not. 190 of these are the Smithery URLs above. The rest are mostly routes that moved (/mcp to /api/mcp, or a version prefix) without an update to the listing.
2. Origin down behind a proxy: HTTP 5xx (577). 197 answer 502, 157 answer 503, 107 answer 500, and 114 return Cloudflare's 52x/530 "origin unreachable" errors. A CDN in front of a dead origin still answers, so a ping on the domain stays green.
3. HTTP alive, MCP broken (559). The server answers but breaks the protocol. 222 fail the new server/discover step of protocol 2026-07-28, most of them by returning a result without the required supportedVersions field. 126 return an empty body to a POST. 95 return a JSON-RPC error to the handshake. 48 send no serverInfo. 36 send invalid JSON.
4. The domain no longer resolves (539). DNS has no record. Many are project domains that expired.
5. TLS fails (249). Expired or mismatched certificates. Every modern client refuses the connection.
6. No answer in 30 seconds (200). The connection hangs.
7. Other HTTP 4xx (157). Mostly 405 Method Not Allowed (57): the URL serves a web page, not MCP. 49 answer 410 Gone, so the author shut the server down but left the listing.

Loud failures and quiet failures #

flowchart LR
    A[Loud<br/>DNS, TLS, refused] --> B[Visible to a ping<br/>5xx, timeouts]
    B --> C[Quiet<br/>HTTP 200/404/405, but not MCP]
    C --> D[Silent<br/>handshake passes,<br/>tool fails or changes]

Some failures are loud. DNS, TLS, and connection errors show up in any uptime tool. Some are quiet. 1,664 endpoints (5.5%) answered HTTP normally (a 404, a 405, or a 200 with the wrong body) and still were not working MCP servers. A plain HTTP check on these hosts is green.

The quietest failure does not appear in this report at all, because no handshake can see it. A server builds its tool list in code, so tools/list still succeeds when the database, the upstream API, or the API key behind the tools is broken. 15,697 servers passed our inspect. That is all we, or any handshake-only monitor, can say about them. To know that a tool works, something has to call it and check the answer.

Can anyone safely test your tools? #

MCP tools can declare annotations. readOnlyHint: true says that a call changes nothing, and destructiveHint: true warns that it can delete data. An agent uses them to decide whether to call a tool without asking a person. A monitor needs them to choose a tool it may call every five minutes.

Counting each distinct tool definition once (143,074 distinct out of 249,332 served):

Per server, the picture is sharper. Of the 15,686 healthy servers that list at least one tool:

• 41.4% declare no hint on any tool. From the metadata alone, a client must treat every tool on these servers as possibly destructive.
• 57.9% have at least one read-only tool.
• 49.2% (7,716 servers) have a read-only tool that takes no required arguments. This is the population where a safe, automatic test call is possible without help from the author.

So the ecosystem splits in two. The passive population is all 30,516 endpoints: anyone can check the handshake and the tool list. The active-safe population is 7,716 servers where a test call is safe by the server's own declaration. For everything else, only the author can choose which tool to call and with which arguments.

Other schema gaps: 27% of tool arguments (127,694 of 469,186) have no description. 29% of tools declare an output schema. Descriptions are the one part that almost everyone fills in: only 73 distinct tools have none.

Tool lists cost context #

An agent loads the full tool list into its context on every session. We estimate the cost as the JSON size divided by 4.

• The median server has 7 tools. 10% have more than 31. The largest has 1,711.
• The median tool list costs about 2,000 tokens. 10% cost more than 11,000. 741 servers cost more than 25,000 tokens, and the largest about 586,000, which is more than most context windows.
• Names collide: 520 separate publishers have a tool named search, and 325 have a tool named fetch. An agent with several servers connected sees several tools with the same name.

How fast a healthy server answers #

The full inspect (TCP, TLS, MCP handshake, and tools/list) took a median of 1.2 seconds on healthy servers. 90% finished under 3.0 seconds and 99% under 6.0 seconds. The slowest took 20 seconds. All times are from one vantage point.

Five protocol versions in production #

Clients must support all five. The newest version, 2026-07-28, replaces the initialize handshake with server/discover, and it is already the source of the largest group of protocol errors (222 servers). The deprecated HTTP+SSE transport is almost gone: only 108 healthy endpoints still use it, though 999 of the probed endpoints declare it in the registry.

What this means if you run an MCP server #

1. Answer HTTP 401 with a WWW-Authenticate header when a token is missing. Not 404, not 500. A 401 tells clients and scanners that the server is up.
2. Declare required headers in your registry entry. Only 22% of auth-walled servers do. Without it, a client cannot know it needs a key.
3. Update or delete stale listings. If you moved the route, the host, or the platform, the old listing is now one of the 948 404s.
4. Set readOnlyHint and destructiveHint on every tool. It is four lines of JSON, and it decides whether an agent calls your tool without asking.
5. Keep the tool list small. Above about 30 tools, every session pays for all of them.
6. Test the server with a real tool call, not only the handshake. Your tool list will still look fine when your backend is down.

What this means if you depend on MCP servers #

• A registry listing is not a health signal. One in nine listed endpoints is broken today, and 40% of listings not updated since April are broken.
• Check the protocol, not the domain. 1,664 broken endpoints answer HTTP normally.
• Treat a tool without hints as mutating. For 41% of working servers, that is every tool.
• Watch the tool list for changes. A renamed argument or a removed tool breaks your agent without any error from the server.

Check your own server #

The probe behind this report is a free command:

curl -fsSL https://mcpcanary.com/install.sh | sh
# Windows PowerShell: irm https://mcpcanary.com/install.ps1 | iex
canary inspect https://your-server.example.com/mcp

inspect connects, reports the transport and protocol version, and lists every tool with its safety class. It never calls a tool. If your server needs a token: MCP_TOKEN=... canary inspect URL --bearer-env MCP_TOKEN.

To catch the silent failure, MCP Canary calls one read-only tool on a schedule and checks the result with assertions:

canary monitor set prod --url https://your-server.example.com/mcp \
  --tool search --args '{"query":"canary"}' \
  --assert '$.results.length > 0' --interval 5m

It calls a tool only when the server declares it read-only, alerts when the tool list changes, and is built to be set up by your coding agent. See the docs for every command.

Limits of this scan #

• One snapshot, one vantage point. Short outages count as broken. Latency is from one location.
• No credentials. We cannot say whether the 9,517 auth-walled servers work after login.
• One gateway has a daily quota. gateway.pipeworx.io allows 500 anonymous requests per day per IP. Our scan used it up, and 1,464 of its endpoints answered HTTP 429. We report them on their own and do not count them as broken.
• Healthy is not working. We listed tools and called none of them.
• Hints are what servers declare. A tool marked read-only can still change data. We report declarations, not behavior.

Next quarter #

This is the Q4 2026 baseline. The Q1 2027 report (January) will probe the same population again, so it can show per server:

server → availability history → tool and schema history → protocol-version history → latency history

That adds the questions one snapshot cannot answer: how many servers changed their tools without a version bump, how many died since October, and how many of the stale listings were cleaned up. We will also probe each endpoint more than once, a day apart, to separate a dead server from a bad hour. Subscribe to the feed to get it.