Point an agent at an MCP server on Smithery and you are not just fetching a URL from a list — you are handing off discovery, execution, and auth to a platform that sits between your client and the server. Here is what that hosted layer actually does.
What Smithery's hosted layer gives you beyond a link list
Smithery is a three-layer control plane for Model Context Protocol (MCP) servers, not a curated GitHub list. It bundles a discovery registry (a searchable catalog of which servers exist), a managed execution layer (running those servers as remote endpoints on its own infrastructure), and an OAuth/credential relay that mints scoped tokens and refreshes credentials for you, per its docs. The catalog has grown from roughly ten servers at launch to a figure reported at 6,000–7,000+ MCP servers.
The piece that a link list cannot replicate is Toolbox, Smithery's meta-MCP: one connection dynamically wires an agent to any registry server at runtime, so you skip per-server configuration in every client. On top of that sits a REST surface where you create long-lived connections, call tools, and hit namespace-wide endpoints at https://mcp.smithery.run/{namespace} — Smithery handles protocol compliance, so callers never implement raw MCP themselves (source).
Smithery was founded in December 2024 by Henry Mao, previously technical co-founder of Jenni.ai. That registry-plus-hosting-plus-router bundle is what separates it from catalog-only competitors such as Glama, PulseMCP, and mcp.so — the last reported at 19,700+ listings, favoring breadth over curation.
smithery.yaml: typescript, container, and URL registration
Every server you ship through Smithery is described by a smithery.yaml at the repo root, and that file picks one of three deployment models . The choice decides who owns the runtime, which languages you can use, and who patches the machine underneath — so it is worth reading before you commit code.
Option A — runtime: "typescript". This is the recommended path. The CLI runs @smithery/cli build and deploys a Streamable HTTP endpoint on Smithery's own infrastructure. It is TypeScript-only, but in exchange you write almost no deployment glue: Smithery builds, hosts, and routes the server for you .
Option B — runtime: "container". Smithery builds a Docker image from your Dockerfile, so any language works. At runtime it starts the app, injects a PORT environment variable, routes MCP traffic to a /mcp endpoint, and passes per-session config as query parameters. This mode requires a startCommand of type: "http" and a JSON-Schema configSchema so the platform can validate session config .
Option C — URL registration. You keep your own VM and point Smithery at a Streamable HTTP endpoint you already run — full control, but you own uptime and patching. A middle option, Uplink, keeps a persistent WebSocket tunnel from a local process, but Smithery's docs explicitly flag it as not production hosting: availability follows the developer's machine .
Smithery's argument for pushing everything toward Streamable HTTP is throughput — it claims the transport "delivers up to 20x higher concurrency and lower latency" than stdio, plus load balancing and auto-scaling . Here is how the three modes compare on the things that bite you in production:
| Dimension | A: typescript | B: container | C: URL registration |
|---|---|---|---|
| Language support | TypeScript only | Any (Docker) | Any |
| VM ownership | Smithery | Smithery | You |
| SLA status | None published | None published | Yours to define |
| Credential handling | Smithery-managed OAuth | Smithery-managed OAuth | Your responsibility |
| Who patches the OS | Smithery | Smithery | You |
Cold-start latency: what Fly.io machines mean in practice
Cold-start latency is the least-documented part of Smithery's hosted story: there is no published p50/p95/p99 table, SLA, region list, scale-to-zero toggle, or prewarming dial in the current build docs . What you can infer is the runtime underneath. The October 2025 GitGuardian disclosure confirmed indirectly that hosted servers run on Fly.io machines behind a Docker registry . Fly.io machines can auto-stop when idle and auto-start on the next request — exactly the mechanism that produces a cold start on a hosted MCP server that has been quiet .
How long that stall lasts, Smithery does not say. As a reference point from the broader serverless literature, a Huawei trace study analyzing roughly 85 billion requests and 11.9 million cold starts measured cold starts of up to 7 seconds in one region — external context, not Smithery's own numbers, which remain undisclosed. The architectural rationale Smithery does publish is that Streamable HTTP "delivers up to 20x higher concurrency and lower latency" than stdio and enables load balancing and auto-scaling — but concurrency headroom is a different metric than first-request latency after idle.
The practical cost is control. On the hosted path you cannot directly set:
- VM size and memory allocation
- Region affinity or multi-region placement
- Keepalive interval to prevent scale-to-zero
- Autoscaling thresholds
- Dependency caching strategy
Every one of those is yours to tune on a self-managed VM, a Kubernetes pod, or a stdio process colocated with its data. If deterministic latency matters, the missing dials — not the raw speed — are the tradeoff to weigh.
The June 2025 path traversal: one flaw, 3,243 apps in scope
Handing runtime placement to a platform also means inheriting its build pipeline's attack surface. The clearest documented cost of Smithery's hosted model is a path-traversal flaw GitGuardian disclosed on October 15, 2025: the dockerBuildPath parameter in a submitted smithery.yaml was unvalidated, so setting it to ".." let a malicious Dockerfile climb out of the build context and read ~/.docker/config.json from the build user's home directory .
The blast radius came from what that file held: an overprivileged Fly.io API token granting the machines API across a Fly.io organization of exactly 3,243 apps — over 3,000 hosted MCP servers — with confirmed root access and the ability to sniff inbound traffic carrying downstream API keys such as Brave keys . One misconfigured build parameter, in other words, exposed every tenant on the shared infrastructure.
The timeline was tight on the fix side: GitGuardian found the flaw June 10, reported it June 13, and Smithery patched and rotated credentials by June 15, 2025, with no evidence of exploitation found . Public disclosure followed four months later.
"A concentration of servers... creates a valuable target," — GitGuardian, on the structural risk of centralized MCP hosting (source: GitGuardian).
That is the tradeoff to weigh: the same aggregation that makes Smithery convenient makes it a single high-value target. And listing is not vetting — a separate scan found 22 of 100 sampled Smithery servers returned security findings . Registry inclusion tells you a server exists, not that its code is safe to run against your credentials.
Hosted vs. self-hosted: the practical choice
Choose hosted when distribution reach, a managed OAuth lifecycle, broad client compatibility, and zero-ops onboarding outweigh latency determinism. For teams shipping a server they want agents to discover and connect to without wiring auth by hand, Smithery's write-only, encrypted credential storage — usable but not readable — beats many do-it-yourself setups that leave secrets in plaintext env files .
Choose self-hosted when p99 latency guarantees, data residency, audit-log ownership, regulatory boundaries, or full language freedom are non-negotiable. A server pinned to a warm VM or a private VPC gives you the placement, keepalive, and logging controls that managed execution abstracts away — at the cost of running and patching the infrastructure yourself.
The middle path is URL registration: keep your own hosting, publish a Streamable HTTP endpoint, and gain Smithery discovery without surrendering runtime placement. One operational catch — WAFs and bot protection can block SmitheryBot/1.0 requests arriving from Cloudflare Workers, so you may need an explicit allow rule or a static server card for the gateway to reach you .
Whichever you pick, the same gaps persist: Smithery's cold-start profile, hosted-runtime isolation model, secret-management internals, and any hard SLA remain unpublished across the reviewed docs . The takeaway: match the deployment model to your hardest constraint — distribution or determinism — and treat the undocumented cold-start window as a risk you accept, not one you can currently measure.
Frequently asked questions
Does Smithery publish a latency SLA for hosted MCP servers?
No. The reviewed Smithery docs contain no p50/p95/p99 latency table, no region list, no scale-to-zero setting, and no published cold-start disclosure . Hosted servers run on Fly.io machines, which can auto-stop when idle and auto-start on the next request — the mechanism that produces cold starts . Without an independent measurement of your own server, the cold-start duration is unknown, not merely small.
What languages can I use with a Smithery-hosted server?
It depends on the deployment model. runtime: "typescript" — the recommended hosted path where the CLI runs @smithery/cli build — is TypeScript-only . runtime: "container" builds a Docker image from your own Dockerfile, so it accepts any language . URL registration is fully language-agnostic: you keep your own hosting and only need to expose a Streamable HTTP endpoint that Smithery routes to .
What exactly happened in the June 2025 Smithery path traversal incident?
An unvalidated dockerBuildPath parameter in a submitted smithery.yaml let a crafted build read the host's ~/.docker/config.json, which held an overprivileged Fly.io API token with machines-API access across a Fly.io organization of exactly 3,243 apps (over 3,000 hosted MCP servers) . GitGuardian found it on June 10, reported it June 13, and Smithery patched and rotated by June 15, 2025, with no evidence of exploitation .
Is Smithery's Uplink tunnel usable in production?
No — by Smithery's own account. Uplink runs a CLI that keeps a persistent WebSocket tunnel bridging JSON-RPC to a local process, exposing it as a normal connection, but the docs state it is not intended as production hosting and its availability follows the developer's machine . It suits local development and testing; for a stable endpoint, use a hosted runtime or a URL registration pointed at your own always-on deployment.
How does Smithery store OAuth credentials, and who holds them?
Smithery's docs describe write-only encrypted storage — credentials are usable by the running server but not readable back, including by Smithery staff . That beats many DIY setups, but the tradeoff is custody: your integration secrets live in Smithery's platform rather than your own vault, KMS, or audit stack . The June 2025 incident showed the stakes of that concentration — a single overprivileged token reached over 3,000 hosted apps before it was rotated .
Enjoyed this article? Subscribe to get new stories by email whenever they're published.
