What struck me most is that this piece treats stdio versus remote HTTP like a clean architectural decision, when in practice it’s often a trust decision disguised as plumbing. That part is true enough: local subprocesses feel simple because they inherit your shell, your tokens, your filesystem, your whole environment. But that simplicity is doing a lot of hidden work. It’s not just “easier.” It’s “I am willing to let this tool sit inside my machine and borrow my identity.” That’s a very different tradeoff than hosting.
The article is strongest when it gets concrete about that split. A local MCP server really is a different beast from a hosted one. If the tool needs local files, a git checkout, or a dev database, stdio is the natural fit. If it needs to be shared with a team, CI, or a browser agent, then remote starts to look unavoidable. That sounds obvious once you say it out loud, but a lot of teams seem to skip over the “who is this actually for?” question and jump straight to implementation.
What I like is the refusal to romanticize remote. Hosted MCP is not just “stdio but on the internet.” The author calls out the stuff that tends to get hand-waved away: auth, uptime, capacity planning, audit trails, retries, multi-tenancy. Those are the parts that usually show up later as a pile of incidents. If you’ve ever watched a local-first prototype become a shared service, you know the moment the module-level state starts lying to you.
I’m a little less convinced by the clean “one server, both transports” story, though. Yes, the code may be shareable. But operationally, the two modes can drift fast. The article hints at that with session IDs, idempotency, and SSE progress streaming. That’s the right warning. The hard part isn’t whether the handler functions can be reused. It’s whether the state model, timeout behavior, and auth story stay honest across both environments. In my experience, that’s where the supposedly transport-agnostic design quietly stops being transport-agnostic.
The most useful line of thought here is probably the advice to start with stdio if you’re prototyping, then move to HTTP when the use case demands it. That feels right. I’d probably push that even further: if the tool only makes sense on one developer’s laptop, keep it local until somebody can name the exact reason it should exist as a service. The article is implicitly arguing against premature hosting, and I think that’s the right bias. Too many internal tools get shoved into infra before anyone has proved they’re worth centralizing.
The spec-driven angle is interesting too, though I’d want to see it in the wild before I trust it completely. In theory, generating MCP servers from OpenAPI could make the transport choice less painful. In practice, generated systems tend to expose where your API design is already messy. If the same spec really can back both local mocks and a hosted endpoint, that’s neat. If not, the generator becomes another layer that papers over mismatches until they explode in production.
What I’d take from this is simple: stdio is for trust and speed, remote is for sharing and control. The article doesn’t say anything revolutionary, but it does a decent job of naming the cost centers people forget. That’s useful. The only thing I’d add is that the real boundary is usually not transport but responsibility. Once other people depend on the tool, it stops being a process and starts being a service.
Reference: MCP stdio vs Remote Transports: Run It Locally or Host It?
