Is that MCP server actually up?

Every server on the official MCP registry that publishes a connect URL, probed once a day with a real initialize handshake and a tools/list call. 30,838 endpoints, last checked 2026-10-23.

2,395 endpoints (7.8%) answer HTTP but cannot complete an MCP session. That is the finding this exists for. A reachability check — DNS, a ping, an HTTP 200 — marks every one of them healthy. Only a real handshake sees it.

Is it your own server that will not connect? The same check runs locally, against one address or one command, and names which of three causes you have — a missing launcher, a dependency that moved, or a transport mismatch. Why does my MCP server say “connection closed”?

How many answer a stranger

16,346 endpoints (53.0%) returned their full tool list to a caller sending no credentials at all. Between them they described 236,906 callable tools. This probe has never held an API key, a token or a cookie for anybody — that is how "needs credentials" gets detected in the first place — so every endpoint in the first row of the table above is one that told an anonymous stranger what it can do.

Counted by operator instead, it is 12,230 of 23,180 hostnames (52.8%). Prefer that number if you are quoting one. The endpoint share is partly a measure of who runs the most servers — the three largest fleets alone hold 14.7% of the endpoints that answered — and one operator standing up a thousand endpoints should not move a finding about the ecosystem.

This is not a security score and it names nobody. Answering an anonymous caller is correct behaviour for a public search tool, a docs server or an open dataset, and requiring credentials stays what it is everywhere else on this site: correct behaviour, not a defect. The largest published survey of the question takes the same view. TrendAI's “Stars Don’t Save You” (24 June 2026) audited 9,695 MCP servers and deliberately set aside 3,573 of them that had been marked unsecured “solely because of a lack of authentication”, because it “did not consider it alarming enough to flag an MCP server on its own”. Its headline 4,982 issues are the ones that survived that exclusion.

And it is not the same measurement as theirs. TrendAI crawled four directories — GitHub, Glama, Lobehub and PulseMCP — and read the servers' published source. This page opens a live connection to a URL on the official registry and sees what actually answers. Source code can show an auth check that a deployment never enforces, and a running endpoint can demand credentials its repository never mentions. Neither number substitutes for the other, and the two should not be added, compared or quoted as one finding.

A further 630 endpoints completed the initialize handshake anonymously and then produced no tool list; those are not counted above, because a handshake is not a tool call. Separately, 103 completed the handshake and then asked for credentials at tools/list — a partial gate the five-way table cannot show, since it files them under "answered, no tool list".

What changed under you

1,184 of the 17,968 endpoints that list tools changed their tool contract on the most recent pass. Uptime is the loud failure: the call errors and somebody notices within the hour. A tool being renamed, a required field being added, a description being rewritten — none of those break the connection. The session still completes, this page still says “answered, tools listed”, and the failure reaches a person as “the assistant is being weird today”. So on every probe that returns a tool list we hash each tool and diff it against the last list we held for that same endpoint.

Over the 24 day(s) tracked so far, 5,766 endpoints have moved at least once: 5,989 tools added, 1,555 removed and 19,726 changed in place. 3,256 of them moved on more than one day, which is usually a property of the server rather than news — a description carrying a timestamp or a session id drifts every time it is read.

This stores no schema. What is kept per tool is two short hex digests — one of the name, one of the name with its description and input schema — and nothing else. A digest is a one-way function of somebody else's text, not a copy of it, so the count above can be published without republishing a word of anyone's documentation. It is also why this page can tell you that a contract moved and how much of it, but not what it now says: for that, ask the server.

Find a server

Every probed endpoint has a page and a badge, not just the ones in the tables on this page. The address is the registry name lower-cased with every run of punctuation turned into a single hyphen — io.github.Owner/My_Server is /mcp-health/server/io-github-owner-my-server/ — or browse all of them A–Z. The box needs JavaScript; the rule above and the A–Z pages do not.

Day by day

Probed is lower than the number of registered endpoints, and the difference is ours, not theirs. On 2026-10-23 we did not get an answer from 4,211 endpoints: 457 rate-limited us and 3,754 were not reached before the pass ran out of time. An endpoint we did not look at is absent from that day rather than counted as broken, so it draws as a gap. Being refused is not evidence about a server — it is evidence about our own request.

Some of what answered today

40 of the 16,346 endpoints that completed a handshake on the most recent pass, largest tool list first, and at most one per host so that one operator's fleet cannot fill the table. Neither column is a score. Tool count is what tools/list returned, not a measure of how useful a server is; the Median column is the round-trip for a full initialize, and a server doing real work on connect is not worse than one that does nothing. These are the largest, not the shape of the corpus: half the servers that answered list 7 tools or fewer.

Answered once, not today

These completed a handshake on a day we probed and did not on the most recent one, at most one per host. This is the field that matters — not a score, which rots, but when the endpoint was last seen working.

How this is measured

Once a day, each endpoint gets a JSON-RPC initialize and — if that succeeds — a tools/list. The user agent identifies itself and carries a contact address; there is a minimum gap between two requests to the same host and no retry storm. Every endpoint probed is a URL its publisher listed on a public registry so that clients would connect to it.

Both remote transports. MCP has two. Streamable HTTP is one POST per message, at protocol version 2025-06-18; the original transport (2024-11-05) is two channels — the client opens the URL with Accept: text/event-stream, the server names a separate POST address in an event: endpoint frame, and replies come back down the open stream. A POST alone cannot complete a handshake with the second kind however healthy the server is. This probe got that wrong until 2026-09-08 and published 143 servers as "answers HTTP, not MCP" that were nothing of the kind — 104 of them working, 36 wanting credentials. They were re-probed and corrected the same day, and each endpoint is now tried on whichever transport its publisher declared, with the other as a fallback.

Deliberately not a score. No 0–100 number, no "dead" flag. The registry considered a publisher-declared health field in 2026 and withdrew it, because a static score rots and because nothing was actually dead — the failure is protocol-level, in servers that answer HTTP perfectly well. "Needs credentials" is not a fault: it means we could not complete a handshake without an account, which is all we can honestly say. Our own server is probed by this same code.

Corroboration. Three independent measurements of this population between 2026-07 and 2026-09 — MCP registry issue #1487, siliroid/mcp-endpoint-census, and yassinht/mcp-observatory — found the same shape of failure at 8–12%, using different samples and methods. This is a continuously-running, publicly-readable version of that check.

We are not the only ones probing. mymcptools.com publishes live handshake results too, and has a longer run of them than we do — theirs go back to 2026-07-02. Theirs is a curated catalogue: of its 2,440 listings, 44 have a remote endpoint that can be probed at all, the rest being local installs with no address. Ours is a census of every endpoint on the official registry. Where the two overlap, they agree — on 2026-09-09, 26 of their endpoints matched ours and all 26 verdicts were the same. They hash each tool schema and flag it when it changes under you, and they were doing it before we were; that is where the section above came from. io.github.operatorsheets/mcp-uptime, on the official registry since 2026-08-01, offers the same check as a tool you can call.

And two more, one of them casting a wider net than ours. RoninForge's State of MCP checked every server on the registry — all 31,538 of them in its 2026-09-13 census: 80.6% healthy, 14.8% degraded, 3.8% dead. Wider, because a server there can be graded without anybody ever connecting to it: a GitHub repository that has rotted — gone or archived, 3,587 of 24,383, 14.7% — or a package that was never published counts toward its verdict, so servers that publish no connect URL at all still get one. This page only ever grades an endpoint we opened a session with, and says nothing whatever about the other kind. That cuts both ways — "healthy" there can mean the packaging is intact, and here it always means a completed MCP session. Slower, though: five censuses in about ten weeks, the newest dated 2026-09-13, against 30,838 endpoints re-probed every day for 30 days here — and their 2026-09-13 census found 19,150 remote-bearing servers where this page probes 29,722 names today, which is what a dated snapshot costs you. Their headline rates are not ours and should not be read as ours: 22.5% of their remote-bearing cohort is dead-or-broken where 7.8% of our endpoints answer HTTP without completing a session, and the distance is almost entirely what each verdict is allowed to be earned from. The nearest thing to a like-for-like is a declared remote that cannot be reached at all: 9.8% there on 2026-09-13, 8.6% here today — and even that is not exact, because their bucket counts an HTTP 404 as down where ours files it under "answers HTTP, not MCP". Their data is CC BY 4.0 and wants attribution; this is CC0 and does not. MCP Queen is the other: 18,849 servers indexed and 9,326 graded live when we read it on 2026-09-30, with its own dated report putting one remote server in six dead in July 2026.

And a fifth that is not measuring the same thing at all. lastseen.dev publishes a dated MCP census — 28,824 server repositories on 2026-07-22, of which it called 70.7% alive, 7.8% dormant, 9.3% abandoned and 12.0% deleted, headlining 21.3% "not maintained" — with a Zenodo DOI, Sigstore-signed releases and a published correction process. Do not read that 21.3% against anything on this page. It grades a repository on how long ago somebody last committed to it; this page grades an endpoint on whether it completes an MCP session right now. A finished server nobody has touched in fourteen months answers every handshake perfectly — abandoned to them, healthy here. A server committed to last week whose deployment has lapsed or whose TLS has expired is alive to them and unreachable here. That is not a quibble, and rather than assert it we measured it: on 491 servers that both registers graded on 2026-10-01, 25.6% of the repositories they call alive are endpoints this page cannot get a session out of (86 of 336, 95% CI 21.2–30.5), and 27.7% of the repositories they call abandoned, deleted or archived answer a clean handshake here (36 of 130, 95% CI 20.7–35.9) — 26.2% disagreement in one direction or the other. Neither register is wrong in those cases; they are answers to different questions, and which one you want depends on whether you are asking "will this still be maintained next year" or "can my agent connect to it this morning". The overlap is small — about half the servers we sampled are not subjects in their register at all, since a server that declares no repository gives them nothing to watch, exactly as a server that declares no connect URL gives us nothing to probe — and it is drawn from an alphabetic slice of the registry rather than all of it, so treat it as a rate and not as a population count. Their data is CC BY 4.0; this is CC0. Their census, with its own method written out, is here — it is worth reading, and it is more careful about the epistemics of dated observation than this page is.

Take the data. feed.json is every endpoint with its class, latency, tool count, 7/30-day uptime and tool-contract digest. A per-server page is /mcp-health/server/<name>/ and a badge you can embed is /mcp-health/badge/<name>.svg. Free, no key, no rate limit. If you run a directory and want this as a feed, or you want your server removed from the probe, write to [email protected].

Licence. CC0 1.0 / public domain, for the measurements. The verdict, latency, tool count, protocol version, 7- and 30-day uptime and last-healthy date for each endpoint are our own observations, and we place them in the public domain: copy, re-publish or sell them, no permission needed, and attribution is welcome rather than required. The endpoint list is not ours to license and needs no licence: each server's registry name and connect URL are facts its publisher posted on the official MCP registry so that clients would connect to them, and those two fields are all we take from it — no description, no tool schema, no code. Every server named here is named because its own publisher published the address. To have a server removed from the probe, write to [email protected].