Skip to content

CONCEPT Cited by 3 sources

Hosted vs local MCP server

Definition

Hosted vs local MCP server is the deliberate architectural-choice axis between running an MCP server as:

  • Local — a process on the operator's workstation (or a personal cloud-dev box), communicating over stdio transport, typically inheriting the operator's full workstation credentials.
  • Hosted — a cloud-deployed HTTP / Streamable-HTTP / SSE MCP server, reachable over the network, with its own authenticated identity + bearer-token or JWT auth boundary.

Two first-party statements

Pinterest (enterprise-ops voice, 2026-03-19)

"Although MCP supports local servers (running on your laptop or personal cloud development box, communicating over stdio), we explicitly optimized for internal cloud-hosted MCP servers, where our internal routing and security logic can best be applied. Local MCP servers are still possible for experimentation, but the paved path is 'write a server, deploy it to our cloud compute environment, list it in the registry.'" (Source: sources/2026-03-19-pinterest-building-an-mcp-ecosystem-at-pinterest)

Pinterest's reasoning: central execution is the only place internal routing + security logic can be applied — JWT validation at Envoy, business-group gating, central logging, cross-server policy. Local-on-laptop execution cannot participate in any of those.

Fly.io (vendor-platform voice, 2025-05-19)

"basically two types of MCP servers. One small and nimble that runs as a process on your machine. And one that is a HTTP server that runs presumably elsewhere and is standardizing on OAuth 2.1. And there is a third type, but it is deprecated." (Source: sources/2025-05-19-flyio-launching-mcp-servers-on-flyio)

Fly.io ships fly mcp launch — a flyctl subcommand that takes any local stdio MCP server and deploys it as a remote HTTP MCP server on a Fly Machine, flipping the authz boundary from workstation-credential-inheritance to bearer-token-in-client-config.

Why hosted wins for production; local wins for experimentation

Hosted advantages

  • Central auth + policy. JWT validation, business-group gating, mesh-identity SPIFFE auth all require a network-reachable enforcement point.
  • Central logging + observability. Per-invocation attribution, usage metrics, incident review.
  • No workstation-credential inheritance. Local MCP servers inherit the operator's AWS tokens, SSH keys, cloud SDK config — a cloud LLM can then "run native binaries on my laptop with my full identity" (concepts/local-mcp-server-risk).
  • Sharing across the org. A hosted server is reachable by N employees. A local server is one-operator-one-install.
  • Config fragmentation mitigated. Client-config files across Claude Desktop / Cursor / Zed / VS Code / Windsurf each need per-local-server entries (concepts/mcp-client-config-fragmentation); hosted servers can often be configured once per organisation.

Local advantages

  • Experimentation is cheap. No deployment, no registry listing, no review.
  • Capabilities bound to the operator's credentials — for personal-productivity tools this is the desired shape (access my files, my account).
  • Zero network round-trip for stdio transport.
  • No server infrastructure to maintain.

Transport axis is orthogonal but correlated

The hosted-vs-local axis partially rides on the transport axis:

Transport Typical deployment Example
stdio Local subprocess on workstation systems/flymcp (Fly.io local)
HTTP+SSE / Streamable HTTP Hosted server, network-reachable Pinterest Presto/Spark/Knowledge MCP
(Old HTTP with SSE sub-endpoint) Deprecated —

Hosted MCP implies non-stdio transport; stdio implies local (though technically a local HTTP server is possible).

When Pinterest and Fly.io disagree (they don't)

Both vendors ship MCP servers that use both shapes. Pinterest allows local experimentation but paved-paths hosted for production. Fly.io ships local-on-laptop flymcp (2025-04-10 read-only flyctl MCP) and hosted sprites.dev/mcp (2026-03-10). The two posts agree on the structure:

  • Experimentation / personal-productivity / single-operator tools → local is fine.
  • Production / cross-org / sensitive-data / shared-tool → hosted wins on every axis that matters.

Seen in

Last updated · 319 distilled / 1,201 read