Skip to content

SYSTEM Cited by 1 source

flymcp

flymcp (github.com/superfly/flymcp) is Fly.io's "most basic" MCP server for flyctl. Thomas Ptacek's stated design brief: "the most basic MCP server for flyctl I could think of … it took 30 minutes." (Source: sources/2025-04-10-flyio-30-minutes-with-mcp-and-flyctl.)

Shape

  • ~90 lines of Go, using mark3labs/mcp-go for the MCP protocol plumbing.
  • Two tools registered: fly logs and fly status.
  • MCP stdio transport — the MCP client (Claude Desktop, Claude Code, Cursor, …) launches flymcp as a subprocess; tool calls round-trip as JSON blobs on stdin/stdout.
  • Per-call subprocess — each tool invocation shells out to the real flyctl binary with --json and returns captured stdout verbatim.
  • Inherits the operator's flyctl credentials — whatever's already in the flyctl auth state becomes the auth boundary. No separate MCP-side login.

Canonical wiki instance of patterns/wrap-cli-as-mcp-server.

Why 90 LoC was enough

Three preconditions converge:

  1. mark3labs/mcp-go handles the MCP protocol (tool registration, stdio framing, request/response routing). The author writes tool handlers, not protocol code.
  2. flyctl --json was already done — a 2020 Fly.io design decision ("to make them easier to drive from automation") that made structured output a no-op in 2025. See concepts/structured-output-reliability.
  3. Two read-only tools is enough to reproduce an experienced SRE's incident-diagnosis flow against a Fly- hosted app. Fewer tools = more accurate tool selection = smaller context footprint (patterns/tool-surface-minimization).

Canonical usage — unpkg incident diagnosis

Pointed at unpkg (the npm package registry's CDN, running on Fly), Claude produced without further prompting: 10-Machine global topology (11 regions named), criticality classification of 2 non-healthy machines, oom_killed: true event correlation. On the follow-up prompt "try getting logs for one of the critical machines" it extracted the kernel OOM line + per-second incident timeline: OOM kill → SIGKILL → reboot → health-check fail → listener up → health-check pass, ~43 seconds end-to-end. Memory diagnosis: Bun at ~3.7 GB of 4 GB allocated. Ptacek's read: "annoyingly useful … faster than I find problems in apps."

See concepts/agentic-troubleshooting-loop for the planner- executor loop shape.

Security posture

Ptacek's own caveat on the local-MCP-server shape:

"Local MCP servers are scary. I don't like that I'm giving a Claude instance in the cloud the ability to run a native program on my machine. I think fly logs and fly status are safe, but I'd rather know it's safe. It would be, if I was running flyctl in an isolated environment and not on my local machine."

Canonical wiki datum on concepts/local-mcp-server-risk; the natural mitigation is patterns/disposable-vm-for-agentic-loop — run flymcp + flyctl inside a throwaway Fly Machine rather than on the operator's laptop.

Seen in

Last updated · 200 distilled / 1,178 read