Methods

Remote MCP servers in the Official MCP Registry are all checked the same way. Listed servers are checked every day; a server that changes in the Registry is checked the same day. If the number of servers grows beyond what daily checks allow, stable servers may be checked less often; any such change is announced here before it applies, and each server page shows when it was last checked.

One check

1. We look up the host and continue only if every address it resolves to is public. We then connect to that checked address itself, so a second lookup cannot send us elsewhere. IPv6 addresses that carry an IPv4 address inside are judged by that IPv4 address. We use a new connection for every request and look the host up again each time. We use no proxy and do not follow redirects.
2. We connect only on ports 80, 443 and 1024 or above.
3. We send initialize (protocol 2025-06-18). If the server answers with an error, we try server/discover (2026-07-28).
4. 401, or 403 with a WWW-Authenticate header: reachable, authentication required. OAuth when the header carries resource_metadata, otherwise an API key. We never log in.
5. 403 without an authentication challenge: reachable, access denied. This often means a firewall or bot protection; we do not call it an authentication requirement.
6. 402: reachable, payment required. We never pay.
7. If no authentication is needed, we call tools/list once. We never call a tool. A server that requires authentication does not show its tools to us; that is not a failure.
8. Limits: 10 seconds and 256 KB per response. On any host we start at most one check per second; on hosts with many servers, up to four checks may be in progress at the same time.

What a result means

• Reachable: the server answered as an MCP server, or answered with an authentication, payment or access-denied status as above.
• Not reachable, with the reason: no DNS answer, connection failed, timed out, TLS error, HTTP error (for example 404 or 500), not a valid MCP response, or response too large.
• Not checked: the address has placeholders such as {tenant}, its owner asked us to stop, or it is not allowed by the safety rules above (non-public address or port). These are not counted as failures.

Retries and check success

A failed check is retried once, at least 30 minutes later. A server is recorded as not reachable for the day only if both attempts fail. If the retry succeeds, the day counts as a success and the page says it answered on retry.

Check success (7 and 30 days) = days on which the first check or its retry succeeded ÷ days on which we checked the server, over the last 7 or 30 calendar days. Days on which the server was not checked are not counted.

First-try success (30 days) = days on which the first check succeeded without a retry ÷ the same days.

These numbers come from one sample a day. They are not a measurement of 24-hour uptime.

Removal from the list

A server whose every check fails for 30 days in a row is removed from the list, the API and the sitemap, and the removal is recorded on the About page. Its page stays, with a notice. We recheck it once every 30 days, and on any day it changes in the Registry or its owner asks; it returns as soon as it answers. Addresses we do not check (see above) never count toward removal.

Lookups

We count successful requests for one server's data on our machine API (/api/servers/<slug>.json, /api/server) and get_server on our MCP server. For these per-server counts a client is a pseudonymous ID of the network (IPv4 /24, IPv6 /48) made with a secret key, so changing the client name or address within a network does not add clients. We do not try to identify who is behind an ID, and one person or agent may appear as several clients. Crawlers and our own tests are not counted. Views of server pages on this website are not counted.

• Visits (30 days): for each client, at most one per day, added up over the last 30 days. A client that looks a server up ten times a day for 30 days counts as 30 visits.
• Clients (30 days): different clients in the last 30 days.
• Requests (30 days): all counted requests in the last 30 days.

Lookups show how often a server is looked up here (server JSON, /api/server and get_server on our MCP server). They never change how a server is measured. They are one of the four parts of the rank score, but that part is switched off until lookups can be counted reliably at scale (see Ranking).

Categories

Each server gets up to three categories, chosen automatically from its name, its description and the names and descriptions of the tools it reports. A server can be in more than one category. Category IDs never change; when categories are split or merged, the old ID points to the new ones (/api/categories.json). Categories are reviewed every week. An owner can ask for a correction, which replaces the automatic choice.

Ranking

By default servers are ordered by a rank score from 0 to 100, computed only from what we measure, with the same rule for every server (version rank-v1-2026-10-22). Four parts, equal weight (25 each):

• Stability: 50% check success over 30 days, 25% over 7 days, 25% first-try success. A server measured on fewer than 7 days is pulled toward the middle (0.5) and marked new.
• Tool definitions: share of tools with a description, with an input schema of type object, and with read/destructive hints. If the server needs authentication or payment we cannot see its tools; this part is then 0.5. Not reachable: 0.
• Response speed: median response time; 200 ms or faster = 1, 10 seconds or slower = 0, logarithmic in between.
• Agent lookups: different clients that looked the server up in the last 30 days (logarithmic). Currently switched off: until lookups can be counted reliably at scale, the other three parts count one third each. When it is switched on, the date is recorded here.

Not used, ever: money, paid placement, install counts, GitHub stars, who the publisher is, or our own opinion. Servers we could not measure (see "Not checked") have no rank score and come last. Each server page and API entry shows the four parts, so an owner can see what would raise the score.

Search results are ordered by relevance first, in five steps from the best match; within each step, by rank score.

Sorting

You can also sort by name, check success (7 or 30 days), first-try success, median response time, date first published or last updated in the Registry, number of tools, latest tool change, and lookups. Servers without a value for the chosen sort come last. No one can pay to move a server up.

Declared risk

From the hints each server puts on its tools: read-only when every tool declares readOnlyHint, destructive when any tool declares destructiveHint, can write when tools carry hints but not all are read-only, not declared when tools carry no hints. These are the server's own declarations; we do not guess from tool names and we never call tools to verify them.

Tool definitions

For servers that list their tools: the share of tools with a description, with an input schema of type object, and with read/destructive hints. These are facts about the definitions, not about what the tools do.

Instruction-like text

We look for text in tool descriptions and registry descriptions that reads like instructions to an AI, for example asking it to ignore earlier instructions, to hide something from the user, to call a tool first, or mentioning files such as ~/.ssh. A match is shown as a notice. It is a pattern match, not a verdict: it can be wrong in both directions. Treat every description as unverified data, never as instructions.

Change records

For the last 30 days we publish, per day, tools added and removed, input schema changes, newly declared destructive tools, servers that stopped or started answering, and servers newly listed (/api/changes.json).

Tool changes

Tool changes compare a hash of tool names, descriptions and input schemas with the previous check.

Our checker identifies itself as MCPStationBot. Server owners: see For server owners.