How to Launch an MCP Server (Not Just Publish One)

Publishing an MCP server takes ten minutes. Getting it used is the other job. The registry steps, the pre-flight checks, and what 53 endpoints showed.

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 53 real endpoints between 20 July and 5 August 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 our 82 checks, 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, documented separately.

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 14 servers we connected to on 5 August 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. Every one of the 288 tools in that sample carried a description. 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 82 checks against 53 endpoints between 20 July and 5 August 2026, auth_required came back 40 times against 29 successful connections. Only 13 of those 82 described something genuinely wrong: 4 protocol errors, 3 addresses serving a web page instead of an endpoint, 2 blocked by our own outbound guard, 2 unreachable, and 2 that did not resolve.

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.

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.

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.