Where to publish your MCP server

You built an MCP server. Now you want people — and their agents — to find it. Search “where to publish an MCP server” and you get a dozen directories, each asking for a slightly different submission. It looks like a chore list. It mostly isn’t.

Here is the map, and the short version first: publish once to the official registry. Most directories mirror it. The work is getting one listing right, not ten.

The hub: the official MCP registry

The Model Context Protocol registry is the canonical index maintained by the MCP project. It is the one that matters, for one reason: the major clients and most third-party directories read from it. Get in here and you propagate almost everywhere else for free.

Publishing is a CLI flow, not a web form:

1. Write a server.json describing your server — name, description, the package (npm/PyPI/OCI) or remote endpoint, and how to run it. It follows the published server.schema.json.
2. Claim a namespace. Two kinds: io.github.<you>/<server> (proven by your GitHub identity) or a reverse-DNS namespace on a domain you own (dev.mcpgrade/mcp), proven by a DNS TXT record. The domain namespace signals you control the project.
3. Publish with the mcp-publisher CLI. It authenticates, validates against the schema, and pushes the entry.

Two details people miss:

• Link the package back. Put an mcpName field in your package.json (or the PyPI equivalent) matching your registry name. It ties the code to the listing and is used to verify ownership.
• Keep the description tight. There is a hard character limit (100), so write the sentence that makes someone install, not a paragraph.

The package registries: npm and PyPI

If your server is a local (stdio) server, its code still lives on npm or PyPI — that is what actually gets installed. The registry entry points at the package; it does not replace it.

This is not a separate “MCP directory,” but it is where an install command resolves, and both npm and PyPI are searchable in their own right. Publish the package, then reference it from server.json. For remote (hosted) servers there is no package — the registry entry points at your HTTPS endpoint instead.

The spokes: third-party directories

These are the aggregators and marketplaces people browse. The important thing about almost all of them in 2026: they ingest the official registry. You do not submit to each one; you appear once you are in the registry, sometimes within hours.

A non-exhaustive map:

Directory	What it is	How you get in
Smithery	Large marketplace, hosted deploys + config UI	Registry ingest + connect a repo
Glama	Server index with quality signals	Registry ingest + submissions
PulseMCP	Directory + newsletter, high traffic	Registry ingest + submissions
mcp.so	Community directory	Registry ingest + submissions
Docker MCP Catalog	Containerized servers for the Docker ecosystem	Curated / submission
Client directories (Claude, VS Code, Cursor, Windsurf)	In-product “add a server” surfaces	Read from the official registry

Two takeaways. First, the registry is upstream of most of this — fix your listing there and it propagates. Second, a few directories (Docker’s catalog, some client “featured” surfaces) are curated, so being in the registry gets you listed but not featured; featured placement is editorial and you earn it with a server people actually use.

GitHub still matters

Two GitHub habits help discovery independent of any registry:

• Tag your repo with the mcp-server topic.
• Get into the community “awesome” lists (the largest is awesome-mcp-servers) via a pull request. These rank well in search and are how a lot of people still browse.

Publish clean, not just fast

Getting listed is the easy half. The half that decides whether someone keeps your server installed is whether it holds up when they look closely — and increasingly, “they” is an agent checking before it wires you in.

A few things that cost nothing and matter before you publish:

• Never take a secret as a tool parameter. API keys, tokens, passwords belong in the environment, not in a tool’s input schema where the model holds them.
• Keep tool descriptions clean. No imperatives aimed at the model (IMPORTANT:, “ignore previous…”), no URLs you would not want an agent to fetch. The description field is read by the model every time; treat it as an interface, not a scratchpad.
• Declare your auth honestly. If you are a remote server, publish your OAuth discovery metadata so clients — and scanners — can see it. Silent auth reads as no auth.
• Make yourself inspectable. A server whose real tool list can be seen earns a stronger signal than one that is a black box. Ship source, or a resolvable package, not just a binary.

That last section is, admittedly, our beat: mcpgrade grades every server in the registry A–F on exactly these things. You do not have to use it. But whether you check or not, the moment you publish, people and agents start evaluating your server — so it is worth publishing something that reads well under that light.

The checklist

1. Write server.json, claim a namespace (GitHub or your domain).
2. Publish the package to npm/PyPI (stdio servers) with a matching mcpName; or point the entry at your HTTPS endpoint (remote servers).
3. mcp-publisher publish. You are now in the hub.
4. Tag the GitHub repo mcp-server; PR into awesome-mcp-servers.
5. Wait for the directories to mirror you. Check a couple after a day.
6. Before all of it: publish clean. It is the difference between listed and trusted.

Directory landscape as of July 2026 — it moves fast. When in doubt, the official registry is the one to keep current; the rest largely follow it.