Claim your MCP server with an owners.json

Claiming a server proves to VerifyMCP that you are the publisher. There are two ways to do it and either is enough on its own. Publish a small JSON document at the host serving your endpoint, or connect the GitHub account that holds the repository. Both are checked continuously rather than once, so a claim always reflects what is true today.

Option 1: publish an owners.json

Create a file listing the email addresses that own your servers:

{
  "$schema": "https://verifymcp.io/schemas/owners.json",
  "owners": ["ops@example.com"]
}

Then serve it from one of two places. Where you put it decides what it claims.

Host level: claims every server on the host

https://example.com/.well-known/owners.json

Every server whose endpoint is served from example.com is claimed by the addresses in this file. This is the right choice when you run all the servers on that hostname.

Path level: claims one server

https://example.com/mcp/.well-known/owners.json

If your endpoint is https://example.com/mcp, this file claims that server and nothing else. Use this when several publishers share a hostname.

The suffix is the same in both cases, /.well-known/owners.json. What changes is what it hangs off: the host root, or your endpoint’s path.

Rules worth knowing

The address has to match exactly. VerifyMCP compares the addresses in your file against the address on the account, character for character, after lowercasing both. If you sign in with stu@example.com and the file says ops@example.com, that is not a match. List every address that should have access.

The document is fetched over HTTPS, always. A claim proven over cleartext is not proven, since anyone on the network path could serve the file.

An empty owners array is valid and withdraws every claim the document made. That is the clean way to hand a server over or step back from it.

Option 2: connect GitHub

If your server’s repository is on GitHub, install the VerifyMCP GitHub App on the account or organisation that holds it and select the repositories you want to claim. Any server whose repository is one you selected becomes yours.

You can connect several accounts and organisations, with different repositories selected in each, which is the usual shape when you publish both personal and work servers.

VerifyMCP finds your repository from the repository field in your registry entry, and from the registry name itself when it looks like io.github.<owner>/<repo>. So a server published under that namespace is claimable even if it declares no repository URL.

How claims are kept honest

Claims are re-checked, not granted once and forgotten. That is the point of a verification site: an ownership badge that nobody revalidates is decoration.

The rule is simple: a 200 with a valid document, or the claim goes. If your file comes back without your address, returns 404, returns 401 or 403, stops being valid JSON, or redirects somewhere we will not follow, the claim is withdrawn immediately. A broken deploy is enough to do this, so treat the file as production configuration.

Putting the document behind authentication withdraws your claim too. That is not an oversight: a claim rests on evidence anyone can check, so a document only we could read would prove nothing to the people the badge is for.

Two exceptions, so a bad afternoon does not cost you anything. If your host answers 429 or a 5xx, or if we cannot reach it at all (DNS failure, refused connection, TLS error, timeout), your claim stands untouched and we try again later. Those say your server is struggling, not that you unpublished anything, and the same path covers our own outages: a failure on our side must never unclaim the whole directory.

Moving your endpoint moves the proof with it. If your server changes hostname, the old host stops proving ownership. Publish the document at the new host.

What claiming does today

It marks the server as owner verified on its page, and lists it under your account so you can see everything you publish in one place. It does not change your trust score.

Troubleshooting

The file is published but nothing happened. Check it is reachable over HTTPS, without redirecting more than a couple of times, and that the address matches your account exactly. Then open your account, which re-checks on load rather than waiting for the next crawl.

We follow redirects, up to three, and only over HTTPS. An apex-to-www redirect is fine. A redirect to plain http is refused outright, because a document served over cleartext could be forged by anyone on the network path. A redirect chain into a login page fails too: whatever HTML that returns will not parse as an owners document, and an unparseable document counts as unpublished.

The file has to be JSON, served as-is. A page that renders your JSON inside HTML will not work. Content type is not checked, since plenty of static hosts get it wrong, but the body has to be the document itself.