If you are running a hosted Model Context Protocol (MCP) server, your uptime means nothing if the registry record is incomplete. A recent case study from minia2a revealed that a fully functional remote endpoint at https://minia2a.uk/mcp was invisible to registry-reading clients because its manifest declared only a local npm package. The server answered initialize and tools/list requests perfectly over streamable HTTP, yet directory clients rendered it as 'Local stdio' only, completely ignoring the hosted option.

The Record Is Not the Endpoint

The core failure here is a misunderstanding of how registry clients operate. They do not probe your server to discover available transports; they read the static registry record and trust it implicitly. If the record does not explicitly name a transport, the client behaves as if that transport does not exist. In the minia2a case, the record for uk.minia2a/minia2a-mcp v1.2.9 listed an npm package with stdio transport but had a null remotes field. Consequently, the hosted URL was effectively hidden from discovery.

Immutability Forces Separate Records

You cannot simply edit a published registry record to add missing transports. Registry versions are immutable, meaning any change requires publishing a new version. To solve this, minia2a created a separate record, uk.minia2a/minia2a-mcp-remote v1.0.0, which contained only the remotes array pointing to the streamable-http endpoint. This is not a hack but the standard pattern: 85 out of 100 sampled registry records were remotes-only, proving that separating installable packages from connectable endpoints is the ordinary shape for hosted services.

Checklist for MCP Developers

Developers must ensure their registry manifest includes a top-level remotes array alongside the packages array if they offer both installation methods. Each remote element must specify the type (streamable-http or sse) and the absolute URL. The minia2a team noted that while their /.well-known/mcp.json correctly pointed to the endpoint, the registry record did not, and it is the registry record that clients actually read. Plan your transport list before the first publish to avoid needing a second record later.

Key Takeaways

  • Registry clients trust the record, not the server's actual availability.
  • A null remotes field hides hosted endpoints even if the server is live.
  • Registry records are immutable; adding transports requires a new version or a separate record.
  • 85% of sampled registry records use remotes-only manifests for hosted services.
  • Always declare both packages and remotes if you support both installation and direct connection.

The Bottom Line

Stop assuming your server's functionality is enough to get discovered. If the registry doesn't say it exists, it doesn't exist to your users.