MCP Server Registry Records Missing remotes Field Make Hosted Endpoints Invisible

A Real Case: Why a Hosted Endpoint "Disappears" from the Registry

minia2a operates a hosted MCP endpoint at https://minia2a.uk/mcp — no installation, no API key required, responding to initialize and tools/list requests over streamable HTTP. At the same time, they also publish a local stdio package, npx -y minia2a-mcp.

Both endpoints genuinely exist. But one of them is "invisible" in the registry.

According to the developer blog, a directory that reads the official MCP registry rendered the server as "Local stdio," with no trace of a remote proxy. This means clients resolving the service through the registry would never know the hosted endpoint exists — even though it has been responding to requests all along.

Root Cause: A Record Is Not an Endpoint

This is an easily overlooked key point: clients that read the registry do not probe your server — they read your "record" and trust it. If the record does not declare a given transport, the client behaves as if that transport does not exist.

minia2a's record itself is clean but incomplete. The JSON record only declared the npm package and stdio transport, with the remotes field set to null. Nothing pointed to the hosted endpoint URL, so no downstream client could discover it.

The key missing field: a registry manifest has a top-level remotes array, parallel to packages. Each element must declare a transport type (streamable-http or sse) and an absolute URL. minia2a's gating is sent per-request by the client, with no fixed header hardcoded in the manifest, so there is no headers entry.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic in late 2024, designed to let LLM applications connect to external tools and data sources in a standardized way. It defines several transports, the two most common being: stdio — the client launches the server as a local subprocess and exchanges JSON-RPC messages over standard input/output, suited for local tools distributed with a package; and streamable HTTP (and its predecessor SSE) — the client sends requests directly to an HTTP endpoint and the server responds in a streaming fashion, suited for hosted services that require no installation. The two are equivalent in capability but have completely different discovery paths: stdio servers are resolved via package managers, while hosted endpoints must have a reachable URL explicitly declared. The MCP registry exists precisely to index the latter, and the transport declarations in its manifest determine which access methods a client can see.

Why Can't the Record Be Edited Directly?

Registry versions are immutable: once a record is published, it is frozen. Modifying it means publishing a new version — incrementing the version number is a new release, not an edit.

So minia2a's hosted transport was placed in its own record, containing no packages array at all and declaring only remotes.

If this looks like a workaround, the data says otherwise: in a sample of 100 records pulled from the official registry, 85 declared only remotes (hosted URL with no package), and only 15 were package-based. Remote-only records are the normal form for hosted endpoints, not a hack. Having two records makes sense: one describes an installable package, the other describes a connectable endpoint, and registry clients pick the transport they support.

85 / 100 Share of sampled registry records that declare only remote transport with no package

The registry's immutable design rests on a content-addressing-like publishing model. Once written, a record is frozen; any change produces a new version, and old versions remain referenceable. The benefit: clients or third parties can cache a record and be confident it will not be tampered with behind their backs, and supply-chain audits become easier — you can pinpoint exactly what a given version declared at the time. The cost is that manifest fields must be planned completely before publishing, especially the transport enumeration. Once remotes is omitted, the only remedy is not to "edit" but to "publish another one," because the old and new records describe different sets of interfaces and cannot be covered by an incremental update. Understanding this is what makes it clear why two coexisting records are normal rather than redundant.

Verification Results

Both checks targeted the live system:

1. The endpoint responds without any installation — a POST request to https://minia2a.uk/mcp sending the initialize method returns HTTP/2 200, content-type application/json, and sets Mcp-Session-Id, with the serverInfo response containing name and version.

2. The registry now returns two records under that namespace — the stdio package and the remote endpoint — and a directory that previously showed only the local package now renders both interfaces.

Reusable Lessons

If you both host an MCP server and publish it as a package, your registry record must declare both. A record that only declares packages tells every client reading the registry that your hosted endpoint does not exist — no matter how long it has been online, it cannot change what the client reads.

A practical checklist:

• If you respond to initialize at some URL, that URL belongs in remotes.
• If you also publish a package, keep the packages array — they describe different transports, not duplicates.
• Records are immutable: plan your transport list before the first publish, or be prepared for a second record.
• Then read your own record the way a client would — because that is what the client sees, not how long you have been online.

The separation of discovery from availability is a classic pitfall in distributed systems: a service can be fully available on the network yet invisible in any directory that relies on a static description. The MCP registry adopts a strategy where "clients only read records and do not actively probe," which follows the same logic as browsers not scanning ports and DNS resolvers only looking up records without verifying that the origin site is online. The benefit is fast queries, cacheable results, and no leakage of private endpoints; the cost is that the record becomes the sole source of truth, and an incomplete record equals a nonexistent service. Therefore, the checklist when launching a hosted MCP service should include: "Read my own record from the perspective of a registry client — can every access method I offer be reconstructed from it alone?"

An Overlooked Detail

minia2a's /.well-known/mcp.json already carried the pointer {"type":"streamable-http","endpoint":"https://minia2a.uk/mcp"}. But the registry record did not. Of the two, the registry client reads the latter — and the latter is precisely the silent one.

For MCP developers who both operate a hosted service and publish a local package, this case is worth adding to the pre-release checklist: the completeness of transport declarations in the record directly determines whether the service can be discovered by the registry ecosystem.

One-line Summary

Whether an MCP hosted endpoint can be discovered depends on the registry record, not on whether the server is online.

Paragraph Summary

Using minia2a's real case, the article explains that registry clients do not probe servers — they only read and trust records, so an undeclared transport is equivalent to nonexistence. minia2a operates both a hosted endpoint at https://minia2a.uk/mcp and a local stdio package, but its registry record declares only packages with remotes set to null, causing the directory to render only "Local stdio" and making the hosted endpoint invisible to clients. Because registry records are immutable, the fix is to publish another record containing only remotes. In a sample of 100 official registry records, 85 are remote-only records declaring only remotes, showing this is the normal form. Two live verifications confirm the endpoint responds normally and the registry now returns two records. Based on this, the author provides a pre-release checklist.