Skip to content

SYSTEM Cited by 2 sources

Sprites MCP Server

Definition

sprites.dev/mcp — Fly.io's official vendor-hosted remote MCP server for Sprites CRUD operations. Shipped 2026-03-10. Plug the URL into Claude Desktop or any MCP-speaking agent; authenticate into a single Fly.io organization; the agent can then create, manage, and delete Sprites via prompt.

The product ships with a deliberately conflicted framing from Thomas Ptacek: "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." The 2026-03-10 post that ships the server is also the canonical Fly.io statement of the MCP-vs-CLI-skills thesis. (Source: sources/2026-03-10-flyio-unfortunately-sprites-now-speak-mcp.)

Shape (from 2026-03-10)

Property Value
URL sprites.dev/mcp
Transport Remote (HTTP/SSE inferred; explicit transport not disclosed)
Hosting Vendor-hosted by Fly.io (contrast with user-deployed via fly mcp launch)
Auth scope (axis 1) Single Fly.io organization — operator picks one org per MCP session
Sprite-count cap (axis 2) Operator-set maximum number of Sprites the session may create
Name-prefix quota (axis 3) Operator-set string prefix — spawned Sprites greppable / deletable en masse
Client target Claude Desktop + "any other agent tool that speaks MCP"
Tool inventory size Not disclosed (presumably covers create / list / stop / delete / checkpoint / restore)
Session lifetime Not disclosed
Relationship to sprite CLI Presumably parity with the CLI that ships to Sprite users (not explicitly specified)
Product entry sprites.dev

Why it exists (Ptacek's reluctant framing)

The post argues shipping the MCP server is the right commercial call but the wrong architectural default:

  • Right commercial call. Agents that cannot run shell commands — Claude Desktop being the canonical example, though clients shift over time — need an integration protocol. MCP is the integration protocol. Not shipping a Sprites MCP server would cede the market for Sprite-consuming agents to nothing.
  • Wrong architectural default. Ptacek: "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." For shell-capable agents (Claude Code, Gemini CLI, Codex CLI), showing the sprite CLI is strictly better: fewer tokens consumed, progressive capability disclosure via subcommands / --help, and no "cramming your context full of tool descriptions" mispriortization signal.

See context-as-importance-signal for the "attention-misdirection cost" framing.

The three-axis guardrail

Sprites-MCP is the wiki's first documented three-axis agent-creation-quota guardrail at the VM-lifecycle altitude:

  1. Org scope. The operator selects which Fly.io organization the MCP session authenticates into. All Sprite operations are scoped to that org; an injected instruction cannot spill across org boundaries.
  2. Sprite-count cap. The operator sets an explicit ceiling on how many Sprites the MCP session may spawn. This bounds the blast radius of an injected instruction ("create 10,000 Sprites to run a benchmark" is clamped at the operator's cap).
  3. Name prefix. Spawned Sprites all share an operator-set prefix. This makes post-hoc cleanup trivial (grep for the prefix, bulk-delete) and monitoring easy (filter your dashboards to the MCP-created-Sprite namespace).

Ptacek's framing: "so you can easily spot the robots and disassemble them." The guardrails don't prevent robot-driven Sprite creation — they make it contained, attributable, and reversible. This is a different risk model from CLI-level-refusal guardrails (which prevent specific destructive operations); it treats runaway spawning as the primary failure mode, not destructive mutation.

See concepts/ai-agent-guardrails for the broader framing and remote-mcp-server-via-platform-launcher for the sibling user-deployed shape.

Relationship to existing Fly.io MCP primitives

Primitive Shape
flymcp (systems/flymcp) User-run stdio MCP wrapping flyctl locally; inherits workstation creds
fly mcp launch (systems/fly-mcp-launch) User-deployed remote MCP on a user's own Fly Machine; bearer-token auth
sprites.dev/mcp Vendor-hosted remote MCP; org-scoped Fly.io-auth; quota-guardrailed

The 2026-03-10 product is the vendor-hosted endpoint of the continuum the earlier posts sketched. It relocates the MCP-execution context from the operator's workstation (local-MCP risk) to Fly.io's infrastructure, and replaces workstation-credential-inheritance with a scoped, quota-bounded session token.

Example prompts (from 2026-03-10)

Ptacek's "On a new Sprite, do…" prompt template:

  • "On a new Sprite, take this repository and reproduce this bug from issues/913, capturing logs."
  • "On a new Sprite, benchmark this function across 1000 runs and summarize the results."
  • "On a new Sprite, update all the dependencies on this project to their newest versions and test that everything works."
  • "On 3 new Sprites, change this service to use each of these 3 query libraries, and use HTTP to test latency."
  • "On a new Sprite, run this code with bpfwatch and show me what files it touches."
  • "On a new Sprite, run a load generator against this endpoint for 60 seconds and report the results."
  • "On a new Sprite, download this dataset and give me a Jupyter notebook to explore it in."
  • "On a new Sprite, set up a webhook receiver and render a real-time web report of all the payloads it receives."

All of these would overshoot a 15-minute ephemeral sandbox. The durable-sandbox property is load-bearing for the example set. The Sprites MCP is architecturally consumed by durable-VM-for-agent workloads.

Operational numbers not disclosed

  • Transport (HTTP SSE vs Streamable HTTP vs WebSocket — mcp-long-lived-sse vs newer shapes). (Still undisclosed as of 2026-09-03.)
  • Session lifetime / TTL.
  • Tool inventory (full list; 2026-09-03 names only exec and service_start, as the boundary-reaching pair, and confirms per-tool read-only/destructive annotations exist).
  • Pricing — does MCP-created-Sprite usage bill to the org differently?
  • Rate limits beyond the Sprite-count cap (per-minute operation limits, concurrent-session limits, etc.).
  • Interaction with existing Fly.io IAM / Macaroon / tkdb authorization primitives.
  • Auth flow specifics (OAuth, bearer token, Fly.io login redirect, …).
  • Audit log surface (what's logged, where, retention).

Closed by the 2026-09-03 post: default Sprite-count cap (5) and default name-prefix (mcp-), both operator-adjustable.

All remaining items implicit; a follow-up architecture post would close these gaps.

Positional statement

Ptacek's framing positions sprites.dev/mcp as the concession to reality, not the preferred interface:

"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. In claude, gemini, or codex, you should just show your agent the sprite CLI and let it impress you."

First wiki instance of patterns/mcp-as-centralized-integration-proxy as an explicit vendor positional statement.

2026-09-03 update — "Your Agent Speaks MCP. Give It a Computer."

A follow-up post ships alongside the Claude Code plugin and resolves the MCP-vs-CLI-skills argument into a layer separation (see transport-vs-disclosure-layer-separation): MCP is how the bytes get there (transport, auth, structured results, a callable tool); progressive disclosure is what you say to the model. They are different layers, so you don't have to pick — the plugin ships "the hosted MCP server underneath and skills on top," and "what lands in your context is roughly a sentence about when you'd want a fresh computer. The rest arrives when it's needed." Canonical instance of both-mcp-transport-and-cli-skills. This reframes the 2026-03-10 reluctant framing above into both, at different layers. (Source: sources/2026-09-03-flyio-your-agent-speaks-mcp-give-it-a-computer.)

Server-side improvements disclosed in the same post:

  • File reads return as MCP resources, not pasted text — "an agent can point at a file without swallowing it." A result-layer context-budget win; see file-read-as-mcp-resource-not-pasted-text.
  • Per-tool safety annotations — read-only / destructive / boundary-reaching. exec and service_start are flagged as "the two that reach past the Sprite's boundary." A client that reads the annotations can "treat 'list my checkpoints' differently from 'run this thing.'" See tool-annotations-for-client-side-policy.
  • Guardrail defaults now stated — the org/cap/prefix triple 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 the previously-open default questions below.
  • Broader named client coverage — Claude, Codex, Cursor, Antigravity, opencode, Grok, plus a bare-endpoint fallback for unlisted clients.

Related in-Sprite surface (not the MCP server itself): every Sprite carries machine-readable docs at /.sprite/llm.txt for agents operating inside the VM. The sprite CLI and a plain REST API remain co-equal access surfaces — "the same API underneath either way."

Seen in

Last updated · 766 distilled / 2,225 read