ManyCP is not affiliated with, endorsed by or sponsored by any directory, Docker, OpenAI, Anthropic or GitHub named here. Names are used to say which service a fact is about.
Smithery lists a remote MCP server by its URL. Before it lists it, it connects to the URL and reads the tools. When that read fails, the publish flow stops, and the message does not always say why. There are three causes in Smithery's own troubleshooting notes[1]: something in front of your server blocks the scan, the server asks for sign-in the way Smithery does not expect, or the server is not a URL server at all. This guide takes them in turn. For the other places to list, see all 26 directories compared.
What the scan does
You give Smithery a public HTTPS URL that speaks Streamable HTTP. Smithery scans the server to read its tools, prompts and resources for the server page[1]. A public server scans on its own. A server that needs sign-in asks you to authenticate so the scan can finish[1].
If the scan cannot complete, because of an auth wall, required configuration or something else, Smithery says you can give the metadata by hand in a server card[1]. That is the way round all three causes below.
Cause one: a bot block returns 403
Smithery sends its requests with the User-Agent SmitheryBot/1.0 (+https://smithery.ai), from Cloudflare Workers. Some firewalls block that by default. When the server refuses the scan, the deployment fails with Initialization failed with status 403[1].
Smithery names Cloudflare's Bot Fight Mode as one cause, next to IP allowlists that leave Smithery out[1]. Cloudflare says Bot Fight Mode issues challenges to traffic that looks like a known bot[2], and that it cannot be skipped with a WAF custom rule[2]. Smithery says the same for the free plan.[1] The options Smithery lists for the free plan are an IP Access Rule that allows Smithery's range, turning Bot Fight Mode off for the whole site, or a plan with Super Bot Fight Mode and a skip rule on the user agent[1]. Turning it off is a choice about your whole site, not only this scan.
You can also leave the firewall alone and serve a server card, below. Smithery then has nothing to scan.
Cause two: a server that needs sign-in
A server behind OAuth has to answer a request with no token the way the protocol says. The MCP authorization spec has the server return 401 Unauthorized with a WWW-Authenticate header that points to its resource metadata, and keeps 403 Forbidden for a token that is valid but not allowed[3]. Smithery uses the 401 to detect that the server supports OAuth, and says a server that answers 403 to an unauthenticated request is a common cause of the failed scan[1][4].
An unauthenticated request gets 401, not 403.
The 401 carries WWW-Authenticate with the address of the resource metadata[3].
Smithery lists OAuth support as a requirement for a server that needs authentication[1].
If you cannot change the status code, serve a server card.
The server card
A server card is a JSON file at /.well-known/mcp/server-card.json on your server. Smithery documents it as the way to give metadata by hand and skip the scan[1]. The shape on its page:
Server card shape, from Smithery's docs (placeholder values)
A real one is easier to read than a shape. ManyCP's own server serves one: manycp.com/.well-known/mcp/server-card.json[5]. It has the same top-level fields: serverInfo, authentication and the tools with their input schemas. It is one example of a card, not a check that Smithery accepts it.
Cause three: it is not a URL server
Publishing by URL needs Streamable HTTP[1]. A server that runs on your machine over stdio, from npm or PyPI, has no URL to scan. Smithery has a separate route for those: it distributes a pre-built MCPB bundle that clients download and run locally[1]. That is a different submission, with a bundle you build first. Everything above is about the URL route.
The steps, in order
These are the catalog's steps for Smithery. You press Continue yourself, and Publish too, where the wizard shows it. Nothing is listed until you do.
Sign in at smithery.ai with email, Google or GitHub.
Open smithery.ai/servers/new (Publish, then MCP).
Enter a Server ID (short and memorable, lowercase). Your account name is added in front.
Enter your MCP Server URL and click Continue. Smithery scans it for tools, prompts and resources.
The scan needs your tool list in public. No sign-in? It reads the tools as they are. Sign-in needed? Answer with a 401 (not 403) and OAuth discovery, or host a server card at /.well-known/mcp/server-card.json.
Command line instead: smithery mcp publish "<url>" -n @your-name/your-server.
What a server needs before step four, from the same catalog entry:
A Smithery account (email, Google or GitHub)
A remote server on public HTTPS that speaks Streamable HTTP (npm and stdio servers cannot be published by URL)
A public tool list, or a server card at /.well-known/mcp/server-card.json
If it needs sign-in: OAuth, and a 401 (not 403) for calls without a token
Your firewall lets SmitheryBot/1.0 in (Cloudflare Bot Fight Mode blocks it)
What ManyCP does here
ManyCP fills in every field and links straight to the form. You click send. On Pro, ManyCP files it by hand for you.
The Server ID and URL to paste
A server-card.json built from your listing and tools, to host if the scan cannot read them
The command line version with your URL
You do: sign in; host the server card if your server needs a token to list tools; click Continue. Smithery's scan runs on Smithery's side, so ManyCP cannot make it pass. It can only hand you the card to host.
When you don't need ManyCP
Your server scans cleanly. Paste the URL at smithery.ai and press Continue. That is the whole job.
You are listing one server on one directory. The form is short, and you sign in with your own account either way.
You can write the server card by hand. The shape above is the whole format.
ManyCP helps when the same server goes to several directories, or when the listing text has to stay the same in all of them. It costs $19 once per server, or from $9 a month[6]. The free checker shows where a repo is listed today. If you also need a Dockerfile for Glama, that is the next guide.
