What it is: Smithery is a Model Context Protocol platform that does three jobs at once — it is a searchable registry of MCP servers, a host that runs your server as a remote HTTPS endpoint, and a runtime router (Toolbox) that picks the right server for a given call. You can browse and install servers through its CLI, or publish and host your own.

The 10-second answer: The official MCP registry tells a client which servers exist. Smithery adds the two parts a registry leaves out on purpose: a place to run the server and a router to reach it. If you want your MCP server discoverable and hosted without building a deploy pipeline, that's the pitch. Self-reported, it lists and hosts 6,000+ servers and serves tens of thousands of tool calls a day. Free tier; Pro is $20/month.

Why a registry isn't a host — and why that matters#

The thing founders miss when they first list an MCP server is that a registry is a feed, not a runtime. The official registry at registry.modelcontextprotocol.io — backed by Anthropic, GitHub, Microsoft, and PulseMCP, and still in preview rather than GA — publishes a machine-readable server.json record for each server under a name you prove you own. A client reads that feed to discover your server. Then it's on you to actually run the thing somewhere a client can reach it.

Smithery is a downstream layer that closes that gap. The registry says the server exists; Smithery's endpoint runs it; Toolbox selects it at call time. That's the one non-obvious idea here: discovery, hosting, and routing are three separate jobs, and most teams only budget for the first one.

Deploying: one file at the repo root#

The hosted path is deliberately short. You drop a smithery.yaml at your repository root. For a TypeScript server you set:

runtime: "typescript"

You don't hand-write a config schema — Smithery auto-detects it from your TypeScript exports. On a hosted deploy, Smithery parses the file, runs npm ci, builds via your package.json module entry, packages the server into a containerized HTTP service, and serves it at https://server.smithery.ai/your-server with load balancing, scaling, and monitoring handled for you. That's the same stateless-MCP deploy work you'd otherwise wire up behind your own load balancer.

Prefer to ship a server users run themselves? Set target: "local" and Smithery registers a CLI-installable server for discovery without hosting it — the client runs it on their machine, Smithery just makes it findable. Either way, test it with MCP Inspector before you publish (npx @modelcontextprotocol/inspector dist/index.js).

Who it's for#

Where the free line sits — and the honest caveat#

Pricing is Free / Pro $20 per month / Enterprise custom. The free tier is enough to list a server and try hosted endpoints; paid tiers raise usage limits and add features. (Some older write-ups cite a $10 entry tier — check the live pricing page before you budget.)

The caveat is the same one that applies to any managed control plane: hosting on Smithery means your server's uptime, auth surface, and analytics run on infrastructure you don't own. For an integration that's a means to an end, that's a good trade — you're buying back the deploy pipeline. For a server that is your product's moat, or one with strict data-residency or auth requirements, owning the deploy is worth the extra work. The stateless spec cuts both ways: it's what lets Smithery scale your server, and it's what lets you scale it yourself when the time comes.