You built an MCP server. Now nobody can find it. The official MCP Registry — launched in preview in September 2025 and grown to thousands of entries — is the canonical place agents and clients look to discover and install servers. Getting listed is the difference between a server that exists and one that gets used. Here's how publishing works in 2026.
What the registry is, and why it's the one that matters
Think of it as an app store for MCP servers: a single authoritative list that downstream consumers read from. The key fact is the fan-out. The official registry feeds named consumers — Smithery, PulseMCP, Docker Hub, Anthropic and GitHub all pull from it — and the GitHub MCP Registry is rendered natively inside VS Code's Extensions view under @mcp. Publish once to the source of truth and you propagate to the sub-registries that developers actually browse, rather than submitting to each one by hand.
The server.json file
Publishing centres on a server.json manifest describing your server: its name, description, the package or remote endpoint it ships as, and how a client should run it. There are two ways it reaches the registry. You can publish the manifest to the registry directly, or — for automatic discovery — host it at /.well-known/mcp/server.json on your server's domain, where the registry can find and verify it without you submitting anything. The well-known path is the more durable option because it keeps the canonical description next to the server itself, so it stays in sync as you ship updates.
Server Cards: discovery without connecting
The 2026 roadmap pushes this further with MCP Server Cards — a proposed standard for exposing server metadata at a .well-known URL so browsers, crawlers and registries can read a server's capabilities without first connecting to it. That's a meaningful shift: today a client often has to handshake with a server to learn what it does, which is slow and a little risky for discovery. Server Cards let the ecosystem index capabilities the way search engines index pages — cheaply, at scale, and ahead of any connection. If you're publishing now, structuring clean metadata sets you up for this.
Get the metadata right
Discovery quality is mostly metadata quality. Write a description that says what the server does in the words a developer would search for, not marketing copy. List the tools accurately. Pin a clear package identifier and version so installs are reproducible. Declare the transport honestly — and if it's remote, make sure it's on Streamable HTTP, not deprecated SSE. A well-described server installs better; a vague one disappears into the thousands of entries. For how consumers evaluate what they list, see how to vet MCP servers.
Going further
For the standards behind all this, read open MCP registry standards and the MCP server discovery protocol. Comparing where to list, see MCP server marketplace comparison and mcp.so vs PulseMCP. Building the server itself? Start with build your first MCP server in Node.js, then deploy it to Docker and Cloudflare. Ready to ship? Submit it to our directory too.