Skip to content

FLYIO 2025-06-12 Tier 3

Read original ↗

Fly.io — What are MCP Servers?

Summary

Sam Ruby's explainer post reframing MCP beyond the official "USB-C for AI applications" tagline through five analogies: (1) MCPs are Alexa Skills — the last-mile pairing step that makes a separately-installed device usable by an assistant; (2) MCPs are API 2.0 — multiplexing + server push over traditional request/response APIs; (3) MCPs are APIs with introspection/reflection — OpenAPI-like schemas plus built-in protocol requests for tool discovery and prose usage hints; (4) MCPs are not serverless — they have a well-defined long-lived lifecycle (init → operate → shutdown) fundamentally at odds with FaaS; (5) MCPs should be considered family — LLMs are brains, MCPs are eyes/hands/legs, and the end result is robots that are agents not appliances. Ruby closes with a strategic thesis: MCPs flip the integration model — instead of adding LLMs to things you already have (the IDE + Copilot shape), you add things you already have to an LLM — and warns that local-MCP installation (plain-text secrets + downloaded-binary-from-third-party) is not inherently secure, with remote-MCP-on-your-own-machine + revocable bearer token as the mitigation.

Key takeaways

  • MCP is a stateful long-lived protocol, not a request/response API or a FaaS function. The official lifecycle has three explicit phases — initialization, operation (normal protocol traffic), shutdown — with initialize request / initialize response / initialized notification framing the boundary. "MCP servers are not serverless; they have a well-defined and long-lived lifecycle." This is the canonical wiki statement of concepts/mcp-lifecycle-not-serverless and pairs with the pre-existing session-affinity framing in concepts/mcp-long-lived-sse. (Source: sources/2025-06-12-flyio-what-are-mcp-servers.)
  • MCP as API 2.0 is the multiplexing/server-push framing. "APIs today are typically request/response. MCPs support multiplexing and server push." Ruby explicitly analogises MCP-over-stateful-transport vs classical HTTP 1.1 APIs to HTTP/2 over HTTP 1.1 — each response is a stream, not a single payload, and the server can push invitations (tool-list changes, notifications) without the client polling. (Source: sources/2025-06-12-flyio-what-are-mcp-servers.)
  • MCP's introspection/reflection is load-bearing, not cosmetic. Classical APIs can publish an OpenAPI Description as a separate document; MCP bakes discovery into the wire protocol — "there are standard requests built into the protocol to obtain useful information, including what tools are provided, what arguments each tool expects, and a prose description of how each tool is expected to be used." This changes tool-onboarding from "read a separate spec file" to "ask the server." See concepts/tool-introspection-reflection. (Source: sources/2025-06-12-flyio-what-are-mcp-servers.)
  • OpenAPI → MCP auto-generation is an anti-pattern warning. Ruby cites Neon's Autogenerating MCP Servers from OpenAI Schemas quote: "Effective MCP design means thinking about the workflows you want the agent to perform and potentially creating higher-level tools that encapsulate multiple API calls, rather than just exposing the raw building blocks of your entire API spec." — consistent with the existing patterns/tool-surface-minimization framing from the Dash MCP / Datadog MCP retrospectives. Auto-generated MCP surfaces leak API granularity into agent context. (Source: sources/2025-06-12-flyio-what-are-mcp-servers.)
  • Local MCP security posture is structurally weak, not technically weak. "The current process for installing a stdio MCP into Claude involves placing secrets in plain text in a well-defined location. And the process for installing the next MCP server is to download a program from a third party and run that tool in a way that has access to this very file." The threat model: MCP server N has read access to the credentials belonging to MCP server N−1 (all in the same client-config file). Not prompt injection, not exploitable abilities — the install model itself is the attack surface. Canonical expansion of concepts/local-mcp-server-risk to cover the cross-MCP-credential-theft dimension. (Source: sources/2025-06-12-flyio-what-are-mcp-servers.)
  • Remote MCP with revocable bearer token is the shipped mitigation. "One key strategy component is the ability to run an MCP server on a remote machine which can only be accessed by you, and only after you present a revocable bearer token. That remote machine may require access to secrets (like your GitHub token), but those secrets are not something either your LLM client or other MCP servers will be able to access directly." Credential isolation through a token-gated remote boundary — the architectural shape fly mcp launch (2025-05-19) already ships as a product. Canonical statement for patterns/remote-mcp-with-revocable-bearer-token. (Source: sources/2025-06-12-flyio-what-are-mcp-servers.)
  • MCPs flip the integration model. "Today, most people exploring LLMs are trying to add LLMs to things they already have — for example, IDEs. MCPs flip this. Instead of adding LLMs to something you already have, you add something you already have to an LLM." First wiki statement of concepts/mcp-integration-inversion — pairs with Desktop Commander MCP as the concrete example ("a prime example of a tool you want to give root access to, then lock it in a secure box and run someplace other than your laptop"). The launcher — operating system, app store, web browser — is being recast as the LLM, not the OS shell. (Source: sources/2025-06-12-flyio-what-are-mcp-servers.)
  • Agents are the durable shape, appliances are the transient shape. Ruby's brains + eyes/hands/legs = robots framing distinguishes appliance MCPs (brainless eyes and hands; most current MCPs; one Hue-lights MCP is like one dishwasher — functionally identical to everyone else's) from agent MCPs (brain-bearing; adapted per-operator; screen my texts, DJ my parties, watch my business trends). Agents are customised at the operator level; appliances are commodities. The wiki already has concepts/agent-context-window + concepts/agent-ergonomic-cli on the building-agents side; this post's contribution is the typology of MCP artefacts along the agent-vs-appliance axis. (Source: sources/2025-06-12-flyio-what-are-mcp-servers.)

Systems extracted

  • systems/model-context-protocol — extended with the MCP-is-API-2.0 + MCP-is-stateful-not-serverless framings, Ruby's Alexa-Skill analogy, the introspection/reflection dimension of the protocol, and the architectural thesis that MCPs flip the integration model.
  • systems/fly-mcp-launch — reinforced. The post's "run an MCP server on a remote machine which can only be accessed by you, and only after you present a revocable bearer token" thesis is the architectural statement that names fly mcp launch as the shipped implementation shape. Ruby's post is the "why" that the 2025-05-19 fly mcp launch post is the "how" of.
  • systems/desktop-commander-mcp — new system page. Named by Ruby as "a prime example of a tool you want to give root access to, then lock it in a secure box and run someplace other than your laptop." Canonical "add your workstation to an LLM" MCP server.

Concepts extracted

  • concepts/mcp-lifecycle-not-serverless — new concept page. The explicit three-phase protocol lifecycle (initialize → operation → shutdown) and why MCP servers are structurally at odds with FaaS / Lambda-shape compute. Pairs with concepts/mcp-long-lived-sse to cover both the protocol-level lifecycle and the transport-level session-affinity constraint.
  • concepts/mcp-integration-inversion — new concept page. MCPs flip the LLM-integration posture from "add an LLM to your existing tool" to "add your existing tool to an LLM." Canonical wiki statement with the IDE + Copilot counterexample and Desktop Commander as the positive example.
  • concepts/local-mcp-server-risk — extended. Pre-existing page framed the risk as "cloud LLM runs native binaries on my laptop with my full identity"; this post extends the frame with the cross-MCP-credential-theft dimension — every MCP-server install has read access to every other MCP server's plain-text secrets stored in the same client-config file. The structural fix is credential isolation via remote MCP + bearer token.
  • concepts/tool-introspection-reflection — new concept page. The distinction between OpenAPI's separate description document and MCP's in-protocol tool discovery, parameter schema, and prose description. Makes MCP a self-describing protocol rather than an API + sidecar-spec.

Patterns extracted

  • patterns/remote-mcp-with-revocable-bearer-token — new pattern page. Run the MCP server on a remote machine; gate access behind a bearer token that you can revoke; keep the MCP-server-held secrets (GitHub token, cloud credentials) inaccessible to both the LLM client and to sibling MCP servers running locally. Decouples credential custody from local-workstation trust. Fly.io ships fly mcp launch as an instantiation of this pattern; the wiki's pre-existing patterns/remote-mcp-server-via-platform-launcher is the deployment-mechanism complement (this page covers the security posture; that page covers the deployment ergonomics).
  • patterns/remote-mcp-server-via-platform-launcher — reinforced. Pre-existing pattern page already frames fly mcp launch as the one-command deploy of a stdio MCP server to a remote machine; this post provides the why (credential isolation against adjacent MCP servers), not just the what (config-fragmentation mitigation).

Operational numbers

  • MCP's age at post time: "MCPs are barely six months old" (MCP launched 2024-11, post dated 2025-06-12 → about seven months). Ruby is writing from the frontier.
  • Lifecycle phases: 3 (Initialization, Operation, Shutdown). 3 initialization messages (initialize request, initialize response, initialized notification).
  • No production numbers. This is an explainer post, not a retrospective.

Caveats

  • Explainer post, not an architecture retrospective. Ruby is making the case for "what MCPs are" through analogies, not disclosing Fly.io's production numbers. The architectural content is in the lifecycle-not-serverless + remote-MCP- bearer-token + MCP-integration-inversion framings, each of which is a few paragraphs.
  • Analogies are framing devices, not specifications. The API 2.0 analogy is imprecise — HTTP/2 semantics are not the same as MCP's Streamable HTTP transport. The Alexa Skill analogy conflates the last-mile authorization step with the underlying protocol.
  • Security claim is directional, not quantitative. "Local MCP servers can read each other's secrets" is correct for the current client-config convention, but the remote-bearer-token alternative has its own threat model (bearer-token theft, remote-machine compromise) that Ruby doesn't enumerate. Treat this as a threat-model sketch, not an audit.
  • Strategic predictions are unverifiable. "MCP servers have the potential to make both [app stores and web browsers] obsolete — and this could happen sooner than you think" is the post's closing line. Noted here as an artefact of the 2025-06 moment; the wiki's job is to archive the thesis, not to underwrite the prediction.
  • Fly.io is Tier-3. Per AGENTS.md Tier-3 filter this post clears the bar on protocol lifecycle / security posture / integration-model architectural content but is close to the threshold — an explainer post with roughly 30% of body content being concrete architecture (lifecycle / security / integration-inversion), the remaining 70% being analogies, framing, and speculation. On-scope by borderline-include rule in AGENTS.md "Borderline cases — include, don't skip".

Source

Last updated · 319 distilled / 1,201 read