Skip to content

Fly.io — Your Agent Speaks MCP. Give It a Computer.

Summary

Fly.io ships the official sprites.dev/mcp vendor-hosted MCP server for Sprites (disposable, durable per-user cloud computers) and — in the same post — resolves the MCP-versus-CLI-skills argument it opened on 2026-03-10 into a both/and position: MCP and progressive disclosure operate at different layers, so you don't have to pick. MCP governs transport, auth, structured results, and having a callable tool (how the bytes get there); progressive disclosure governs what you say to the model (concepts/progressive-capability-disclosure). The Claude Code plugin ships both: a hosted MCP server underneath and skills on top, so "what lands in your context is roughly a sentence about when you'd want a fresh computer. The rest arrives when it's needed." The server side improved too: file reads return as MCP resources rather than a wall of pasted text, and every tool carries safety annotations (read-only, destructive, and a boundary-reaching flag on exec and service_start). Every Sprite also carries machine-readable docs at /.sprite/llm.txt so an agent working inside a Sprite can learn the environment. Guardrails from the 2026-03-10 post are restated with defaults: a five-Sprite cap and an mcp- name prefix, both operator-adjustable. (Source: sources/2026-09-03-flyio-your-agent-speaks-mcp-give-it-a-computer)

This is Fly.io Tier-3, but on-scope: it contains real agent-infrastructure and protocol-design architecture (MCP layer separation, MCP resources vs inline text, tool safety annotations, in-environment agent docs, VM-lifecycle creation guardrails), not a pure product launch.

Problem framing — the MCP-vs-CLI argument, taken seriously

Ptacek names the argument going around: "MCP is the wrong way to extend an agent, and that command line tools and discoverable APIs are the Right Way." He grants half of it, the important half, then splits the other half apart:

"Dumping thirty tool descriptions into a context window is a bad way to teach anything. Not every Sprite command matters in every session, and cramming them all in signals to the model that they all matter to you."

This is the attention-misdirection cost: tool descriptions in context don't just cost tokens, they signal importance-weighting to the model. "If you're not using network policies, gemini shouldn't burn a single token learning to configure them." Capabilities "should reveal themselves progressively, the way they do when an agent works out a CLI one subcommand at a time" (concepts/progressive-capability-disclosure).

Key takeaways

  1. MCP and progressive disclosure are different layers — you can have both. The post's central architectural correction:

    "Progressive disclosure is a question of what you say to the model. MCP is a question of how the bytes get there: transport, auth, structured results, a tool the model can call instead of a command whose flags it has to guess. Those are different layers, and nothing stops you from having both." The Claude Code plugin "is what having both looks like" — hosted MCP server underneath, skills on top. See transport-vs-disclosure-layer-separation and both-mcp-transport-and-cli-skills. This retires the framing of the 2026-03-10 post, which read as CLI-skills-good / MCP-reluctantly-shipped; the 2026-09-03 position is both, at different layers. (Source: sources/2026-09-03-flyio-your-agent-speaks-mcp-give-it-a-computer)

  2. A skill collapses the tool inventory to one sentence + on-demand detail. "What lands in your context is roughly a sentence about when you'd want a fresh computer. The rest arrives when it's needed." This is progressive disclosure implemented on top of an MCP transport, not instead of it. (Source: sources/2026-09-03-flyio-your-agent-speaks-mcp-give-it-a-computer)

  3. File reads come back as MCP resources, not pasted text. "A file read comes back as an MCP resource instead of a wall of pasted text, so an agent can point at a file without swallowing it." This is a context-budget win at the result layer (distinct from the tool-description budget): the agent references a file by handle rather than inlining its whole content into the transcript. See mcp-resource and file-read-as-mcp-resource-not-pasted-text. (Source: sources/2026-09-03-flyio-your-agent-speaks-mcp-give-it-a-computer)

  4. Every tool carries safety annotations; two tools are flagged as boundary-reaching. "Read-only operations are marked read-only, destructive ones are marked destructive, and exec and service_start are flagged as the two that reach past the Sprite's boundary. A client that pays attention to those can treat 'list my checkpoints' differently from 'run this thing.'" The annotations are advisory metadata the client consumes to apply differentiated policy (auto-approve reads, gate destructive/boundary ops). See mcp-tool-safety-annotation and tool-annotations-for-client-side-policy. (Source: sources/2026-09-03-flyio-your-agent-speaks-mcp-give-it-a-computer)

  5. Every Sprite ships machine-readable in-environment docs at /.sprite/llm.txt. "Every Sprite carries machine-readable docs at /.sprite/llm.txt that teach an agent working inside it how the place operates." This is the inside-the-VM complement to the outside-the-VM MCP/CLI surface: an agent that has a shell reads the CLI docs from within; an agent driving from outside uses MCP. Both point at the same API. See concepts/machine-readable-documentation. (Source: sources/2026-09-03-flyio-your-agent-speaks-mcp-give-it-a-computer)

  6. Three surfaces, one API: MCP, plain REST, and the sprite CLI. "The shell never went anywhere. There's a sprite CLI, there's a plain REST API… If your agent would rather write little scripts than call tools, let it. It's the same API underneath either way." The design deliberately does not force a single access modality; the agent's own capabilities (shell vs no-shell) pick the surface. (Source: sources/2026-09-03-flyio-your-agent-speaks-mcp-give-it-a-computer)

  7. Creation guardrails now have stated defaults: 5-Sprite cap, mcp- prefix. "When you authenticate you're handing your agent a single specific organization on your Fly.io account, and you can scope the session down from there. It defaults to a cap of five Sprites and an mcp- name prefix, so the robots are easy to spot and easy to disassemble. Both are yours to change." This closes an open question from the 2026-03-10 systems/sprites-mcp page (were defaults specified? now yes). The three-axis guardrail — org scope × count cap × name prefix — is unchanged; the defaults are newly disclosed. (Source: sources/2026-09-03-flyio-your-agent-speaks-mcp-give-it-a-computer)

  8. Broad client coverage; bare-endpoint fallback. "Codex, Cursor, Antigravity, opencode, Grok and the others work the same way, and if yours isn't on that list, point it at the bare endpoint and it still works." MCP is the interoperability floor for clients without a first-party plugin — the MCP-as-fallback position, now generalised to any client without a Fly plugin. (Source: sources/2026-09-03-flyio-your-agent-speaks-mcp-give-it-a-computer)

  9. "Fuck Stateless Sandboxes" — the durable-substrate thesis, restated. "The industry is stuck on 'sandboxes' as a way of letting agents run code, and sandboxes aren't good enough anymore. What agents want is real computers, with real filesystems, connected to real networks." The example prompts (reproduce a bug, benchmark 1000 runs, 3 Sprites testing 3 query libraries, load-generate for 60s, build a Jupyter notebook, run a webhook receiver) all overshoot a 15-minute ephemeral sandbox — the durable-sandbox property is load-bearing. (Source: sources/2026-09-03-flyio-your-agent-speaks-mcp-give-it-a-computer)

Architecture / design detail

Two orthogonal layers. The post's load-bearing distinction:

Layer Question it answers Instances
Transport / protocol (MCP) How do the bytes get there? Transport, auth, structured results, a callable tool the model doesn't have to guess flags for. sprites.dev/mcp, bare MCP endpoint
Disclosure / pedagogy (concepts/progressive-capability-disclosure) What do you say to the model? One sentence up front; the rest on demand. Skill file in the Claude Code plugin; CLI subcommand tree; --help

The plugin composes them: MCP handles the wire, a skill handles the teaching. This is both-mcp-transport-and-cli-skills — the first wiki instance of MCP and skills as complementary layers rather than competing choices.

Server-side improvements (result + safety layer):

  • MCP resources for file reads — reference-not-inline; agent points at a file without swallowing its bytes into context.
  • Per-tool safety annotations — read-only / destructive / boundary-reaching (exec, service_start). Client-consumed advisory metadata for differentiated approval policy.

In-environment docs: /.sprite/llm.txt inside each Sprite — the agent-facing manual for an agent operating inside the VM (complements the outside-the-VM MCP/CLI surface).

Creation guardrails (defaults now disclosed): single org per session; default cap of 5 Sprites; default mcp- name prefix; both operator-adjustable.

Operational numbers / specifics

  • Default Sprite cap per MCP session: 5 (adjustable).
  • Default name prefix: mcp- (adjustable).
  • Boundary-reaching tools flagged: exec, service_start.
  • In-Sprite docs path: /.sprite/llm.txt.
  • Named compatible clients: Claude (Desktop + Code), Codex, Cursor, Antigravity, opencode, Grok — plus a bare-endpoint fallback for unlisted clients.
  • Access surfaces: sprites.dev/mcp (MCP), plain REST API, sprite CLI — one API underneath.

Caveats / what's not disclosed

  • MCP transport specifics (Streamable HTTP vs SSE) still not named.
  • Tool inventory count / full tool list not enumerated (only exec, service_start named, as the boundary-reaching pair).
  • Resource lifecycle for MCP-resource file handles (TTL, size caps) not specified.
  • Auth flow specifics (OAuth vs bearer, redirect flow) not detailed.
  • Whether the safety annotations follow the MCP spec's standard annotation fields or are Fly-specific is not stated.
  • No pricing / billing differences for MCP-created Sprites disclosed.

Source

Last updated · 766 distilled / 2,225 read