Publish to the MCP registry
The publish flow fails in a handful of predictable places, and DNS verification is the one that costs people an afternoon — because every failure looks identical from the outside. This tells you which route your namespace needs, gives you the exact record, and then looks it up for real.
First time? Read the publishing walkthrough — what the registry checks, which verification route your namespace needs, and the order the steps have to happen in.
Before you publish
The registry validates your metadata, not your server — it never connects to it. A published server can fail every rule in the specification. Two things worth doing first:
- Check your
server.json— the registry rejects a publish for reasons that are hard to read from the error alone. Paste it before you runmcp-publisher. - Validate the running server — once a URL is in the registry, clients will connect to it. Better to find the failures before they do.
For the full walkthrough in prose, including the package ownership marker, see the publishing guide.
Frequently asked
Why does my namespace decide how I verify?
The registry ties a namespace to something it can independently check. io.github.alice belongs to a GitHub account, so mcp-publisher proves it with a GitHub login. Any other reverse-DNS namespace — com.example — maps to a domain, and the only way to prove you control a domain is to publish something in its DNS. That is what the TXT record is: a value only someone with write access to the zone could have put there.
I added the TXT record and it still says not verified. What now?
Check which of the four causes it reports, because they need different fixes. "No TXT record exists" means propagation — wait, most providers publish within minutes. "Records exist but none are ours" means the name is right and the value is wrong, usually a missing createmcps-verify= prefix. "Token does not match" means an old record from an earlier attempt is still there; delete it. "DNS lookup failed" is a nameserver problem and has nothing to do with the value. The check also prints the raw values it saw so you can compare by eye.
Do I enter the full record name or just the subdomain?
It depends on your provider, and getting it wrong is the most common failure. Cloudflare, Namecheap and most panels append your domain automatically, so you enter only the part before it. Route 53 and dig want the fully-qualified name. Entering the full name into a panel that appends produces a doubled domain that looks correct in the UI and resolves nowhere.
Can I remove the TXT record after verifying?
No. Verification lasts 90 days and is re-checked, so removing the record un-verifies the domain. That is deliberate: it means a domain that changes hands stops being vouched for by us rather than carrying a stale claim forever.
Does publishing mean my server works?
No, and the gap between the two is where most problems live. The registry checks that your server.json is well-formed and that you own the namespace. It does not connect to your server or check a single line of the specification. A published server can be entirely non-conformant — which is what the validator is for.