MCP Registry Guide 2026: Where and How to List Your Server
Where to list your MCP server in 2026. Publish to the official MCP Registry, prove your namespace, and propagate to downstream directories. By RoxyAPI.
TL;DR
- The MCP ecosystem consolidated in 2026 around one canonical directory: the official MCP Registry at registry.modelcontextprotocol.io. Publish there first.
- Publishing is a CLI push of a small server.json, with namespace ownership proven by a GitHub login or a DNS record. Downstream directories and newsletters ingest the registry automatically, so one publish propagates outward.
- A listing needs the same metadata everywhere: a name, a display title, a capability description under 100 characters, the transport, the auth method, and a rich per tool description.
- Verify the JSON-RPC initialize handshake before you publish. Ship a production MCP server with RoxyAPI.
About the author: Brett Calloway is a Developer Advocate and AI Integration Specialist with 12 years of experience building APIs and developer tooling, including three years focused on AI native infrastructure for spiritual and wellness applications. He has led developer relations at two Series B SaaS companies and spoken at PyCon and JSConf on building context rich AI agents using Model Context Protocol.
You shipped an MCP server. Claude, Cursor, Windsurf, ChatGPT, and custom agents can all connect to it with the right config, yet no one knows it exists. The server answers initialize in a few milliseconds and exposes a dozen well typed tools, but the tool discovery surface inside modern AI clients is not your homepage. For most of 2025 the answer to "where do I list my MCP server" was a scattered set of community directories, each with its own form and its own metadata quirks. In 2026 that consolidated: the protocol grew an official registry, and the wider ecosystem now reads from it. This guide covers the canonical publish path, what a professional listing contains, how to verify your server before you submit, where listings surface once you do, and the mistakes that keep a working server invisible.
What is the official MCP Registry and why it matters
The official MCP Registry at registry.modelcontextprotocol.io is the canonical, protocol maintained directory of Model Context Protocol servers. The MCP specification, currently version 2025-11-25, defines the wire protocol but historically said nothing about discovery, so a server that spoke flawless JSON-RPC still had nowhere central to be found. The official registry closes that gap. It stores a record per server: name, title, description, transport, the remote URL, and the auth a client needs. It matters because it is the source the rest of the ecosystem reads. Community directories, MCP newsletters, and client side catalogs ingest it on a regular cadence, so a single publish there propagates to several downstream surfaces without a second form. Think of it as npm search or the Postman public network for agent tools. If your server is only reachable from your own docs, it is invisible to the slice of the agent market that browses the registry.
Ready to ship a production MCP server your agents actually reach? RoxyAPI exposes one Remote MCP server per domain, from Western astrology to tarot and numerology, each documented in the MCP architecture reference. See pricing.
How to publish to the official MCP Registry
You publish with the mcp-publisher CLI against a server.json file, the registry schema dated 2025-12-11. The file declares your server name, a version, a short capability description, an optional display title, a websiteUrl, and a remotes block carrying the Streamable HTTP URL plus any header a tool call requires. Namespace ownership is proven one of two ways. A GitHub login authorizes an io.github.your-account namespace, which suits an individual or an open source project. A DNS TXT record at your domain apex authorizes a reverse DNS namespace such as com.yourbrand, which reads like a real product and is the right pick for a company. Run the login, then publish. Updating an existing entry needs a new version, so bump the patch number whenever the copy changes. That is the whole flow: one file, one namespace proof, one command. Because the copy is not generated from your OpenAPI spec, treat each server.json as the source of truth for its own listing text.
What a professional MCP listing contains
Every registry and downstream directory wants the same metadata, so prepare it once. The parts that decide whether an agent picks your tool are the description and the tool list, not the transport boilerplate. Keep the top level description capability first and under 100 characters, because that string is exactly what agents and directory quality scorers read. Give each tool a clear name, a short human title, and a rich description that states what it does, what it returns, and when to use it. A bare title used as the description is what earns a low quality grade on the catalogs that score listings.
| Field | What to put | Why it matters |
|---|---|---|
| Name | Programmatic id, product scoped | Stable identifier agents call |
| Title | Human readable display name | Shown in client catalogs |
| Description | Capability first, under 100 chars | The string agents rank on |
| Transport | Streamable HTTP for remote servers | Filters which clients can connect |
| Auth | None, API key, or bearer token | Clients skip entries missing this |
| Tools | Name, title, and a rich description each | Drives tool selection quality |
| Homepage | The product behind the server | Human trust signal |
| License | Clear license string | Operators filter on it |
Verify your server before you publish
Before you file anything, confirm your server serves the spec. The minimum handshake a registry crawler or a curious agent issues is a JSON-RPC 2.0 initialize request. Post it to your endpoint and confirm the response echoes a matching protocolVersion, your server name, and the capability flags.
curl -X POST https://roxyapi.com/mcp/astrology \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"registry-probe","version":"1.0.0"}}}'A healthy server answers with its identity and capabilities:
{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-11-25","capabilities":{"tools":{}},"serverInfo":{"name":"roxy-astrology","version":"2.0.0"}}}If you get a 405, your transport is misconfigured, because Streamable HTTP is POST only. If you get a 401 on initialize, auth is gated too early and most agents will reject the server. Keep initialize and tools/list public and require auth only on tools/call. Then run tools/list and read your own tool descriptions the way an agent would, or open the interactive API reference to see the same shape.
Where your listing shows up downstream
Once you publish to the official registry, your listing propagates without extra work. Downstream directories and MCP newsletters ingest the registry on a regular cadence, so a hosted server you published shows up across several catalogs from that one entry. Two listing shapes exist and it helps to know which you have. A hosted server reachable at a URL appears as a remote connector, mirrored from the registry. An open source server in a public repository can appear as a repository based listing when a directory crawls GitHub for MCP config, even if you never submitted it. Claiming ownership differs by shape: a hosted connector is claimed at the domain level with a small well known file that names the account behind it, while a repository based listing is claimed at the repository root. Either way, the copy that gets you picked is the same clear description and clean tool list. This is why you publish once, verify the copy, and let the ecosystem carry it rather than filling a dozen forms by hand.
Common reasons a server never gets discovered
Most invisible servers fail on the same handful of avoidable points. Fix these before you blame the directories.
- Auth gated at initialize. Agents reject a server that returns 401 on the handshake. Gate auth on tools/call only, and keep initialize and tools/list public.
- Terse tool descriptions. A tool named get_thing with the description "get thing" reads as noise. Write what it does, what it returns, and when to use it, and the quality score follows.
- A slow or flaky handshake. If initialize or tools/list times out or errors intermittently, crawlers give up and clients drop the server. Keep the handshake fast and stateless so every probe succeeds.
- No namespace proof. Without a GitHub login or a DNS record you cannot publish to a branded namespace, and an unclaimed listing cannot be edited.
- A dead homepage or repository link. Reviewers and crawlers both drop entries with broken links, so test every URL before you publish.
Frequently Asked Questions
Q: Where should I list my MCP server in 2026? A: Publish to the official MCP Registry at registry.modelcontextprotocol.io first. It is the canonical, protocol maintained directory, and downstream directories and newsletters ingest it automatically, so one publish propagates to several surfaces. Only pursue individual directory forms after that, and only where the audience is worth the manual effort.
Q: How do I publish to the official MCP Registry? A: Use the mcp-publisher CLI against a server.json file (schema 2025-12-11) that declares your server name, version, description, and a remotes block with your Streamable HTTP URL. Prove namespace ownership with a GitHub login for an io.github namespace or a DNS TXT record for a reverse DNS namespace like com.yourbrand, then run publish.
Q: Do MCP registries give SEO backlinks? A: Some do and some do not, and the rel attribute can change without notice, so treat registry listings as agent discovery channels first and SEO second. The durable value is being present in the source that clients and downstream directories read, not a single backlink.
Q: How do I test my MCP server before submitting? A: Send a JSON-RPC 2.0 initialize request with protocolVersion 2025-11-25 and confirm the response returns your server name and capabilities. The one line curl above runs it. Keep initialize and tools/list public and gate auth only on tools/call, or agents will reject the server at the handshake.
Q: What transport should my MCP server use for a registry listing? A: For a remote, hosted server, use Streamable HTTP, the standard for remote MCP in 2026. Stdio is for local servers a user runs on their own machine and is not reachable from a registry URL. Declare the transport in your listing so clients know how to connect before they try.
Conclusion
The discovery story simplified in 2026. Instead of chasing a dozen directory forms, you publish once to the official MCP Registry, prove your namespace with a GitHub login or a DNS record, and let the downstream ecosystem ingest it. Keep the handshake fast and public, write a capability first description and a rich per tool description, and verify the initialize probe before you file. If you want a production reference, every RoxyAPI domain ships its own Remote MCP server, documented at /docs/mcp with a live API reference and reusable starter templates. Pricing and plan tiers are on the pricing page.