MCP Registries in 2026: Where to List Your Server for AI Tool Discovery

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 Desktop, Cursor, Windsurf, and custom agents can all connect to it with the right config. But no one knows it exists. The server answers initialize in 3 ms and exposes a dozen well typed tools, yet the tool discovery surface inside modern AI clients is not your homepage. It is a handful of public registries where agents browse capabilities and developers paste configs. "List of MCP registries 2026" has no canonical answer right now, so every operator reinvents the research. This post fixes that. Below are the four registries worth a submission in 2026, the metadata each one demands, a verified fetch of every homepage, and a minimal probe you can run against your own server before you submit it.

What an MCP registry is and why it exists

An MCP registry is a public directory that indexes Model Context Protocol servers so AI clients and their humans can find them by capability. The MCP specification, currently at version 2025-11-25, defines the wire protocol but says nothing about discovery. A server that speaks flawless JSON RPC still needs a place for agents to find its URL, read a description, and understand what tools it exposes. Registries fill that gap. Most index a server record containing name, transport type, tool list, auth requirement, homepage, repository, and a short capability description. Some are fully self serve. Some review submissions. A few simply crawl GitHub for MCP config signatures. In aggregate they are the MCP equivalent of npm search or the Postman public network. If your server is not in at least one, it is invisible to a meaningful slice of the agent tool market.

Ready to ship a production MCP server your agents actually reach? RoxyAPI exposes one MCP server per product. See pricing.

The four MCP registries worth submitting to in 2026

Verified fetch results from April 2026. Every row checked by direct HTTP fetch the day this post published.

Fetch status. mcp.so responded with its marketplace homepage and reports 20,222 MCP servers indexed at time of writing. smithery.ai responded with its publisher focused landing page and a CLI first distribution model via npm install -g @smithery/cli. glama.ai/mcp resolved but the fetched main content returned duplicated marketing copy with no catalog text exposed to the crawler, so the submission form position could not be captured from HTML alone. The punkpeye/awesome-mcp-servers repository resolved cleanly and its CONTRIBUTING.md was fetched. All four URLs are live and none redirected away from the advertised domain.

mcp.so: the largest public MCP marketplace

mcp.so calls itself a third party MCP marketplace and reports 20,222 servers indexed as of April 2026. That is the largest public directory we could verify. The site tabs featured, latest, client, hosted, and official collections on the homepage, which tells you the index is actively curated and not purely submission driven. Listings include a short description, the originating GitHub handle, and a direct link to the server project. For an API product, mcp.so is the single highest leverage submission because it is the registry most often cited when a developer types "list of MCP servers" into a search engine.

What to submit: server name, a one sentence capability description, tool count, transport type (Streamable HTTP or stdio), GitHub repository URL, homepage URL, and an optional icon. If your server lives behind auth, include the config snippet the user needs to register it in Claude Desktop or Cursor. mcp.so renders those snippets inline, which means a well written config is the landing page sell. One practical rule: list each product server separately if your product exposes per product endpoints. A single monolithic entry hides breadth from the category search.

smithery.ai: CLI first agent connectivity

smithery.ai takes a different angle. Rather than functioning only as a directory, it operates as a publisher platform with a CLI (@smithery/cli) and a managed auth layer called agent.pw. An agent connects once through Smithery and Smithery handles the OAuth flow, credential storage, and session retry. For MCP server authors this matters because a listing on Smithery is not just a directory entry. It is a distribution channel where your server gets invoked with auth already plumbed.

What to submit: a publisher account, a manifest describing the server name, description, tools, and auth method (API key, OAuth, none), plus a working server URL or npm package. Smithery supports both hosted and remote servers, so a Streamable HTTP endpoint like https://yourdomain.com/mcp/product is valid. If your server uses bearer tokens, specify that clearly in the manifest so Smithery can surface the right auth prompt to the end user at install time. The CLI flow lets you install your own server with smithery mcp add <name> to validate the submission before publishing.

glama.ai/mcp: the third major catalog

glama.ai runs a dedicated MCP section at /mcp. The page resolves and is linked from their primary product, which is an enterprise ChatGPT alternative. The MCP catalog is a secondary surface on an otherwise enterprise AI site, but it is routinely cited in "best MCP servers" roundups and does carry weight in LLM training corpora. Submissions are form based and manually reviewed.

What to submit: server name, description, repository URL, installation snippet, transport, tool count, and a one line capability summary. glama.ai tends to feature production quality servers with clear docs and working examples, so a submission that links a real README with an install guide is more likely to land than a raw git URL. If your server exposes multiple products under one domain, list them as separate entries with individual descriptions rather than bundling everything as "the XYZ multi tool server." Category search on aggregator sites favors focused listings.

punkpeye/awesome-mcp-servers: the GitHub list PR flow

The punkpeye/awesome-mcp-servers repository is the canonical GitHub awesome list for MCP. It is not a hosted registry. It is a curated README that developers, AI clients, and LLMs reliably read. Inclusion is a pull request against the main branch. The CONTRIBUTING.md is explicit about format: fork, branch, add one server per line in the correct alphabetical position under the correct category, commit with a clear message, open the PR. The maintainer notes a streamlined path for automated agent PRs: add the literal string 🤖🤖🤖 to the end of the PR title to opt in. Merging is fast tracked.

What to submit in the PR: the server name linked to its repository, a one line description of functionality, and the correct category placement. If your server covers a category that does not yet exist in the README, you are allowed to create one, but maintain alphabetical order across all categories. Descriptions should be concise and accurate. Reviewer concerns usually focus on dead links, wrong category, or hyped descriptions, so keep the entry factual and test every URL before pushing.

Preparing your MCP server for submission

Every registry wants the same metadata with cosmetic differences. Prepare it once, submit it four times. Before filing anything, verify your server actually serves the MCP spec correctly. The minimum JSON RPC 2.0 handshake a registry crawler or a curious agent will issue is an initialize request. This is the exact payload your server must accept and answer:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"registry-probe","version":"1.0.0"}}}

Post that body to your server URL and confirm the response includes a matching protocolVersion, your server name, and capability flags. Our own servers respond to that exact probe in under 5 ms warm. If your server answers correctly, the registry submission becomes paperwork rather than debugging. Here is the curl you can run against any MCP endpoint that speaks Streamable HTTP:

curl -X POST https://yourdomain.com/mcp/your-product \
  -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 successful response looks like {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-11-25","capabilities":{...},"serverInfo":{"name":"...","version":"..."}}}. If you get a 405, your transport is misconfigured. If you get a 401, auth is required at initialize, which most agents will reject. Keep initialize and tools/list public and require auth only on tools/call.

Submission checklist every registry will ask for

Collect this information once, store it in a text file, and paste it into every registry form or PR. Skip none of it. A listing missing auth type or transport information gets passed over inside agent clients that filter catalog entries programmatically.

• Name. The server display name. Short, product scoped, no vendor suffix.
• Description. One sentence describing what tools the server exposes and the domain it covers. Under 160 characters.
• Capabilities or tool list. Explicit list of tool names and one line descriptions. A server exposing get_daily_horoscope and post_birth_chart should say so.
• Transport type. Streamable HTTP, stdio, or SSE. For remote servers it is almost always Streamable HTTP in 2026.
• Auth method. None, API key, bearer token, or OAuth. If bearer, note whether the token goes in Authorization or X-API-Key.
• Example usage. One config snippet for Claude Desktop or Cursor that a user can copy paste.
• Homepage. Landing page for the product behind the server, not the registry listing itself.
• Repository. Public git URL. Required for most GitHub facing registries.
• License. MIT, Apache 2.0, commercial, or proprietary. Agents and human operators both filter by this.
• Contact. Maintainer email or a public issue tracker. Used when a registry runs a quality audit.

See the MCP architecture docs for how RoxyAPI structures every field above, and inspect a live Tarot MCP server or the corresponding REST API reference for a real example. Our starter templates include working Claude Desktop configs you can reuse verbatim.

Frequently Asked Questions

Q: How many MCP registries should I submit my server to? A: Four is the right number in 2026. Submit to mcp.so, smithery.ai, glama.ai/mcp, and open a PR against punkpeye/awesome-mcp-servers. Submitting to more than that hits diminishing returns quickly because the smaller directories share indexes, and a crowded listing with dead links hurts trust.

Q: Do MCP registries give SEO backlinks? A: It depends on the registry. GitHub hosted lists such as punkpeye/awesome-mcp-servers carry DoFollow links from github.com, which is durable. The hosted registries vary and their rel attribute can change without notice. Treat MCP registry submissions as agent discovery channels first and SEO backlinks second.

Q: What metadata do MCP registries require? A: Every registry wants name, description, transport type, auth method, tool list, homepage, repository, license, and an example config snippet. Prepare this metadata once and paste it into each submission form or PR. A server entry without auth or transport information is often skipped by automated filters inside AI clients.

Q: Is there a way to test my MCP server before submitting? A: Yes. Send a JSON RPC 2.0 initialize request to your server with protocolVersion: 2025-11-25 and confirm the response includes your server name and capabilities. The curl example above runs in one line. If the handshake passes, your server is ready for any registry crawler.

Q: Can I list the same server in multiple registries? A: Yes, and you should. Each registry has a different audience. Claude Desktop users browse mcp.so. Agent framework users reach for Smithery. Developers read awesome lists on GitHub. A single server listed across all four reaches an audience no single registry covers on its own.

Conclusion

MCP registries are where AI agents and developers actually discover tool servers in 2026. Submit to all four that matter, use the same prepared metadata pack for each, and keep your initialize handshake fast and correct. If you want to see a production reference, every RoxyAPI product ships its own MCP server listed across these directories and documented at /docs/mcp. Pricing and plan tiers are on the pricing page.