How do I make an MCP server discoverable?

Publish accurate server metadata, expose a valid package or remote transport, publish the server to the official MCP Registry, verify the registry record through its API, and republish a new version whenever the public descriptor materially changes. Third-party catalogs can extend reach but should not replace the authoritative registry record.

What is server.json in the MCP Registry?

server.json is the publication document used by the MCP Registry. It identifies the server namespace, description and version and describes installable packages, remote endpoints, or both. Registry publishing validates the document and verifies ownership of the namespace and referenced artifacts.

How do I update an MCP server in the Registry?

Change the server version and any updated descriptor fields, validate the new server.json, publish the new version through the existing authorized publisher path, then query the Registry API and confirm the intended version is active and treated as the latest record. Automating publication from tagged releases reduces stale listings.

Does listing an MCP server in a directory prove that it works?

No. A registry record improves discovery but does not prove current reachability, tool quality, authorization behavior, payment behavior or successful delivery. Buyers should verify the live endpoint and tool contract separately.

Editorial

Research guide · MCP discovery

How to make an MCP server discoverable

A working MCP endpoint can still be invisible to buyers. Discovery is a separate contract: publish machine-readable metadata, register the server under one stable identity, keep versions current, and verify what the registry actually exposes.

Published 11 September 2026 · sources checked 11 September 2026

1 identity

Keep one stable MCP server name across versions

2 proofs

Verify both registry presence and live runtime behavior

0 shortcuts

A directory listing is not a successful tool call

Discovery checklist

Seven steps from working server to discoverable server

Describe the outcome

Use a short description that says what the server actually lets an agent do. Discovery systems cannot select a useful tool from vague branding copy.

Publish a valid server.json

Keep the namespace, version, package identifiers, remote URLs and transport types aligned with the thing clients can actually install or call.

Prove namespace ownership

Use the Registry's supported authentication path for the namespace you chose. Custom-domain namespaces require domain ownership; GitHub namespaces use GitHub identity.

Publish to the official Registry

Treat the official MCP Registry as the canonical public discovery record, then use compatible downstream catalogs as additional distribution rather than separate identities.

Verify the record by API

Search the registry for the exact server name after publication. Do not treat a successful CLI message alone as proof that clients can discover the intended record.

Republish material version changes

If the public descriptor, package, remote URL or capability set changes, publish a new version and verify that the latest record moved with it.

Probe the live server separately

Registry presence is discovery evidence, not runtime evidence. Test initialize, tools/list and the intended authorization or payment handoff independently.

The authoritative layer

The official MCP Registry is a discovery record, not a health check

The Model Context Protocol project describes its Registry as an open catalog and API for publicly available MCP servers. Publication revolves around a versioned server.json document and an ownership check for the chosen namespace. Servers can point at installable packages, remote transports, or both.

After publishing, verify the exact server name through the Registry API. That check answers a narrow but important question: can a client discover the metadata you intended to publish? It does not answer whether the remote endpoint is reachable now, whether tools/list succeeds, or whether a paid tool will deliver the promised result.

Official MCP Registry publishing quickstart →Official Registry →

Version drift

A server can stay online while its discovery record goes stale

This is not just a theoretical failure mode. A 2026 longitudinal study of the official MCP Registry reconstructed 120 observations over 88.6 days and found that descriptor changes were unevenly distributed. The practical implication for publishers is simple: do not assume a once-published record will keep describing a changing server. Bind registry publication to material descriptor or release changes, then verify the new record after publication.

Read the MCP registry-drift study →

What belongs in discovery metadata

• one stable namespaced server identity;
• a concrete outcome-oriented description;
• the current semantic version;
• package identifiers or the canonical remote URL;
• the actual transport a client should use;
• repository or ownership information where supported.

What should be verified at runtime

• initialize/handshake succeeds;
• tools/list returns the intended current tools;
• input schemas match the public description;
• authentication or payment challenges are expected;
• tool execution returns the documented result;
• browser CORS exists only if direct browser clients are intentionally supported.

Registry map

Use one canonical record, then extend distribution

Surface	Useful for	Do not confuse it with
Official MCP Registry	Canonical public MCP server discovery metadata and versioned publication.	A live reliability, reputation or payment-delivery guarantee.
Google Cloud Agent Registry	Centralized discovery and management of MCP servers and tools inside Google Cloud environments.	A replacement for the public MCP Registry's publisher identity.
Third-party MCP catalogs	Additional reach, search UX, compatibility checks and downstream discovery.	Proof that the listing is current, independently used or economically valuable.

Google Cloud Agent Registry MCP documentation →

Minimal verification loop

Publish, read back, probe, repeat only when something changed

on release or material descriptor change:
  validate server.json
  publish new version through the authorized publisher
  query registry by exact server name
  require intended version/status in the read-back
  probe live initialize + tools/list
  record the result
otherwise:
  do not republish merely to create activity

The same rule applies to downstream directories: update because the machine contract changed or because a listing is wrong, not because repeated submission feels like distribution.

See a live machine surface

Inspect zFinia's MCP and machine-readable contracts

zFinia publishes a remote MCP endpoint alongside OpenAPI, an agent descriptor and x402 discovery metadata. Treat them as inspectable implementation surfaces, not as evidence of independent demand.

MCP remote →OpenAPI →Agent descriptor →x402 discovery →x402 discovery guide →Verify before paying →

Sources