How do I make an MCP server discoverable?

Publish accurate server metadata, expose a valid package or remote transport, authenticate the namespace, publish the server to the official MCP Registry, verify that record through the Registry API, and then extend distribution through relevant third-party MCP directories. Republish only when the public descriptor materially changes.

Can I publish an MCP server to the official Registry without GitHub OAuth?

Yes. The official MCP Registry publisher supports domain-based DNS and HTTP authentication for custom-domain namespaces. DNS authentication uses a public-key TXT proof on the domain, while HTTP authentication uses a public proof at /.well-known/mcp-registry-auth. Keep the private signing key secret.

Where does the MCP Registry DNS verification TXT record go?

Current official Registry documentation says the MCPv1 TXT proof belongs on the apex of the domain, such as example.com, not under selector-style names such as _mcp-auth.example.com or _mcp-registry.example.com. Remove stale old proof records when rotating keys.

Where can I submit an MCP server?

Start with the official MCP Registry as the canonical public metadata record. Third-party directories can add reach after that. Check each directory and its submission queue for the exact server, domain and endpoint before submitting, and do not create duplicate listings.

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.

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

No. Registry or directory presence 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, prove the namespace you own, register the server under one stable identity, keep versions current, and then distribute that canonical identity through directories where MCP users actually look.

Published 11 September 2026 · updated and sources checked 12 September 2026

1 identity

Keep one stable MCP server name across versions

2 auth paths

Custom domains can use DNS or HTTP verification

0 repeats

Do not resubmit a pending or already-correct listing

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 GitHub identity for the appropriate GitHub namespace, or the Registry's DNS/HTTP domain-authentication path for a custom-domain namespace.

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 publisher message alone as proof that clients can discover the intended record.

Extend distribution once

Check relevant third-party MCP directories for an existing listing first. Submit through the directory's documented route only when absent, and record the pending/live state.

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 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 →

Custom-domain authentication

You can publish an MCP server without GitHub OAuth

The current official mcp-publisher supports domain-based authentication for custom-domain namespaces. DNS authentication uses mcp-publisher login dns; HTTP authentication uses mcp-publisher login http. Both prove control of the namespace without making a GitHub identity the ownership anchor.

For DNS authentication, current Registry documentation says the v=MCPv1 TXT proof belongs on the apex of the domain — for example, example.com — not under selector-style names such as _mcp-auth.example.com or _mcp-registry.example.com. If a key is rotated, remove the stale proof record instead of leaving multiple old keys for the verifier to try.

For HTTP authentication, publish the public proof at https://example.com/.well-known/mcp-registry-auth. The Registry CLI currently supports Ed25519 and ECDSA P-384 signing, and the official documentation also describes Google KMS and Azure Key Vault signing paths. Keep the private key out of source control, logs and public documentation.

DNS proof

example.com. IN TXT "v=MCPv1; k=ed25519; p=PUBLIC_KEY"
mcp-publisher login dns --domain example.com --private-key "$MCP_PRIVATE_KEY"

HTTP proof

GET https://example.com/.well-known/mcp-registry-auth

v=MCPv1; k=ed25519; p=PUBLIC_KEY

Official Registry authentication guide →mcp-publisher CLI reference →Official Registry GitHub Actions guide →

Directory distribution

Where to submit an MCP server after the canonical Registry record exists

Third-party MCP directories solve a different discovery problem from the official Registry. They add human search, categories, popularity views, compatibility notes and editorial context. That can put a server in front of buyers who would never query Registry APIs directly, but the downstream listing should still point back to the same server identity and live transport.

MCP.so is one current example. At the 12 September 2026 check, its long-running GitHub issue titled Submit Your MCP Servers here remained open and explicitly asked publishers to leave MCP server links for visibility on MCP.so. Treat a submission as pending distribution until the directory actually publishes it; a comment alone is not a visitor, installation or conversion.

Before submitting

Search the directory and its submission queue for the exact server name, domain and remote endpoint.

In the listing

Disclose affiliation, use the canonical MCP endpoint, describe concrete outcomes and avoid unsupported adoption claims.

After submitting

Record pending/live state and wait for maintainer action. Do not create duplicate entries merely to chase visibility.

MCP.so public submission thread →Browse MCP.so →

Version drift

A server can stay online while its discovery record goes stale

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 directories	Additional reach, search UX, compatibility checks, curation 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, distribute once, probe, then wait for change

on release or material descriptor change:
  validate server.json
  authenticate the namespace through the supported path
  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
  update downstream listings only where materially stale
on a new directory opportunity:
  search for existing server/domain/endpoint first
  submit once through the documented route
  record pending/live state
otherwise:
  do not republish or resubmit merely to create activity

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 →Verify an MCP server before connecting →Inspect zFinia API services →

Sources