How we test

What a test does

1. Once a day we take the whole official MCP Registry (the latest version of each server).
2. At every address served remotely: the MCP handshake (initialize), then, if it worked, the tool list (tools/list, five pages at most), then the session is closed. The older SSE transport too.
3. No tool is ever called, no sign in is tried, no key is sent.
4. Public addresses only: anything that resolves to this machine, a private or link local network is never connected to, nor is an address with blanks to fill in (your own subdomain, say).
5. Each answer gets 10 seconds, an address 25 in all; 48 at a time, at most 2 at a time and a quarter of a second apart on one host. Every request says who we are: HorizontalProbe, with an address to write to.
6. Servers that only run as a package on your own machine (npm, PyPI, Docker and the like) aren't tested: we don't run strangers' code on ours.

Six results

Works

We connected, the MCP handshake succeeded and it listed its tools. Some still ask for a sign in once a tool is called: the tried use cases show that layer.

Needs sign in

The server is up, but asks for a sign in or a key first; without one we can't see its tools.

Answers, but broken

Something answers at the address, but not a working MCP server: not found, a server error, or no MCP in the reply.

Unreachable

The name doesn't resolve, the connection is refused, the certificate fails, or nothing came back in 10 seconds.

Not testable

The address needs filling in first (your own subdomain, say), or points into a private network, which we don't connect to.

Runs locally

Only runs as a package on your own machine (npm, PyPI, Docker and the like). We don't run strangers' code on ours, so it isn't tested.

What to watch out for

Instructions aimed at the agent

A tool's description tells the agent to do something first, follow a link, or keep something from the user. It may be an advert or a prompt injection: read it before you use it.

Hidden characters in a description

A tool's description holds zero width or text direction characters: invisible to a person, read by the agent.

Tells the agent to use it first

A tool's description tells the agent to use it first, or before other tools or a web search. Sometimes that is the order the server needs (fetch the ids first), sometimes it is pushing itself ahead of others: read it and judge.

One host, many entries

The same host has 50 or more entries in the registry. Some are platforms listing each API on its own, some are listings in bulk.

Has tools that change things

The server itself marks these tools as deleting or overwriting data (destructiveHint): have the agent ask you before it calls them.

Marked deprecated

Whoever listed it marked it deprecated in the registry.

A program finds these by rules and shows what it found, so you can judge. Servers whose descriptions carry instructions aimed at agents stay out of search results, and that description isn't reproduced.

How lists are ordered

1. First by the test: working servers first, then those needing a sign in, broken and unreachable last.
2. Within each, by score: the number of tools (up to 30 count), whether it has a title, a website and a code repository, how complete its description is, how fast the handshake was (most under a second), and whether it was updated in the last 90 days.
3. Taken off: 50 or more entries from one host (perhaps listings in bulk), instructions aimed at agents or hidden characters in a description (the most, and such servers stay out of search results), marked deprecated.
4. Two at most from one host on any list, so no one host fills it.
5. Scores can't be bought. Paying buys monitoring, reports and listing work; it changes no server's test and no order.

Where ways to use a server come from

1. Tried and tested: we had an agent do a real task with the server, calling read only tools only, and kept the input, the output and the date.
2. From the maker: submitted by whoever claimed the server, marked as such; read by us, not run again.
3. From the tool descriptions: worked out from the tool list alone, never run, and always marked so.
4. As in the case library, a use case starts as a draft and goes up once a person has read it.

Data

Server names and descriptions come from the official MCP Registry, written by whoever listed them, shown as they are. Searches on the site are counted by day, with no visitor's network address kept. The search MCP server counts its calls by day and by tool, and its clients only by the name they give. A claim or a note of interest keeps the email address you give, only to write back: never shown, never passed on; to have it deleted, write to [email protected].

Rather not be tested, or a wrong result

Rather not be tested? Write to [email protected] with the address: we stop testing it and take it off the pages and the search. If a result looks wrong, write too.

[email protected]