Skip to content

FLYIO 2026-03-10 Tier 3

Read original ↗

Fly.io — Unfortunately, Sprites Now Speak MCP

Summary

Thomas Ptacek, Fly.io, 2026-03-10. Announces that Sprites now have an official remote MCP server at sprites.dev/mcp — plug into Claude Desktop (or any MCP-speaking agent), authenticate to a Fly.io organization, and the agent can create / manage Sprites by prompt. The post's tone is deliberately reluctant: "This feature works well, but we're less than enthusiastic about it. Not as product developers, mind you. It's a good product! Just as aesthetes." Ptacek uses the product-launch to stake a canonical architectural-position claim: "In 2026, MCP is the wrong way to extend the capabilities of an agent. The emerging Right Way to do this is command line tools and discoverable APIs." The 2026-03-10 post is therefore a two-layer disclosure: (1) a concrete system ship (sprites.dev/mcp + guardrails), and (2) the load-bearing first-party statement of the MCP-vs-CLI-skills thesis Fly.io has been building toward across five prior MCP posts. The post closes with a reprise of the 2026-01-09 "Fuck Ephemeral Sandboxes" manifesto under the new banner "Fuck Stateless Sandboxes."

Key takeaways

  1. Sprites now have a remote MCP server at sprites.dev/mcp. Plug the URL into Claude Desktop or any MCP-speaking agent, authenticate into a single Fly.io organization, and the agent can speak the Sprites API ("On a new Sprite, take this repository and reproduce this bug from issues/913, capturing logs"). Companion surface to the Sprites launch (2026-01-09) and implementation disclosure (2026-01-14). (Source: 2026-03-10, "Plug this URL into Claude Desktop, or any other agent tool that speaks MCP".)
  2. Explicit anti-MCP thesis from the vendor that ships MCP servers. "In 2026, MCP is the wrong way to extend the capabilities of an agent. The emerging Right Way to do this is command line tools and discoverable APIs." This is the load-bearing first-party statement for the concepts/agent-ergonomic-cli + patterns/wrap-cli-as-mcp-server + concepts/local-mcp-server-risk framings the wiki has been accreting from prior Fly.io posts (2025-04-10, 2025-05-07, 2025-11-06). Fly.io has been consistent — every prior post hedges MCP toward CLI skills where possible — but this post names the aesthetic claim directly. (Source: 2026-03-10, "We Did This Because Your Agents Suck" section.)
  3. Progressive capability disclosure via CLI subcommands is the preferred alternative. "CLI-driven agent skills are efficient because they reveal capabilities progressively. You can do CLI subcommands, like sprite checkpoint and sprite exec, or with API endpoints and subpaths. Good agent harnesses are uncanny at quickly working out how to use these things." The skill only needs one sentence — "Use this skill whenever users want to create a new VM to run a task on, or to manage the VMs already available" — and progressive disclosure takes care of the rest. This is the canonical wiki statement of concepts/progressive-capability-disclosure. (Source: 2026-03-10, "Your agent just needs a short sentence…" through "Good agent harnesses are uncanny".)
  4. Context-as-importance-signal is the load-bearing framing of MCP's aesthetic failure. "Cramming your context full of MCP tool descriptions is a way of signaling to the model that those tools are important to you. But not every Sprite command is equally important in every setting. If you're not using network policies, you don't need gemini to waste a bunch of time setting them up for you." First wiki-grade articulation of concepts/context-as-importance-signal — a framing distinct from the concepts/context-window-as-token-budget cost argument. Two separate complaints, both chargeable to "cram your context full of MCP tools": the token cost (Dropbox / Datadog framing) and the attention-misdirection cost (Ptacek's framing). (Source: 2026-03-10, "And there's more at stake than just efficiency…" paragraph.)
  5. Playwright as the canonical "MCP is optional" datum. "Take Playwright, the industry-standard browser automation tool. Ask claude to install Playwright and Chrome and there's a coinflip chance it sets up the MCP server. But notice that when the coin comes up tails, Playwright still works. claude just drives it by writing little scripts. This is good! The models already know how to write little scripts without using up context." A coin-flip of Claude installations pick MCP vs just-write-scripts, and the non-MCP path works equally well — empirical confirmation that MCP is a crutch for shell-less agents, not a universal tool-integration requirement. (Source: 2026-03-10.)
  6. Canonical positional statement for MCP-as-fallback. "Skills and APIs are the best way to drive Sprites. But to make that work, you need an agent that can run shell commands for itself. So you'll want to reach for MCP sessions when you're stuck with an agent that can't run commands. Thankfully, most of us aren't using those kinds of agents anymore." MCP's remaining legitimate niche is as a fallback protocol for shell-less agents (Claude Desktop, older MCP-only clients). For shell-capable agents (Claude Code, Codex, Gemini CLI), the CLI is the better surface. This is the anchor claim for patterns/mcp-as-fallback-for-shell-less-agents. (Source: 2026-03-10.)
  7. Sprite-creating MCP ships with three structured guardrails. On authentication, the operator (a) selects a single specific organization the MCP session can act within; (b) caps the maximum number of Sprites the MCP session will create; (c) assigns name prefixes so spawned Sprites are greppable / deletable en masse. "You can cap the number of Sprites our MCP will create for you, and you can give them name prefixes so you can easily spot the robots and disassemble them." First wiki instance of a three-axis agent-creation-quota guardrail (org scope × count cap × name prefix) from a production platform. Extends concepts/ai-agent-guardrails beyond the code-review gates framing previously anchored on vinext. (Source: 2026-03-10, "Some of you are thinking to yourself…" paragraph.)
  8. "Fuck Stateless Sandboxes" reprise. "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, and there's no technical reason not to give them some." Restates the sources/2026-01-09-flyio-code-and-let-live|2026-01-09 "Fuck Ephemeral Sandboxes" manifesto under an evolved banner — the original post attacked ephemeral, this one attacks stateless. Semantic difference: ephemeral is about lifetime (does the VM die at session end), stateless is about reachability to real network / real filesystem. Both are ways of naming the same insight: the industry default for agent-compute is too impoverished. (Source: 2026-03-10, "Fuck Stateless Sandboxes" section.)
  9. Internal tension: Fly.io ships what it considers aesthetically wrong. "It's a good product!" Ptacek's self-conscious framing acknowledges that shipping the MCP server is the right commercial call (meet agents where they are — Claude Desktop, older clients — until the shell-capable-agent world arrives everywhere) while simultaneously arguing the tool-integration abstraction the shipped product uses is the wrong one. This is a useful wiki datum because it clarifies the positional role of MCP on the wiki: not wrong, just default-too-often — the right answer in a narrow case (shell-less agents, cross-vendor interop) and the wrong answer by default. (Source: 2026-03-10.)
  10. The prompt template for durable-sandbox agent usage. "On a new Sprite, do…" — Ptacek's recommended prompt prefix. Example prompts: "reproduce this bug from issues/913", "benchmark this function across 1000 runs", "update all the dependencies on this project to their newest versions", "change this service to use each of these 3 query libraries, and use HTTP to test latency", "run this code with bpfwatch and show me what files it touches", "run a load generator against this endpoint for 60 seconds". Reinforces concepts/durable-vs-ephemeral-sandbox: these are long-running, network-bound, external-API-hitting tasks that do not fit in a 15-minute ephemeral sandbox. (Source: 2026-03-10 example-prompts block.)

Extracted systems

  • Sprites MCP Server (new) — sprites.dev/mcp, Fly.io's official remote MCP server for Sprites CRUD. Org-scoped authentication, Sprite-count cap, name-prefix quota. HTTP/SSE transport (inferred from remote URL + Claude Desktop compatibility — confirmation of transport left implicit).
  • Fly Sprites (extended) — the MCP server is a new consumer surface; the guardrails triple is a new disclosure axis.
  • MCP (extended) — 2026-03-10 Ptacek aesthetic-objection framing is new; prior wiki framings (context-window cost, local-MCP risk, skills-vs-MCP tension) converge with this post into an explicit position.
  • Playwright (extended) — the coin-flip observation is a new datapoint.
  • flyctl (related) — Ptacek's "show your agent the sprite CLI and let it impress you" presumes the sprite CLI is at parity with the flyctl CLI in discoverability / JSON support.
  • Claude Code / Gemini CLI / Codex CLI (mentioned) — the three shell-capable coding agents Ptacek names as examples of agents that should prefer CLI skills over MCP.

Extracted concepts

  • concepts/progressive-capability-disclosure (new) — the CLI-subcommand-as-progressive-disclosure design concept. Distinct from concepts/agent-skills-discovery (the well-known-URL directory) and concepts/mcp-server-card (MCP pre-connect metadata): this is about the agent discovering capability mid-task via --help, subcommand enumeration, or API-endpoint-sub-path exploration, rather than declaring the full capability surface in context up-front.
  • concepts/context-as-importance-signal (new) — the observation that stuffing tool descriptions into the context window communicates importance-weighting to the model, not just capability availability. A distinct axis from token cost.
  • concepts/agent-ergonomic-cli (extended) — Ptacek's "CLI is better than MCP for shell-capable agents" framing is a direct extension of the Cloudflare-and-Fly-io 2026 cross-vendor consensus on agents-as-primary-customer for CLIs.
  • concepts/local-mcp-server-risk (referenced — no new disclosure, but the 2026-03-10 remote-MCP ship is the positive alternative the existing page points toward).
  • concepts/ai-agent-guardrails (extended) — the three-axis org×cap×prefix guardrail is a new instance at the VM-creation altitude (prior instances: code-review gates, CLI safety invariants, allowlisted read-only actions).
  • concepts/durable-vs-ephemeral-sandbox (extended) — the "stateless" banner is a new framing-layer on top of "ephemeral". Restatement + rename.
  • concepts/agentic-development-loop (extended) — the example-prompts block is concrete evidence of long-running task shape.

Extracted patterns

Operational numbers

  • ~3-4 minutes of Ptacek's example prompts in the post reference durable / long-running work (load generators for 60 seconds, benchmarks of 1000 runs, dependency-update test-loops) — all of which would exceed the 15-minute ephemeral-sandbox budget Ptacek named in the 2026-01-09 post. (Approximate; no explicit SLO given in this post.)
  • Playwright coin-flip — "a coinflip chance" Claude installs the MCP server. No sample size given.
  • Skill-prompt cost — Ptacek's estimate: "a short sentence" replaces the tool-description-bloat of an MCP server. Specifically "Use this skill whenever users want to create a new VM to run a task on, or to manage the VMs already available" (~21 words). (Compare the ~3,000-op-in-<1,000-tokens claim for Cloudflare Code Mode — same order of magnitude of compression via CLI-skill framing.)
  • Three guardrails — org scope (1), Sprite-count cap (N, operator-set), name prefix (string, operator-set). No default values disclosed.

Caveats

  • Tier-3 source; opinion-piece framing. The post is consciously polemical ("because your agents suck" is the section header). The architectural claims are real but the framing is aesthetic; downstream wiki pages should cite the specific concrete claims, not the polemic.
  • sprites.dev/mcp internals are not disclosed. Transport (HTTP SSE vs Streamable HTTP vs WebSocket), session-affinity story, authz token lifetime, tool inventory size, pagination — all implicit. Defer structural-shape questions until a follow-up post fills them in.
  • "Emerging Right Way" is a forward-looking claim. Ptacek's "in 2026" framing gestures at industry direction. Counter-datapoints (Cloudflare's Code Mode is MCP-generated, Dropbox's Dash exposes MCP, Databricks' Unity AI Gateway governs MCP specifically) suggest MCP continues to be the default integration protocol at enterprise scale. The post does not litigate this tension — it argues for a different default in the coding-agent-with-shell use case.
  • No comparison numbers. Post does not benchmark the Sprites MCP against CLI-skill-based Sprite control. The Playwright coin-flip is the only empirical claim.
  • "Agents that can't run shell" is not enumerated. Ptacek name-checks Claude Desktop implicitly (MCP is the interop path it uses) but doesn't produce a clean list. The wiki concept patterns/mcp-as-fallback-for-shell-less-agents should preserve this ambiguity: "agents without shell access" is a moving target as clients add shell capability.
  • Guardrails scope. Described guardrails (org scope, Sprite cap, name prefix) apply at MCP session authentication time. Whether they compose with Fly.io's existing IAM / Macaroon / tkdb authorization machinery is not described. Presumably yes — but the post does not explicitly confirm.
  • "Stateless" vs "ephemeral" semantic drift. The 2026-01-09 post framed the attack as on ephemeral sandboxes; the 2026-03-10 post uses stateless. The terms are not exactly synonymous (ephemeral = dies at session end; stateless = no persistent filesystem or real network) but the arguments are parallel. Downstream pages should note that "stateless" is the evolved framing, not a replacement, and the two concepts compose (concepts/durable-vs-ephemeral-sandbox is the right landing page for the axis).
  • No retrospective on the 2025-05-19 fly mcp launch approach. The 2026-03-10 post ships a remote-MCP (sprites.dev/mcp) that Fly.io itself hosts; prior guidance (systems/fly-mcp-launch) emphasised users deploying their own stdio MCP servers as remote Fly Machines. The 2026-03-10 product is the vendor-hosted variant of that pattern.

Source

Last updated · 319 distilled / 1,201 read