Brands we build software with

API operations

220 API operations

published tools

13 published tools

tests

1238 tests

Hetzner is not one API. A Cloud token can only see the project it was created in, and there is no project parameter anywhere in the API — so every project is simply a separate connection. hetzner-mcp makes that visible instead of hiding it: every tool takes the connection by name, and a search can sweep all of them in one call. All 220 live operations stay reachable, but the client is not handed 220 tool schemas — the loop an operator actually repeats fits in thirteen tools, and the rest is called through a searchable catalog.

• Three surfaces stay separate: Cloud (a project), the Hetzner account (Storage Boxes) and Robot (leased physical hardware — the connection is defined, the operations are planned for v0.3). Collapsing an hourly-billed virtual machine and leased physical hardware into one word is how "reboot the server" becomes a question nobody can answer safely.
• Deletes are off by default — not listed-and-refusing, absent. A host that auto-approves non-destructive tools is then auto-approving something genuinely non-destructive.
• Read-only is a ceiling: turned on for a connection, every non-GET is refused at the HTTP client before the socket opens, and the connection cannot opt back out of it.
• No tool schema can name a host — there is no baseUrl, host or credential parameter. An injected instruction pointing at another server has nowhere to land.
• 143 of the 220 operations return an Action rather than a result, so waiting is the default rather than a convenience, and every response states whether the work actually finished.
• No credential is written into any client config. Install writes a pointer only; the token is read from an environment variable, a command, or the machine's credential store.

TypeScript · Model Context Protocol SDK · Zod · vendored OpenAPI codegen

REST operations

189 REST operations

instances × teams

N × M instances × teams

supported clients

8 supported clients

There are already two good ways to reach Coolify from an AI client. coolify-mcp was not written to be a third one, but for the one thing they miss: looking at all of them at once. In the other two the model is one instance per process and one team per token. If you are looking at four boxes and cannot remember which one api-gateway lives on, this is what it is for — one call sweeps all of them. All 189 REST operations are reachable through a generic door, while the default surface is fifteen tools, because competing on tool count means spending the client's context budget on schemas it never calls.

• N Coolify instances and M teams from one connection: every (instance, team) pair is a named connection, and one search sweeps all of them.
• Both stdio and HTTP transport. In HTTP mode the server itself runs as a container on Coolify, reachable from a client on any machine.
• The installer detects eight clients, shows a unified diff of every file it would touch, and writes only after approval. What it writes is a pointer — base URL and token never enter a config file.
• The check command tells you whether the instance is reachable and the token works; doctor reports config health and scans for credentials left at rest.
• Writes sit behind a flag, deletes behind another. The docs say plainly where the alternatives are better — with one instance and one team, Coolify's own endpoint may serve you with less setup.
• Triggering a deploy, reading its status, reading logs and managing environment variables are separate tools because that is the operator's daily loop; everything else goes through the catalog.

TypeScript · Model Context Protocol SDK · stdio and HTTP transport · container deployment