Why is my MCP Registry server active but unreachable?

If the latest Registry record is active but declares neither remotes nor packages, discovery can return metadata without giving a client any remote endpoint to call or package to install. Check the exact latest version before debugging the MCP runtime itself.

Does status active in the MCP Registry mean the server is reachable?

No. Registry status is metadata state, not a live health check. A usable record still needs a publicly accessible remote transport, an installable supported package, or both, and the declared route must work independently.

What belongs in server.json remotes?

For a hosted MCP server, the Registry documentation supports a remotes array that identifies the public remote transport and URL. The remote must be publicly accessible. Do not substitute a repository URL or marketing website for the actual MCP transport URL.

Can an MCP Registry record use packages instead of remotes?

Yes. The Registry supports installable package metadata for supported registries such as npm, PyPI, NuGet, OCI and MCPB. A server can publish packages, remotes, or both when those declarations accurately describe how clients can obtain or reach it.

Should I edit the same published MCP Registry version in place?

Treat published versions as versioned discovery records and publish a corrected version using the Registry's versioning rules. Then verify which record is marked latest. Do not assume a metadata-only prerelease published after a final release will automatically become the latest semantic version.

Editorial

Research guide · MCP Registry data quality

MCP Registry active but unreachable: fix missing remotes or packages

An MCP server can be published, marked active and discoverable by Registry search while still giving clients no way to reach or install it. Before debugging OAuth, tools or transport code, inspect the latest Registry record: if both remotes and packages are absent, the discovery metadata itself is incomplete.

Published and sources checked 13 September 2026

387 active

Reported August 2026 Registry census with neither remotes nor packages

1.54%

Reported share of latest distinct servers in that census

2 routes

A client needs a usable remote, an installable package, or both

Fresh failure pattern

Registry presence is not the same thing as a usable route

An open MCP Registry issue filed 27 August 2026 reports an August census of 25,125 distinct latest server records. The reporter found 393 with neither remotes nor packages, including 387 still marked active. Those figures are a third-party snapshot from that issue and will drift; they are not an official live Registry metric.

The official Registry documentation describes the Registry as metadata that tells clients where a public MCP server can be obtained or reached. Remote publishing uses a public remotes URL; installable servers use supported packages. A status field cannot manufacture either route when both are missing.

Registry issue #1579 →Official Registry overview →Official remote-server publishing guide →

Fast diagnosis

Find out whether discovery metadata or runtime health is actually broken

Signal	What it means	First action
Active, no remotes and no packages	The Registry can expose the record, but it contains no client execution or installation route.	Correct the latest server.json with a real remote, supported package, or both, then republish a new version.
Remote exists, but connect times out or 404s	The discovery record has a route; the live endpoint is unhealthy, moved, blocked or wrong.	Probe the declared URL directly and debug reachability, transport and auth rather than adding another Registry identity.
Package exists, but installation fails	The locator is present, but the package/version/artifact is unusable or mismatched.	Verify the public package and Registry package metadata against the supported package-type rules.
Older version works, latest version has no route	A newer Registry version may have accidentally dropped remotes or packages.	Inspect the exact latest record and version ordering before changing the server runtime.
Only a repository or website URL is present	Human provenance is not the same thing as a machine execution route.	Keep repository/website metadata, but also declare the actual public remote or installable package clients can use.

Minimal remote fix

A hosted MCP server needs its actual public transport in server.json

If the server is hosted rather than installed, declare the real public MCP transport. The URL below is illustrative; use the endpoint your client can actually reach. Keep human-facing repository and website fields as provenance, not as replacements for the machine route.

{
  "name": "example.com/my-server",
  "description": "What this MCP server lets an agent do",
  "version": "1.0.1",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://api.example.com/mcp"
    }
  ],
  "repository": {
    "url": "https://github.com/example/my-server",
    "source": "github"
  }
}

If your distribution model is installable software instead, use the Registry's supported package metadata for the public artifact. Do not invent an empty remote merely to satisfy discovery: a declared route that cannot be reached is a different failure, not a repair.

Official supported package types →Official Registry versioning →

Repair sequence

Seven checks from broken metadata to a usable public record

Read back the exact latest record

Query the Registry by canonical server name and inspect the version marked latest. Do not diagnose from a local server.json alone.

Choose the real acquisition path

If clients call a hosted service, publish a public remote. If they install software, publish a supported package. Use both only when both are genuinely maintained.

Declare the actual transport or artifact

For a remote server, point remotes at the real MCP transport URL. For a package, match the public registry, identifier, version and transport to the artifact clients can install.

Keep provenance separate

A repository URL and website can help humans verify ownership, but neither replaces remotes or packages as the machine route.

Publish a corrected version

Follow the Registry versioning rules and choose a version that will become the intended latest record. Avoid a prerelease ordering surprise that leaves the broken final version selected.

Verify Registry read-back

Confirm the latest public record now contains the intended route and stable server identity. Do not count a local publish success message as proof.

Verify the live route separately

Connect to the remote or install the package and exercise the MCP discovery path. Registry discoverability and runtime health remain separate verdicts.

Version trap

A metadata correction still has to become the latest version

Registry records are versioned. The official versioning guide allows metadata-only changes to use semantic prerelease versions, but normal SemVer precedence still matters. A prerelease such as 1.2.3-1 does not outrank an already published final 1.2.3. If the broken record is the final release, choose the next version deliberately rather than assuming any later publish timestamp will make a prerelease the selected latest record.

After publishing the correction, query the Registry again and verify the record marked latest contains the intended remotes or packages. Only then move on to live MCP connection testing.

Continue the implementation path