I spent yesterday afternoon trying to list one MCP server on three catalogs: Glama, Smithery, and mcp.so. I assumed they would be variations of the same thing — git URL goes in, listing comes out.

They are completely different services with completely different ideas about what an MCP server is. If your server only speaks one transport, exactly one of them will Just Work and the other two will reject you in different ways.

This is what each one actually does at scan time.

Glama: clones the repo, runs stdio

Glama scrapes public GitHub for MCP-shaped repos automatically. My server showed up on glama.ai/mcp/servers/kfuras/notipo-app without me submitting anything. Claiming it then unlocks an admin where you control the build.

When you trigger an evaluation, Glama spins a debian:trixie-slim container with Node 26, mcp-proxy@6.4.3, pnpm@10.14.0, and uv preinstalled, then does this:

git clone https://github.com/kfuras/notipo-app .
git checkout <pinned commit>
<run your build steps>
<run your CMD>

Your CMD has to be a local stdio MCP server. mcp-proxy bridges Glama's introspector to whatever process you start. The first thing I tried was pointing CMD at the live HTTPS endpoint:

["mcp-proxy", "--transport", "streamableHttp", "https://notipo.com/api/mcp"]

Glama rejected this with a one-line error:

CMD cannot contain URLs. The Dockerfile must be used to build and launch the server locally, not to connect to an external endpoint.

So if you only have an HTTP server, you need a second entrypoint for catalogs. I added apps/api/src/stdio-mcp.ts to the repo — a standalone file that imports @modelcontextprotocol/sdk/server/stdio.js, registers the same 13 tool schemas as the HTTP route, and stubs the handlers so any real tools/call returns "use the hosted endpoint instead." Catalogs only call tools/list for scoring, so the stubs never run in practice.

The other Glama gotcha: the build container has no Postgres, no env vars, no database. If your npm start boots a real API, it crashes before the MCP route mounts. I gated all the production plugins behind if (process.env.DISCOVERY_ONLY === "true") return early and set the env var in the placeholder-parameters form on Glama.

Once the build succeeds, the scoring is split into License, Quality, and Maintenance, each graded A through F. License is auto-detected from your SPDX file. Maintenance is commit activity. Quality is "did the introspection actually return tools." A score of A across all three is what awesome-mcp-servers' PR bot requires for badge submission.

Smithery: proxies your HTTPS endpoint

Smithery takes the opposite approach. The "External URL" deployment type is a Gateway proxy — you paste a public HTTPS URL into a form at smithery.ai/new and Smithery's runtime forwards tools/list (and any future client traffic) to that URL.

No build, no clone, no container on your side. If your server already serves Streamable HTTP MCP at https://your-domain/api/mcp, you are done in two minutes.

The catch is that the MCP spec says only tool execution requires auth — initialize, tools/list, prompts/list, resources/list, etc. should be callable without credentials so any client can discover the server's surface. If your route requires an API key for the discovery methods, Smithery's first scan fails with a 401 and you cannot get past the connect step.

Mine did, so I had to patch:

const DISCOVERY_METHODS = new Set([
  "initialize",
  "notifications/initialized",
  "ping",
  "tools/list",
  "prompts/list",
  "resources/list",
  "resources/templates/list",
]);

if (!DISCOVERY_METHODS.has(method)) {
  // require api key as before
}

The other detail I missed first time: Smithery's quality scoring weights structured-output declarations. Each tool needs an outputSchema next to its inputSchema and annotations. I had clean input schemas everywhere and zero output schemas. Adding all 13 output schemas in routes/mcp.ts lifted the Capability Quality from 28/40 to 38/40 and the overall score from 73 to 83.

One last thing about Smithery: when their gateway proxies traffic to your server, it injects the parameters you declared in the connection-settings form. So if you tell Smithery your server needs a header called x-api-key, it will translate the user-supplied apiKey form value into a real header on every upstream request. The gateway also runs proprietary probes — triggers/list is one — that look like authorization errors in your scan log because the gateway handles them, not you.

mcp.so: wants a markdown line

mcp.so is the simplest of the three by an order of magnitude. The directory is rendered from a single README.md in chatmcp/mcpso on GitHub. You open a PR adding one line right after the preview image:

- [Name](https://github.com/you/repo) — One-sentence description.

No scan. No build. No env vars. The maintainer merges the PR and the row shows up on mcp.so/servers once their indexer syncs.

The trade-off is that mcp.so doesn't actually verify anything. There is no quality signal, no introspection result, no scoring. You also can't badge it — there is nothing to badge.

What this means if you only built one transport

Notipo started in the second row. Six releases later — v1.2.1 through v1.2.6 — it sits in row one and row two simultaneously, with the stdio file and the discovery patch doing all the work.

The takeaway is small but easy to miss: when you build an MCP server you implicitly pick a transport, and that transport decides which catalogs accept you. If you have time, ship both. If you only have time for one, hosted Streamable HTTP gets you onto Smithery in two minutes and stays useful for actual Claude Desktop / Cursor users via your domain. Stdio gets you onto Glama and most existing community catalogs, but ties your MCP server to whatever runtime can spawn the process.

There is also a fourth option, which is the one you should default to: ship both, and treat the stdio entrypoint as a catalog adapter that shares its schemas with the production HTTP route. That is what apps/api/src/stdio-mcp.ts ended up being for me.