Your MCP server may already be in a directory you never signed up for

If you run a remote MCP server on a public URL, there is a decent chance MCP Checkup has a page about it, and you never filled in a form. This post explains why that is, exactly what the page does and does not say, and the two things you can do about it: claim the page, or make it go away.

How a server gets in

MCP Checkup is an observational directory. We don’t wait for maintainers to register; we start from endpoints that are already public and look at them the way any client would.

Apart from a short hand-picked starting list, our servers come from the official MCP registry, which anyone can publish to. From it we take only servers that advertise a remote HTTP endpoint. Stdio-only packages are out of scope, because checking them would mean running your code, and we don’t. We keep one endpoint per host, skip temporary tunnel domains, and read each host’s robots.txt before adding it. A host whose robots.txt disallows our user agent at that point is not added and gets no page. After that, robots.txt is not re-read; to stop checks on a server that is already listed, use the opt-out below.

Every probe is unauthenticated and read-only from your server’s point of view: a handshake, a tools/list, and a handful of protocol-level observations. We never call one of your tools. The one tools/call we send names a made-up tool, to see how your server reports the error. How to recognise a probe in your logs, by its User-Agent, and how many requests a round may send, is on the probing page.

What the page says, and what it refuses to say

A directory page is a set of observations with timestamps, not a judgement. There is no overall grade and nothing you can pay to change. That is deliberate; the reasoning is in Why we don’t score MCP servers.

Two more things worth knowing:

• Unsigned runs show no verdict. Every run that meets our publication rules gets a signed attestation, claimed or not. When a run has no signed attestation, the page lists every check with what it tests and any reason we recorded, without colour and without the four assertion states a signed run uses. The page says so. An unsigned page is not “worse”; we could not sign that run, so we don’t dress its observations up as conclusions.
• We probe unclaimed servers every 12 hours; claimed ones more often, by plan. The page shows the latest run and a 90-day record laid out by week, one cell per day, each showing the worst result we saw that day. A signed page adds colour to that record; an unsigned page draws the same record in shapes only.

Claiming the page

If it is your server, you can take ownership of the page. Claiming is done against the address, not against our record: you prove control of the endpoint’s host, and the page becomes yours, including pages for servers we found before you ever heard of us. The flow starts at /claim/new with your endpoint URL; if we already have one page for that host, you are sent straight to it; if we have several, you choose which one; and if someone else has already claimed it, the page says so.

Claiming never asks for credentials to your server, and it never changes the requests the probe sends. What it changes is who the page speaks for: the page becomes yours, it is checked on your plan’s schedule, you get alert emails when it stops answering or a protocol check fails, and you can put a “claimed” badge in your README. The badge on a free plan is static; it carries no result.

Opting out

You can also decide you don’t want a page at all. Email us, as described on the probing page, and we will stop every check of that endpoint. The server is removed from the directory, and its report and attestation pages return 404 from then on. We don’t keep a public “this server opted out” placeholder; signed records already issued are kept with their content and signatures unchanged (in our database for at least 30 days, then in cold storage), but we no longer publish them. (robots.txt only governs servers we discover on our own: one that disallows automated clients is never added in the first place.)

Why do it this way

A directory that only lists servers whose maintainers showed up is a marketing list. The agents that actually call MCP servers need the opposite: a place that has already looked at the server they are about to depend on, whether or not anyone asked. That is the gap this directory fills. It is also why the checks are boring on purpose: reachability, protocol version, tool list, redirects. Observable facts any client could reproduce with curl.

If you find a page about your server and something on it looks wrong, tell us. We would rather fix a probe than defend it.