LaunchmaticBack to home
All posts
deep-dive8 min read

The MCP-first deploy platform for AI agents

When we sat down to design the agent-facing surface for Launchmatic, the first instinct was the obvious one: build a great CLI, then wrap it in MCP tools later. We got about a week into that before flipping the order. The CLI is now a thin wrapper around the MCP tools, not the other way around. This is the post about why.

What MCP solves that a CLI doesn't

A CLI is a great surface for a human at a terminal. It's a clumsy surface for an AI agent. The reasons stack up fast:

  1. Output parsing. A CLI prints text. An agent has to parse that text into structured data on every call. Half the bugs in early agent tooling are regex problems.
  2. Auth flow. A CLI assumes a logged-in session. An agent that wants to deploy on behalf of a user has to either store credentials (security risk) or shell out to lm login and somehow drive the OAuth flow (impossible from a tool call).
  3. Streaming. Build logs are a stream. Agents want to summarize the stream, decide if the build failed, and respond. A subprocess.run("lm deploy") swallows that stream.
  4. Tool schemas. Models work better with structured tool definitions than with free-text command help. Claude, GPT, and Gemini all reason more reliably about a deploy(service: str, env: dict) schema than they do about parsing --help output.

MCP solves all four. Tools have JSON Schema input/output, streaming responses, OAuth-based auth, and a standard handshake every model already knows.

What we shipped

Launchmatic's MCP server lives at https://launchmatic.io/mcp (Streamable HTTP, OAuth 2.1). It exposes:

  • deploy — deploy a service, with optional service, branch, env overrides
  • logs — tail logs for a service, with since, follow, level filters
  • services_list — list all services in the agent's team
  • env_get / env_set — read or write environment variables
  • db_create — provision Postgres or Redis, with optional --link to a service
  • domain_add — add a custom domain with auto-SSL
  • rollback — revert to the previous successful image

Plus a meta-tool, launchmatic-agent, that wraps a higher-level "do whatever the user asked, end-to-end" workflow when the calling model wants to delegate the planning step to us.

Adding the server (any agent)

Claude Code:

claude mcp add launchmatic https://launchmatic.io/mcp

OpenAI Codex CLI:

codex mcp add launchmatic https://launchmatic.io/mcp

Cursor: Settings → MCP Servers → paste the URL.

Windsurf: Settings → Cascade → MCP → paste the URL.

The OAuth handshake runs in the user's browser the first time the agent calls a tool. After that, the agent has a per-team token and can call any tool without re-prompting.

What this looks like in a session

A real Claude Code session, abridged:

User: add a /health endpoint that returns the DB ping latency, then deploy

Claude: (edits src/routes/health.ts, runs the test suite)

Claude: (calls deploy MCP tool)

Claude: Deployed. The new /health endpoint is live at https://my-app.launchmatic.app/health and returns {"status":"ok","db_ms":3.4}. Build took 47s.

No copy-paste of CLI commands. No "now run lm deploy in your terminal." The agent does the deploy because it has the tool.

The CLI is now downstream

We kept the CLI because some workflows still want it (CI pipelines, ad-hoc scripts, terminal users who don't run an AI assistant). But the CLI's lm deploy now hits the same MCP deploy tool the agents use. There is exactly one code path. When we add a feature to the MCP tool, the CLI gets it for free.

This had a useful side effect: every deploy primitive has structured input/output by design. The CLI just renders that output as text for humans. No more "the CLI does X but the API does Y" drift.

Why this matters for the broader agent ecosystem

There's an asymmetry forming in how platforms expose themselves to agents. The platforms that ship MCP-native APIs are the ones agents reach for first, because the friction is lower. Telling Claude to "deploy this to Render" requires Claude to construct CLI calls and parse text. Telling Claude to "deploy this to Launchmatic" is a single tool call with structured args.

This is most of why we made the bet. The next two years of developer tooling are going to be agent-driven, and the platforms that win are going to be the ones an agent can use without translation.

What's next

Open agenda for the rest of the year:

  • Per-tool resources alongside tools — so an agent can read a service's recent deploys, env vars, and metrics without an extra round-trip.
  • Sampling support so the MCP server can ask the calling model questions ("is this a Node app or a TypeScript-only library?") when detection is ambiguous.
  • Durable agent contexts — when an agent crashes mid-deploy, resume the workflow on reconnect rather than starting over.

If you're building an agent and want first-class deploy primitives that don't require your model to parse --help output, point it at https://launchmatic.io/mcp and it should work today.

The full machine-readable platform context is at launchmatic.io/llms-full.txt — every supported runtime, every tool signature, every pricing tier in one document an agent can ground on.