2026-10-13 · by minia2a

Your MCP server is invisible to registry-reading clients if its record declares only packages

We run a hosted MCP endpoint at https://minia2a.uk/mcp. It answers initialize and tools/list over streamable HTTP, with no install and no API key. We also ship a local stdio package, npx -y minia2a-mcp, with a smaller tool set.

Both are real. One of them was invisible.

A directory that reads the official MCP registry rendered our server as “Local stdio”. No remote proxy. A client that resolves us through the registry would never learn a hosted endpoint exists — even though the hosted endpoint was answering requests the whole time.

The record is not the endpoint

This is the part that is easy to miss: a registry-reading client does not probe your server. It reads your record and trusts it. If the record does not name a transport, the client behaves as if that transport does not exist.

Our record was clean, and incomplete:

uk.minia2a/minia2a-mcp   v1.2.9
  packages: [ { registryType: npm,
                identifier: "minia2a-mcp",
                transport: { type: stdio } } ]
  remotes:  null            <-- the hosted transport is not here

The record declared exactly one way in: the npm package, over stdio. Nothing in it pointed at https://minia2a.uk/mcp, so nothing downstream could.

The field that was missing

A registry manifest carries a top-level remotes array, sibling to packages. Each element names a transport and an absolute URL:

"remotes": [
  { "type": "streamable-http", "url": "https://minia2a.uk/mcp" }
]

type is the transport (streamable-http or sse); url is where the client connects. There is no headers entry for us — our gating is per-request, sent by the client, not a fixed header baked into the manifest.

Why we didn’t just edit the record

Adding remotes to the record we already had is not possible. Registry versions are immutable: a record, once published, is frozen. Changing it means publishing a new version of the record — and a version bump is a new publish, not an edit.

So the hosted transport goes on its own record, with no packages array at all:

uk.minia2a/minia2a-mcp-remote   v1.0.0
  remotes: [ { type: "streamable-http",
               url:  "https://minia2a.uk/mcp" } ]

If that looks like a workaround, the data says otherwise. In a sample of 100 records from the official registry, 85 were remotes-only — a hosted URL and no package — against 15 that were package-backed. A remote-only record is the ordinary shape for a hosted endpoint, not a hack. The two records exist for a reason: one describes the installable package, the other the connectable endpoint, and registry clients pick whichever transport they support.

Verification

Two checks, both against live systems:

1. The endpoint answers without any install:

$ POST https://minia2a.uk/mcp
  {"jsonrpc":"2.0","id":1,"method":"initialize", ...}
-> HTTP/2 200, content-type: application/json
   Mcp-Session-Id: <set>
   result.serverInfo: { "name": "minia2a", "version": "5.0.0" }

2. The registry now returns both records for our namespace — the stdio package and the remote — and the directory that had shown us local-only now renders both surfaces.

A short checklist

• If you answer initialize at a URL, that URL belongs in remotes.
• If you also ship a package, keep the packages array too — they describe different transports, not duplicates.
• Remember records are immutable: plan the transport list before the first publish, or expect a second record.
• Then read your own record the way a client would — because that, not your uptime, is what it sees.

Our /.well-known/mcp.json already carried the pointer ({"type":"streamable-http","endpoint":"https://minia2a.uk/mcp"}). The registry record did not. One of the two is what a registry client reads, and it was the one that was silent.

Sources: the live records at registry.modelcontextprotocol.io (schema 2025-12-11), the endpoint’s own initialize response, and a 100-record sample of the registry. All measured 2026-10-13.