Claiming an MCP server page: we verify the address, not the record

A claimed page carries signed attestations and speaks for a real maintainer. That makes the question “who is allowed to claim this page?” the most consequential design decision in the product. This post explains the answer and the wrong answers we rejected on the way.

What a claim is anchored to

A page on MCP Checkup describes an endpoint URL. When you claim it, you are asserting control over that endpoint. So the proof has to be something only the operator of that host could produce. We accept two:

• A well-known file. We give you a token; you serve it from a fixed path on the endpoint’s own host. We fetch it from that host, over HTTPS, and compare.
• A DNS TXT record. You publish the same token in a TXT record at a fixed name built from the endpoint’s hostname. We resolve it and compare.

Both proofs are checked against the host taken from the endpoint URL we probe, never from anything you typed into the claim form. If the page says the server lives at mcp.example.com, the file must be on mcp.example.com and the TXT record must be named _mcp-checkup-claim.mcp.example.com. There is no field where you can point us somewhere else.

The wrong answer we turned down

A third proof suggests itself: put a token in the root of the server’s source repository. It reads naturally, it is how several package registries work, and it is wrong for us.

A repository token proves “I control a repository.” It does not prove “I control the endpoint this page is about.” Anyone could point our form at any server, name a repository of their own, drop the token there, and walk away owning a page about someone else’s endpoint. The proof was disconnected from the thing being claimed. We don’t accept it; the two proofs above are the only ones we take, because both are impossible to produce without the host.

Why the claim can’t move between records

Sometimes we already have a page for an endpoint before its maintainer shows up. Sometimes a maintainer arrives with an address we have never seen. The claim flow at /claim/new handles both, but with one rule: a claim is for the record whose address you proved, and only that one.

• If we already list the endpoint, you are sent to that existing page and prove control of its host. You do not get to create a duplicate with a nicer name.
• If we don’t list it, you name it and we create a provisional record that only you can see until the proof succeeds. If you never finish, the record is deleted after 30 days and nothing was ever public.
• A proof for one address cannot be reused for another. Different host, different token, different record.

This also settles the “rename” problem. A claimed page’s name and provider slug are part of a URL other people link to, so a maintainer can’t quietly repoint a well-linked page at a different server by editing the record. The address is the identity; everything else is a label.

What claiming does not ask for

Nothing about your server’s credentials. We never ask for an API key, a bearer token, or an admin login, because the probe never uses any. Verification is a one-way check that a value we generated appears somewhere only you could put it. After that, the probe keeps sending exactly the same requests: anonymous, read-only methods, on a schedule you can see on your page.

What it changes

Once a page is claimed, the check cadence tightens according to your plan and alert emails reach you. The observations themselves don’t change, and neither does signing: runs are signed whether or not a page is claimed. What changes is that someone has taken responsibility for the endpoint, and the page stops calling it unclaimed.