Model Context Protocol for deployment platforms — a practical primer

Published 2026-05-08 by tavin

The Model Context Protocol — MCP — is, depending on who you ask, “an open standard for tools and AI clients to talk to each other,” “the USB-C of LLM tooling,” or “yet another protocol.” All three framings are partially correct.

For deployment platforms, the practical answer is simpler: MCP is the wire format that lets AI coding agents call your platform’s product operations as structured tools instead of clicking through a dashboard or scraping a CLI.

This post is a primer for engineers who already understand HTTP APIs and want to know what changes when they expose those APIs through MCP.

What MCP actually is

MCP is a JSON-RPC-flavored protocol maintained at modelcontextprotocol.io and implemented by clients including Claude, Cursor, Codex, and Zed. A server exposes:

• Tools — typed functions the agent can call.
• Resources — read-only context the agent can fetch.
• Prompts — reusable templates a user can invoke.

The transport options that matter today are stdio (for local tools spawned as a subprocess) and Streamable HTTP (for hosted servers that an agent connects to over the network with Bearer auth).

For a deployment platform, Streamable HTTP is the relevant one. Your agent does not want to launch a local subprocess to ship code; it wants to talk to your platform over the same network it already uses.

Every PaaS is shipping an MCP server

The big platforms have all moved in the same direction over the last year:

• Render’s MCP server exposes services, deploys, env groups, and logs.
• Railway has both an MCP server and a Railway Agent.
• Vercel ships a hosted MCP for projects, deployments, and logs.
• Fly’s flyctl exposes MCP via flyctl mcp.
• tavin.cloud has a Streamable HTTP MCP at https://api.tavin.cloud/api/v1/mcp.

This is good for the market. It means an AI agent in Claude Code or Cursor can speak to multiple platforms with the same protocol surface. The interesting question is no longer “does this PaaS support MCP?” — it is “what authority does the agent receive, and how is that authority structured?”

We argued the wedge has shifted in this earlier post. MCP is the transport. The product question is what the tools do, who can call them, and what happens after.

What “good MCP design” looks like

A useful MCP surface for a deployment platform has a few load-bearing properties.

Tools should match product operations, not CLI gestures

Tools should look like the things you actually want the agent to do:

• init_from_repo
• deploy_project_source
• wait_for_deployment
• set_env
• get_deployment_build_logs
• get_deployment_runtime_logs
• roll_back_deployment

Bad MCP tools are thin wrappers around dashboard URLs (open_project_settings) or shell commands (run_cli). Those exist mostly so the agent can paper over a missing API. They make the protocol look fancier without changing the authority surface.

Good MCP tools are typed product operations the platform would expose anyway, with structured input and output the agent can reason over. This is the same principle as a well-designed REST API, expressed through a different transport.

Output should be structured

If the agent has to parse bun run build | grep "error" to decide whether a deploy succeeded, you have lost.

Tools should return JSON with explicit fields: deployment ID, status, build duration, log streams. The agent then reasons about a structured object instead of pattern-matching against a free-form string. tavin.cloud’s wait_for_deployment returns status, deploymentId, serviceUrl, failureReason, and a typed log handle, not a colorized terminal blob.

Authority should be explicit and revocable

The MCP transport does not decide who can do what. That is your platform’s auth model.

Good defaults:

• OAuth for an agent acting on behalf of a logged-in user. The agent receives an access token tied to that user; revoking the OAuth client revokes the agent’s authority.
• Personal Access Tokens (PATs) for headless workflows. PATs are scoped, named, listable, and revocable independently of the user’s browser session. tavin.cloud users create PATs with tavin tokens new <name>.
• One-time deploy intents for an agent acting on behalf of a not-yet-logged-in user — covered in agent-safe deployment is the wedge.

Bad defaults:

• A long-lived API key that does everything and lives in the agent’s ~/.config.
• A reused dashboard cookie.
• “Just give the agent your kubeconfig.”

The wire format is identical in all cases. The authority shape is wildly different.

Audit rows are part of the design

If your MCP server does not record who called what, you cannot answer the basic incident questions: which agent triggered this deploy, with which credential, on whose behalf? Audit rows are not a security afterthought — they are the contract that makes it safe to grant an agent any production authority at all.

A concrete example: a deploy-and-tail flow

The agent receives “deploy this branch to staging and tell me when it is ready” from the user.

A reasonable MCP flow on tavin.cloud:

1. Agent calls init_from_repo({ repoUrl, branch: "staging" }).
2. Agent calls deploy_project_source({ projectId, branch }).
3. Agent calls wait_for_deployment({ deploymentId }) — single tool, structured result with status: "succeeded" or status: "failed", failureReason: "...".
4. On success, agent reports the live URL and offers to tail logs via get_deployment_runtime_logs({ deploymentId }).
5. On failure, agent fetches get_deployment_build_logs({ deploymentId }) and uses the structured log lines to suggest a fix.

The tool catalog is in the MCP docs. The point is that every step is an explicit call with typed input and output, traceable in audit rows, callable with a scoped credential.

Why this matters for non-AI workflows

You do not need an AI agent to benefit from a well-designed MCP surface. The same JSON-RPC over Streamable HTTP works for:

• CI systems that want to deploy from a repo without juggling a CLI binary.
• Internal scripts that want a typed API instead of a curl + jq pipeline.
• Other platforms that want to integrate with yours without writing a custom SDK.

MCP is, structurally, a typed API description with a transport. The “AI” part is mostly that AI clients ship with first-class MCP support out of the box. The protocol is useful regardless of what is on the other end.

What this changes for a repo-to-container PaaS

The bet for tavin.cloud is that repo-to-container deployment is a workflow worth exposing through agent-safe primitives, not a workflow the agent has to script around a dashboard.

That bet has three implementation pieces:

1. The repo stays the cloud contract. Code, lockfiles, build commands, and Dockerfiles live in Git. (Why the repo should be the contract.)
2. Auto-detection handles the common case. Railpack reads the repo and produces a normal container without a hand-written recipe. (When to choose a repo-to-container PaaS over serverless.)
3. The agent talks to the platform over MCP, with scoped authority. OAuth, PATs, deploy intents — never a dashboard cookie.

The MCP server is not the product. The product is repo-to-container PaaS where AI agents can operate scopes safely. MCP is the wire format that makes that operation legible to clients you do not control.

Where to start

If you are evaluating MCP for your own platform: read the MCP spec, look at the TypeScript and Python SDKs, and pick a small surface to ship first. A platform that exposes three good tools beats one that exposes thirty trivial wrappers.

If you are an AI coding agent user: try connecting an MCP-aware client to a deployment platform. tavin.cloud’s MCP setup is documented in the MCP guide, with examples for Claude Code, Cursor, and any other Streamable HTTP MCP client.

The protocol is interesting. The product design around it is what determines whether the workflow is safe enough to ship through.