How to publish an MCP server, and get anyone to install it

The six mcp-publisher steps, checked against the official docs. Then the job every tutorial skips: getting somebody to actually install the thing.

MCP Hunter team Updated 11 September 2026 9 min read mcp registry publishing launch

Launching an MCP server is two separate jobs. Publishing is the documented one: you ship your package, point the registry at it, and you are listed in about ten minutes. Getting anyone to install it is the other, and it is the job the tutorials skip.

This page covers both. The publish flow below is checked against the official registry documentation rather than paraphrased, and the pre-flight section comes from connecting to 55 real endpoints between 24 July and 2 September 2026, including the single most common result, which most makers read as a failure and should not.

TL;DR:

The registry stores metadata, not your code. Your package goes to npm first, or your endpoint stays where it already is, and the registry points at it [1].
Being listed is not being found. One directory alone listed 22,085 servers when we checked on 6 August 2026 [2].
Connect to your own server before launch day, the way a client will. The median server we reached exposed 4 or 5 tools, so a broken tool list is obvious to anyone who looks.
A 401 is not a broken server. It was the most common outcome across the 55 endpoints we checked, ahead of successful connections.

What does launching an MCP server actually mean?

Two things that get treated as one. Publishing makes your server installable: a package on npm, an entry in a registry, a URL that answers. Launching means someone finds it, installs it, and keeps it. Publishing is a CLI command. Launching is distribution, and nothing in the toolchain does it for you.

Search results for this question are almost entirely about the first job. That is not wrong, it is just incomplete, and the gap matters more every month: the registry that hosts your metadata is the same registry hosting everyone else's.

How do you publish an MCP server to the official registry?

Six steps with the official mcp-publisher CLI. The important thing to understand first is what the registry actually stores: "The MCP Registry only hosts metadata, not artifacts" [1]. Your code lives on npm or PyPI or at your own URL. The registry is an index that points at it.

For a TypeScript server published to npm, the flow is:

Add the verification marker. The registry checks that a package matches its metadata, which for npm means an mcpName property in package.json [1].
Publish the package to npm with npm publish --access public. This has to happen before the registry step, because there is nothing to point at otherwise.
Install mcp-publisher from the release binary or Homebrew.
Run mcp-publisher init to generate a server.json template, then edit the name, description, repository, version and transport.
Authenticate with mcp-publisher login github, which prints a device code.
Run mcp-publisher publish.

The step that trips people is naming. With GitHub authentication your server name must start with io.github.your-username/, and the name in server.json "must match the mcpName property in package.json" [1]. A mismatch produces "You do not have permission to publish this server", which reads like an auth problem and is actually a naming problem.

Two caveats worth knowing before you build a release process around this. The registry is explicitly "currently in preview", with breaking changes or data resets possible before general availability [1]. And this flow assumes a package. A remote server that lives at a URL follows a different path.

What should you check before launch day?

Connect to your own server the way a client will, from outside your machine, and read what comes back. Not curl against the health endpoint: a real initialize handshake followed by a real tools/list call. Almost every launch-day embarrassment is visible in that one exchange.

Four things worth reading in the response:

Tool count. Across the 14 servers we connected to between 24 July and 2 September 2026, the median exposed 4 or 5 tools and 11 of the 14 exposed 10 or fewer. A focused server is normal. If your list is empty, that is the launch blocker.
Descriptions. All 14 of those servers carried descriptions on their tools, 288 tools in total. It is the field a model reads when deciding whether your tool is the right one, so an undescribed tool is close to unusable.
The revision you negotiate. Five of those 14 servers answered on a protocol revision older than the current one. Yours may not be the revision you think.
Whether you paginate. None of the 14 returned a nextCursor, which is exactly why clients ship without cursor handling and break on the first server that does.

You can run that exchange against any public endpoint with our connection tester, which returns the same dated record we keep: outcome, negotiated revision, tool count, tool names, and one round trip in milliseconds. If you want to know what each field in the response means before you read one, the tools/list field reference has the whole shape.

Why is a 401 not a broken server?

Because the server answered. A 401 or 403 comes from software that is running, listening, and declining this particular caller, which is different in kind from an address that times out or does not resolve.

This is the result makers most often misread, and it is the most common one we see. Across 55 endpoints checked between 24 July and 2 September 2026, counting each address once by its most recent check, auth_required came back 32 times against 14 successful connections. Only 9 of the 55 described something genuinely wrong, or an address that was never an endpoint: 3 protocol errors, 3 addresses serving a web page instead of an endpoint, 2 that did not resolve, and 1 unreachable.

If your server guards itself, it is behaving the way the specification expects an internet-facing server to behave. What you should check is that an anonymous caller gets a clean 401 pointing at your authorization server, rather than a timeout or a 500.

The other outcomes are worth knowing before launch day too, because two of them look like a broken server and are not. We wrote up why an MCP server fails to connect against the same corpus, including the status codes where the specification tells you to send a second request before concluding anything.

Where do you list an MCP server?

The official registry first, since it is the one other tools read from, then the aggregators. Most directories pull metadata from GitHub or the registry automatically, so listing is often a form submission or nothing at all.

Be honest with yourself about what that buys. PulseMCP alone listed 22,085 servers when we checked on 6 August 2026 [2], updated daily. Directory listings are table stakes: they make you findable by someone already searching your exact category, and they do essentially nothing for a server nobody knows to search for. If your entire launch plan is "submit to the directories", your launch plan is a lottery ticket.

Worth knowing before you chase badges: the word "verified" means something different on each of them. One checks that you own the domain you published under, one runs your server and grades how well its tools describe themselves, one estimates your weekly traffic. What each MCP directory's badge is derived from sets the six labels side by side, so you can tell which one is worth the submission.

What does an actual launch day look like?

A dated event with an audience, rather than a row appended to a catalog. That means picking a day, telling the people who already follow you, and putting the server somewhere people look at new things specifically because they are new.

That last part is what MCP Hunter does: one ranked board per week, archived permanently at its own URL. Being on a launch board is not better than being in a catalog, it is a different mechanism. A catalog answers "what exists in this category". A launch board answers "what shipped this week", which is a question people check on a schedule.

Two things are worth knowing before you submit a product, because both are unusual. Your product is not required to have a URL we can reach: stdio servers are accepted, and the command is stored and displayed rather than run. And when we can connect, the listing carries exactly what the server returned on the date we asked it, and when we cannot, it carries no such line at all rather than a vaguer version of one.

What we changed when our own rule rejected our own product

We removed our own submission requirement on 6 August 2026, after it blocked the product we run ourselves. That is worth writing down, because it explains what the listings here actually claim.

The original rule was that every listed product had to expose an HTTP endpoint we could connect to. It sounded like a quality bar and it worked as one, right up until it rejected AppScreenshotStudio, whose MCP server is real, published, documented, and used. It is also stdio only, so there was no URL to submit and never would be. The rule was not filtering bad products. It was filtering the transport most of the ecosystem actually ships, and testing a stdio server safely means running a command a stranger chose, which we will not do.

So the check stopped being a door. Anyone may submit, a human reviews every submission, and the connection test now records evidence rather than granting entry. The honest version of what a listing here means is narrower than what we used to say, and it is still something a catalog cannot say: a person looked at this, and when we connected to it, this is exactly what it returned on that date.

If you have shipped something, put it in a week. It is free, it takes one form, and the worst outcome is a dated record of what your server answered.