A team tries to publish metadata for an MCP server reachable only at mcp.acme-corp.internal to the official MCP Registry, and the submission is rejected. What is the most likely reason, and what should they do instead?
Select an answer to reveal the explanation.
Short Explanation
The public registry is a public notice board, so a server nobody outside your building can reach doesn't belong on it. The fix is your own private board, not a rename or an upgrade.
Full Explanation
Server developers can publish metadata to the official MCP Registry only when the installation method is publicly available, such as a package on a public registry, or the server itself is publicly accessible, such as a remote endpoint not restricted to private networks. The documentation specifically names servers on private networks, with mcp.acme-corp.internal as its example, and servers on private package registries as unsupported. Its recommendation is to host a private MCP registry, ideally implementing the official OpenAPI specification so host applications can consume it. The registry does not require stdio; it accepts both packaged local servers and remote servers, as long as they are publicly reachable, and republishing an internal service as a public npm package could leak internal tooling. No paid tier unlocks private servers; the rule concerns accessibility, not the account. Namespaces may be based on GitHub accounts or on verified domains such as com.example, so an io.github name is not mandatory and renaming would not fix reachability. Exam caveat: closed-source servers are allowed; what matters is public reachability, not open source. Operational check: confirm whether the endpoint resolves and answers from the public internet; if not, register it in the internal catalogue instead.