Deploying with AI agents: what MCP actually changes

Ask a chat assistant to deploy your app in 2024 and you got a plausible-looking shell script. You still had to read it, trust it and run it yourself. The gap was never the model's reasoning — it was that the model had no hands.

The Model Context Protocol closes that gap in a boring, useful way: a server exposes a list of typed tools, the client calls them, results come back as structured data. No screen scraping, no browser automation, no prompt-injecting your own dashboard.

What an agent can actually do

DeployCloud ships an MCP server with 33 tools, and they map one-to-one onto the REST API — so the agent is not driving a special "AI mode" with different rules. It is making the same calls the CLI makes:

• Ship it. Queue a deploy, watch it reach running, roll back to a previous release without a rebuild.
• Diagnose it. Runtime logs, the full build log of any deployment, CPU/memory history, recent alerts.
• Change it. Environment variables, replica count, custom domains, add-ons (Postgres, Redis, object storage), cron jobs.
• Poke it. Run a one-off command inside the live release environment — a migration, a REPL, a SELECT count(*).

The useful shape is a loop the agent can close on its own. "Deploy the api branch" is one tool call; "why did it fail" is a second one against the build log; "roll it back" is a third. You are not copying error text between windows.

The part people underestimate: it works from a phone

Not because the MCP server runs on your phone — it does not. It speaks JSON-RPC over stdio, so it runs wherever your assistant runs: your laptop, a dev box, a container.

What makes the phone case work is that none of this is a special path. Every tool is a plain HTTPS call authenticated with a bearer token, and the dashboard is a normal web app. So the honest version of "deploy from anywhere" is:

• From your laptop, talk to an agent that has the MCP server configured.
• From your phone, open the dashboard and press the button, or curl the API from a shell app.
• From CI, the same token drives the same endpoints — no separate integration to maintain.

What it does not change

An agent with deploy access is a deployer. On most platforms — including this one — a deploy is arbitrary code running on the platform's infrastructure, so the tool list is not a sandbox. Three things follow:

1. 1Scope the token, not the prompt. Give the agent its own API token you can revoke, rather than reusing yours. A prompt saying "only touch staging" is not an access-control mechanism.
2. 2Read the destructive ones. Deleting an app or restoring a database backup is not recoverable by asking nicely. Good MCP servers require an explicit confirmation flag on those; ours does.
3. 3Keep the audit trail. Every action should be attributable after the fact, whether a human or an agent took it.

None of that is an argument against agentic deployment. It is the same argument for least privilege that applied to CI tokens ten years ago, and the answer is the same: a narrow credential, revocable, with a log.

Setting it up

Create an API token in the dashboard, then point your client at the server. For Claude Code that is one command:

Claude Desktop, Cursor and anything else speaking MCP over stdio take the same shape in their own config file. There is nothing DeployCloud-specific about the transport — if a client supports MCP, it works.

From there the phrasing that works best is the phrasing you would use with a colleague: name the app, say what you want, and let it ask for the parts you left out.

Is this actually better than typing?

For a single git push, no — pushing is already one command, and the platform deploys on its own. The agent earns its place on the messy paths:

The pattern: it is worth most exactly when you are least equipped — on a phone, half asleep, or in a codebase you did not write.