MCP Server Release Self-Checker

Submission rejected—most likely not due to code issues, but one of these: incorrect namespace, TXT record placed at the wrong location, description too long, or duplicate version. We hit every one of these pitfalls when submitting our own x402 data marketplace—same version numbers cannot be republished (e.g., must increment from 1.0.0 to 1.0.1), and TXT records must be placed atDomain RootInstead Of _mcp-auth Selectors of this type reject descriptions exceeding 100 characters outright. This tool validates each official requirement and generates an executable command sequence.

Free · No login required Local Generation · Content is not uploaded Corresponding Incident · Duplicate version release rejected

1Namespace and Identity

Namespace (the `name` prefix in server.json)

Domain verification must be the reverse of the domain name:feegate.org → org.feegate; GitHub verification is io.github.username。

Server name (the part after the slash)

Verify domain

Verification method

2Server information

title (display name)

description (≤ 100 characters)

Current 0 characters ·

Version

Last released version

Transport protocol

MCP Endpoint URL

Official Website

GitHub repository URL

ResultSelf-check result

Outputserver.json

0 lines

—

OutputPublish Command Sequence

0 lines

—

Keep the order correct: verify identity first → then publish. Publishing is not submitting a PR to the official repository; you must use mcp-publisher Run from your own project directory.

Quick ReferenceCommon Rejection Reasons

Error / Phenomenon	True Culprit	How to Fix
version already exists	The same version number cannot be released repeatedly	Increment the version number by 1 (e.g., 1.0.0 → 1.0.1), then publish
generic signature error	TXT record placed in `_mcp-auth.domain` Under This Selector	Must be placed inDomain Root(apex), placed in SPF style rather than DKIM style
Verification still fails after changing the key	The old TXT record wasn’t deleted and was read first.	Delete the old TXT record when rotating keys.
HTTP validation: local curl succeeds, official fails.	Officially, it pulls from its own machines; andDo Not Follow 3xx	The verification file must return HTTP 200 directly—no redirects; verify that the IPv6 AAAA record is reachable.
Namespace validation failed	name is not the reverse of the domain name.	`feegate.org` Corresponds To `org.feegate/*`
description was rejected.	Exceeds 100 characters	Trim to ≤ 100 characters; leave details for the README.
macOS key generation failed	The system LibreSSL does not support Ed25519	Use OpenSSL 3.0+ (`brew install openssl@3`）

We’ve Fallen Into This Pitfall

1 · The same version number cannot be republished.After successful publication, to change the description, you must bump the version from 1.0.0 to 1.0.1; otherwise, the update is rejected outright.

2 · The TXT record must be at the domain root.Intuitively, records would be added to _mcp-auth.example.com, official tools only recognize apex (example.com), adding a selector will always trigger a generic signature error, making it difficult to associate the issue with incorrect placement

3 · Publishing is not submitting a PR.Adding server.json to or modifying seed.json in the official repository will not result in listing; you must publish using the CLI from your own project directory.

4 · Official fetching and your local curl are two different things.The official infrastructure accesses your endpoint directly and does not follow redirects; if IPv6 records point to unreachable addresses, verification fails immediately—even if IPv4 works fine in browsers.