stdio is the default MCP transport for good reason. You add a block to your config, the client spawns a local process, and you are off. No network, no CORS, no auth header to remember. It is the right answer when you are the only person using the tool and the tool talks to something on your machine.

It stops being the right answer the moment a second engineer asks, "how do I get that billing tool?"

What stdio actually costs

Under stdio, every MCP client spawns the Node process itself. That means:

  • Every engineer needs Node 20+ installed, the right version of the package, and the OpenAPI spec file sitting on their disk.
  • The spec file on Maria's laptop is from last Tuesday. The one on Jorge's is from last quarter. They are now looking at different tool surfaces and getting different answers.
  • When the server package has a bug fix, you ask six people to bump a version and restart their editor. Two of them do it on Friday afternoon and forget.
  • CI runners, shared Slack bots, and non-engineers (support, PMs) cannot use the tool at all. stdio assumes a human sitting at a Mac.
  • Debugging means asking "what does your config look like?" and "did you restart Cursor?" on a Tuesday.

We hit this with the billing tool. It started as my own stdio server. Then three engineers asked for it. Then support asked for it. Then the CI agent that summarizes failed deploys asked for it. By then we were maintaining six slightly different versions of the same process.

What Streamable HTTP actually buys you

Streamable HTTP (and the older SSE transport) flips the model. There is one server, running somewhere with a stable URL. Every client points at it. The config block is:

{
  "mcpServers": {
    "billing": {
      "type": "http",
      "url": "https://mcp.powerduck.com/d/abc123",
      "headers": { "Authorization": "Bearer pk_eng_maria_..." }
    }
  }
}

That is the entire setup. No Node version on the laptop, no spec file to keep in sync, no npx cold start every time Cursor opens. Maria uses it in Cursor on her Mac. Jorge uses it in Claude Desktop on his Linux box. The CI runner uses the same URL with a different access key. The support engineer who uses a managed editor can paste the URL into the MCP inspector and it works.

When the spec changes, you upload it once. Every client sees the new tool surface on the next call. When the server package ships a fix, it is deployed once. When something breaks, there is one process to look at, one request log to read, one place where the upstream token lives.

When stdio is still the right answer

We are not arguing stdio is bad. It is the right transport when:

  • The tool talks to something on your laptop: a local SQLite database, a dev server bound to localhost:3000, a filesystem path that only exists on your machine.
  • You are prototyping a tool for yourself and no one else has asked for it.
  • The tool needs to run with your personal shell environment, your local env vars, your SSH agent.
  • You are on a flight and need it to work offline.

Those are real cases. For the long tail of internal HTTP APIs that already live on a server somewhere — billing, support, CRM, feature flags — stdio is solving a problem you do not have. The API is already on the network. Running a second process on every laptop just to translate a local tool call into the same network call is duplicated work.

The threshold

We use a rough rule: if the tool is useful to you alone, stay on stdio. The moment a second engineer says "can I have that too," move it to a hosted HTTP endpoint. The cost of moving is ten minutes. The cost of staying on stdio past that point is a support ticket every time someone's Node version breaks, and a spec drift you do not notice for three weeks.

The MCP protocol chose transports deliberately. stdio is for local, personal, private tools. Streamable HTTP is for shared, team, hosted ones. Picking the right one is not a philosophical stance — it is just recognizing how many people are about to ask for the tool.

The hosted MCP URL Powerduck issues is Streamable HTTP from day one — shareable across the team, with no per-developer stdio process to keep alive.