Coolify's MCP Server Ships Read-Only: Dokploy Beat It to AI-Driven Deploys, and Neither Can Answer 'Is My Fleet Healthy?'

Coolify's v4.0 release note reads like the "AI agent as operator" story every self-hosted PaaS is racing to tell: an MCP server, so any MCP-aware client — Claude Code, Cursor, Cline — can manage your infrastructure by chat. Connect it, and here's the first thing you can ask it to do: nothing. Not deploy, not redeploy, not roll back a bad release. Coolify's official MCP server exposes exactly 10 tools, and every single one is read-only. The docs say plainly that write operations are "planned for a future release."

That alone would be a minor asterisk on an otherwise solid release. What makes it a real story is the second fact: Dokploy — a direct competitor in the same self-hosted-PaaS category — shipped its own official, first-party MCP server about a month earlier, in its v0.29.0 release, and it isn't read-only. It ships full application lifecycle tools — create, deploy, redeploy, start, stop — among 60-plus tools total, each one annotated with machine-readable safety metadata that tells a client whether it's read-only, destructive, or idempotent before the agent ever calls it.

So the honest framing isn't "the first self-hosted PaaS ships native AI deploy commands." It's this: one competitor shipped a cautious, read-only MCP server; another shipped a write-capable one with real safety scaffolding, first. And neither one — for reasons that have nothing to do with which team moved faster — can answer the question a fleet operator actually needs answered: is my infrastructure healthy, across every node, right now. That gap isn't a roadmap item either team will close with a point release. It's baked into how both platforms are built.

What Coolify v4.0 Actually Shipped​

Coolify's v4.0, released May 18, 2026, is a substantial release on its own terms, MCP server aside. The headline items:

Ollama landing as a first-class deployment target matters beyond a checkbox: it's Coolify explicitly courting the same self-hosted-AI-infrastructure crowd that would want an agent operating the platform in the first place. The 280+ one-click services figure — up roughly 40% from v3's ~200 — is Coolify continuing to compete on breadth of what you can one-click deploy, a different axis entirely from agent-operability.

The multi-server support is the piece worth sitting with, because it's the architectural decision everything downstream — including the MCP server's ceiling — traces back to. One server runs the Coolify control plane: the dashboard, the internal database, Git webhook processing, deployment orchestration. Additional servers register as workers, and the control plane reaches them over SSH to run Docker commands. It's a real capability — you can genuinely run apps across several boxes — but it's one control plane fanning out imperative SSH sessions, not a distributed system with its own consensus or reconciliation layer.

The MCP Surface, Tool by Tool​

Here's what each of the three real, shipped MCP implementations in this category actually exposes, by name.

Coolify's official server — 10 tools, all read:

get_infrastructure_overview, list_servers, get_server, list_projects, list_applications, get_application, list_databases, get_database, list_services, get_service. That's the entire surface. You can ask an agent "what's running on my infrastructure" and get a real answer. You cannot ask it to deploy, restart, or touch an environment variable — those tools don't exist yet in the official server.

Community forks of Coolify's server — write-capable, but third-party: Projects like StuMason's coolify-mcp expose roughly 42 tools, including deploy and rollback-adjacent operations, by calling Coolify's REST API directly with a user-supplied access token. They work, and people run production infrastructure through them today. But they're unofficial: not shipped by Coolify, not audited by Coolify, and every deploy or rollback call routes through a third-party npm package holding a token scoped to your production environment. "AI clients issue deployment commands" is true for Coolify only if you're willing to hand that trust to a project outside Coolify's own release process.

Dokploy's official server — 60+ tools, write-capable, safety-annotated: Shipped in v0.29.0, roughly a month before Coolify's v4.0, Dokploy's first-party MCP server includes full application lifecycle tools — create, deploy, redeploy, start, stop — spanning applications, databases, domains, backups, and user/SSH-key management. Every tool carries readOnlyHint, destructiveHint, and idempotentHint annotations, so an MCP client can distinguish "this call is safe to retry" from "this call redeploys production" before it ever fires — a distinction Coolify's server doesn't need yet, precisely because it has no destructive tools to annotate.

Put side by side, the "first mainstream self-hosted PaaS with native agent-operator tooling" framing doesn't survive contact with the timeline. Dokploy's official, write-capable server predates Coolify's read-only one. What Coolify actually gets right isn't being first — it's shipping the safer half of the feature (read access) before the riskier half (write access), rather than rushing out an unscoped deploy tool to win a release-notes headline. What it leaves out is everything the marketing framing implies it has: an agent still can't deploy anything through Coolify's own, official tooling.

Where the Architecture Caps the MCP Surface​

Here's the part that has nothing to do with which team shipped first, and everything to do with what kind of tool both of them are. Coolify and Dokploy are both single-daemon, SSH-fan-out orchestrators: one control-plane process holds the source of truth, and it reaches every other node by opening an SSH session and running Docker commands. That's a fine architecture for a handful of servers. It has a structural ceiling once the question an agent needs answered is about the fleet as a whole.

Ask either platform's MCP server "is my fleet healthy," and there's no single object to query for that answer — there's a control-plane process that would have to serially SSH into every worker, check in, and aggregate the result live, on every call, with no persistent per-node status to fall back on between checks. Fail one SSH round-trip mid-fan-out — network blip, a worker under load — and the agent's answer is either stale or incomplete, not "one node reported unhealthy" the way a system with per-node state would report it.

Compare that to how a Cluster API-native platform answers the identical question. Cluster API represents each machine in the fleet as its own object — Machine, backed by a MachineDeployment — and a controller continuously reconciles each one's status independently of any single query. "Is my fleet healthy" against a CAPI-based platform is one read against objects a controller already keeps current, not a live fan-out an agent has to wait on and hope completes cleanly. It's the same distinction that shows up when CAPH manages real Hetzner bare metal instead of CAPD's disposable Docker containers: the object graph, not any individual server, is the thing that's actually reconciled.

This isn't a gap either platform closes by shipping more MCP tools. It's downstream of the fundamental decision to model infrastructure as "a control plane with SSH access to some servers" instead of "a declarative object graph a controller keeps in sync." Coolify's own docs already gesture at this limit indirectly — native multi-server orchestration is explicitly framed as still maturing, not a solved problem — and no version of "add a get_fleet_health tool" changes what's actually happening underneath that tool when it's called.

What a Cluster-API-Native MCP Server Needs to Expose​

None of this makes read-only-first the wrong instinct, or write-capable-first the wrong one either — it makes both current implementations a floor, not a ceiling, for what "AI agent as operator" needs to mean for a platform built to run on more than a handful of boxes. Four things worth taking from this comparison directly:

• Task-shaped tools, not a mirror of the REST API. A dozen well-scoped tools — deploy, rollback, get_logs, scale_service — map to how someone actually phrases a request in chat. Dokploy's 60-plus-tool surface and the unofficial Coolify forks' 42 both lean toward one-tool-per-endpoint; that's a token-cost and tool-selection problem worth avoiding from the start, not retrofitting later.
• Per-tool safety annotations as a baseline, not an afterthought. Dokploy's readOnlyHint/destructiveHint/idempotentHint pattern is worth adopting outright — it's the one concrete mechanism in this comparison that lets an MCP client reason about blast radius before a call fires, rather than after.
• Read/write trust tiers that don't share a boundary. A tool that reads infrastructure state and a tool that mutates it shouldn't sit in the same "the agent is allowed to call tools" bucket just because they're registered on the same server — the same lesson the Sentry DSN-injection incident made concrete for any MCP tool consuming untrusted input.
• A write path that can be direct or PR-mediated, per environment. Staging can take a synchronous deploy call; production shouldn't have to choose between "no agent access" and "agent can call a live mutating API with no review step" — routing agent-originated production changes through a pull request caps the blast radius of a confused or manipulated agent without giving up chat-driven deploys entirely.

The fourth item only works at all if the platform underneath has per-node, per-environment state a controller keeps current — which loops back to the architecture problem in the previous section. An MCP server can be as well-designed as Dokploy's and still hit the same wall Coolify's SSH fan-out hits, because the tool surface can only expose what the reconciliation layer underneath actually tracks. Get the object graph right — a real Cluster/Machine/MachineDeployment graph a controller reconciles continuously, not a control plane polling workers on demand — and the MCP tools that query and mutate it inherit that reliability for free. Get it wrong, and no amount of tool-schema polish changes what "is my fleet healthy" actually costs to answer.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a deploy/rollback surface built on Cluster API's reconciled object graph, not an SSH fan-out from a single control-plane box. Star the repo on GitHub or deploy your first app today.

Sources​

• Coolify MCP Server — Official Documentation
• Coolify Changelog
• Coolify v4.0.0: A Sovereign Deployment Platform Beyond Heroku and Vercel
• StuMason/coolify-mcp — MCP server for Coolify, 42 tools
• Dokploy/mcp — The Official MCP package for Dokploy
• Dokploy v0.29.0: AI-Powered Debugging, MCP Server & CLI, Shared Git Providers
• Cluster API (CAPI): What It Is and When You Need It