Which integrations are available for this server?

Supports deploying Gitea as a one-click service within Coolify. Allows deploying applications from GitHub repositories using deploy keys or GitHub App integration. Enables creation and management of PostgreSQL databases, including backups and environment variables.

How do I use awesome-coolify-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@awesome-coolify-mcp check if my Coolify instance is online" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

awesome-coolify-mcp

by clezcoding

Overview Schema Related Servers Score Discussions

TypeScript

Remote

This MCP server provides a comprehensive interface for AI agents to operate and manage Coolify (self-hosted PaaS) instances, covering infrastructure control, deployments, diagnostics, and emergency operations.

System & Meta: Verify API connectivity, check Coolify version, get an aggregate infrastructure overview (servers, projects, apps, services, databases), and retrieve the MCP server's own version without an API call.

Resource Discovery: List or fuzzy-search applications, services, databases, servers, projects, and environments by name, domain, or IP with pagination.

Diagnostics & Logging: Investigate app or server health, run fleet-wide issue scans grouped by severity, and retrieve bounded runtime or deployment logs with triage context.

Application Lifecycle: Create, update, delete, start, stop, restart, and deploy applications (with optional force rebuild); manage environment variables (list, get, create, update, delete, bulk-update, sync from .env file).

Deployment Tracking: List deployments, get details, cancel in-flight deployments, watch deployments with bounded polling/backoff, and retrieve build logs.

Service & Database Management: Full CRUD and lifecycle control for services and databases (8 engines supported); manage database backup schedules (create, list, update, delete, trigger immediate backups, view history); discover one-click service types.

Server, Project & Environment Management: Register, configure, validate, and delete servers; full CRUD for projects and environments.

SSH Key Management: List, create, update, and delete private SSH keys, with PEM content masked by default.

Recipes & Orchestration: Multi-resource orchestration in a single call — create git-backed apps, app+database stacks with auto-wired DATABASE_URL, or one-click services.

Setup Wizard: Preflight checks, wire existing workloads, or provision greenfield projects with guided steps.

Emergency Operations (gated): Stop all running applications fleet-wide, or redeploy/restart all apps in a project — all requiring explicit confirm: true.

Multi-Instance Registry: Register and manage multiple named Coolify instances, rotate credentials, set defaults, and import from environment variables.

Local Manifest Cache: Read/write/sync a local .coolify/manifest.json for offline UUID resolution, diff against live API, and prune stale entries.

Offline Documentation: Search a bundled Coolify troubleshooting index without any live web fetch.

Safety Features: Destructive actions require confirm: true; sensitive values (passwords, tokens, keys) are masked as *** by default (use reveal: true for plaintext); structured error codes (e.g., COOLIFY_401) with recovery hints; automatic retries with exponential backoff for transient failures.

📋 Table of contents

Related MCP server: coolify-mcp

🔭 Overview

Self-hosted Coolify is one of the best open-source alternatives to Heroku/Vercel-style PaaS platforms — but wiring it up to an AI coding agent has historically meant piecing together several small, overlapping community MCP integrations, each with its own schema, its own error format, and its own idea of what "safe" looks like.

awesome-coolify-mcp 1.1.4 replaces that patchwork with a single, community-maintained MCP server that speaks Coolify's REST API 4.1.x through a clean, action-based tool surface. Source, docs, and npm distribution live in one public repo — clezcoding/awesome-coolify — while the installable package stays awesome-coolify-mcp. Instead of memorizing dozens of near-identical tool names, your agent calls one of 19 tools with an action field:

application({ action: "deploy", uuid: "<app-uuid>", wait: false })
deployment({ action: "watch", deployment_uuid: "<deployment_uuid>", timeout: 300 })
diagnose({ action: "scan" })
emergency({ action: "stop_all", confirm: true })

Under the hood, every call goes through the same request pipeline: Zod-validated input, retrying HTTP client, secret-aware output masking, and structured error envelopes with recovery hints — so your agent fails gracefully instead of guessing.

NOTE

This is a community project built for people who run their own Coolify instances.It is not affiliated with or endorsed by Coolify Labs.

🆚 Why awesome-coolify-mcp

Typical setup without it	With awesome-coolify-mcp
Several overlapping community MCP tools, each with its own schema	One server, one consistent schema
Dozens of granular, single-purpose tools per resource	19 tools with consistent `action` discriminators
Ad-hoc error strings that agents have to guess at	Structured codes (`COOLIFY_401`, `COOLIFY_404`, …) + machine-readable recovery hints
Secrets can leak straight into agent context	Default secret masking + confirmation gates on destructive actions
Read a wall of raw JSON to find what changed	Bounded, paginated projections tuned for LLM context windows

Today, the shipped surface covers day-2 operations and infrastructure creation: verify connectivity, discover fleets, deploy and watch builds, inspect bounded logs, diagnose incidents, run gated emergency ops, and manage applications, services, databases, SSH keys, servers, projects, environments, backups, and environment variables.

✨ Features

19 action-based tools — call application({ action: "deploy", uuid }) instead of hunting through dozens of granular tool names. The registered surface is system, meta, resource, diagnose, application, emergency, deployment, service, database, private_key, instance, manifest, server, project, environment, docs, recipe, setup, and intelligence.
Multi-instance registry & routing — register every Coolify instance you own in ~/.coolify-mcp/instances.json via the instance tool; per-call credential resolution with no cross-instance leakage.
Coolify Cloud aware — instance({ action: "cloud-info" }) for local discovery, team-scoped tokens, and structured cloud error codes (COOLIFY_CLOUD_FORBIDDEN, COOLIFY_CLOUD_UNSUPPORTED).
Local manifest cache — .coolify/manifest.json sync via manifest({ action: "sync" }), best-effort auto-hooks on app/service/DB mutations, and _meta.manifestWarning when the cache is stale.
Server branding — MCP list icon via serverInfo.icons (embedded data URI + jsDelivr CDN entries from docs/assets/).
Ops workflows that mirror real incidents — a single system.infrastructure_overview call for the big picture, fuzzy resource.find when you only remember a name or domain, diagnose.app / diagnose.server for a specific suspect, and diagnose.scan when you just know something is wrong fleet-wide.
Deploy lifecycle agents can drive — start/stop/restart, force rebuild, deployment.watch with bounded backoff, deployment.logs for builds, bounded application.logs, and runtime follow with idle/overall timeouts.
Full workload CRUD — create, inspect, update, delete, and operate applications, services, and databases; discover live one-click IDs with service.list-types.
Recipes and guided setup — create git apps, app-plus-database stacks, and one-click services; run setup.preflight, setup.wire, or setup.resume; install four matching IDE workflow skills.
Safety by default, not by convention — emergency mutations require an explicit confirm: true; sensitive keys (password, token, secret, private, env) render as *** unless you opt in with reveal: true.
Agent-friendly failure modes — every error is a parseable envelope with a code, a human message, and recoveryHints; transient network/429/5xx failures retry automatically with exponential backoff.
Broad client coverage out of the box — Cursor, VS Code / GitHub Copilot, Claude Desktop, Claude Code, Windsurf, and 15+ more via the install configurator.

🏗️ How it works

MCP client (Cursor / Claude / VS Code / …)
        │  stdio MCP
        ▼
awesome-coolify-mcp  (19 tools + action discriminator)
        │  optional ~/.coolify-mcp/instances.json resolution
        │  HTTPS + Bearer token
        ▼
Coolify REST API 4.1.x  (servers · projects · applications · services · databases)

The server itself is intentionally boring: it holds no long-lived state and never touches your IDE's config files. Your MCP host (Cursor, Claude, VS Code, …) injects COOLIFY_URL and COOLIFY_TOKEN through its MCP config's env block — or you register named instances in ~/.coolify-mcp/instances.json via the instance tool. The process reads credentials from its environment (or the registry) and forwards authenticated requests to your Coolify instance over HTTPS.

🚀 Quick start

Prerequisites

Node.js 24+ (Active LTS; CI uses Node 24)
A self-hosted Coolify instance on 4.1.x
An API token from Coolify → Keys & Tokens (authorization docs)

Run it directly with npx — no global install needed:

npx -y awesome-coolify-mcp

Wire the two required environment variables into your MCP host (see Install for every client). Once connected, a minimal smoke test looks like this:

meta({ action: "version" })                       // server identity — no Coolify call
system({ action: "verify" })                      // authenticate + connectivity check
system({ action: "infrastructure_overview" })     // servers, projects, apps, services, DBs at a glance

NOTE

Multi-instance users: register each Coolify instance first with instance({ action: "add", name, url, token }), then call system({ action: "verify" }). Single-instance setups can skip the registry and use COOLIFY_URL / COOLIFY_TOKEN in MCP env.

IMPORTANT

Emergency actions (stop_all, redeploy_project, restart_project) require confirm: true. Call them without confirm first — you'll get a would_affect preview and no mutation runs. Only pass reveal: true when you genuinely need plaintext secrets back.

📦 Install

There are three equally supported paths — pick whichever fits your workflow.

1. One-click deeplink

Best when you already have your Coolify URL and token handy. Placeholder credentials work fine too — you'll be prompted to fill them in, or you can swap them afterwards.

Both editors implement a protocol handler that reads a JSON server configuration straight out of the URL:

Client	Scheme	Encoding
Cursor	`cursor://anysphere.cursor-deeplink/mcp/install?name=…&config=…` (mirrored at `https://cursor.com/en/install-mcp?…` for a friendlier landing page)	`config` is base64-encoded JSON
VS Code / Copilot	`vscode:mcp/install?name=…&config=…`	`config` is URL-encoded JSON

Clicking the button opens your editor, shows the server it's about to add, and lets you review or edit the command/env before accepting — nothing is installed silently.

2. Install configurator (GitHub Pages)

Use the browser configurator to type in your real COOLIFY_URL / COOLIFY_TOKEN and generate a ready-to-paste snippet for your exact client — JSON, TOML, or YAML depending on what that client expects.

Everything runs client-side in your browser. Your token is never sent to a backend, logged, or stored anywhere but the config file you paste it into.

3. Manual MCP config

Paste this into your host's MCP configuration file. Cursor example (~/.cursor/mcp.json for global, or .cursor/mcp.json in a project):

{
  "mcpServers": {
    "awesome-coolify-mcp": {
      "command": "npx",
      "args": ["-y", "awesome-coolify-mcp"],
      "env": {
        "COOLIFY_URL": "https://coolify.example.com",
        "COOLIFY_TOKEN": "YOUR_COOLIFY_API_TOKEN",
        "COOLIFY_VERIFY_SSL": "true",
        "COOLIFY_MCP_LOG": "info"
      }
    }
  }
}

A ready-made copy-paste template also lives at docs/mcp.example.json.

TIP

UsingCoolify Cloud? Generate a team-scoped token and follow the registry setup in docs/en/cloud.md.

IDE skills (Cursor, Claude Code, Codex)

Install Coolify workflow skills for Cursor, Claude Code, and Codex:

npx skills add clezcoding/awesome-coolify -a cursor -a claude-code -a codex

After MCP install, run setup({ action: "preflight" }) or see the Setup guide for gh preflight, project linkage, and greenfield provisioning.

🖥️ Supported clients

Client	Config location	Notes
Cursor	`~/.cursor/mcp.json`	One-click deeplink or manual JSON
VS Code / GitHub Copilot	`.vscode/mcp.json`	Native `inputs` prompts for URL/token — no plaintext in the file
Claude Desktop	`claude_desktop_config.json`	Manual JSON or configurator output today
Claude Code	`~/.claude.json` or `.mcp.json`	stdio via `npx -y awesome-coolify-mcp`
Windsurf	`~/.codeium/windsurf/mcp_config.json`	Same `npx` + `env` pattern as Cursor

The install configurator covers a much wider matrix — OpenCode, Codex CLI, Gemini CLI, Cline, Kilo Code, Goose, LM Studio, Hermes Agent, Kimi Code, Google Antigravity, OpenClaw, and more — with the correct config shape for each.

NOTE

Claude Desktop currently uses manual JSON or configurator output.

🔐 Environment variables

Variable	Required	Default	Description
`COOLIFY_URL`	yes*	—	Coolify base URL, no trailing slash — e.g. `https://coolify.example.com`
`COOLIFY_TOKEN`	yes*	—	Bearer API token, scoped to your team
`COOLIFY_VERIFY_SSL`	no	`true`	Set to `false` only for self-signed certs on local/dev instances
`COOLIFY_MCP_LOG`	no	`info`	Log verbosity: `debug` · `info` · `error`

Credentials are read from the process environment (your IDE's MCP env block) or an optional local .env file when running the CLI directly. They are never echoed back inside tool responses.

NOTE

With the multi-instance registry (~/.coolify-mcp/instances.json), COOLIFY_URL and COOLIFY_TOKEN become optional — the instance tool resolves credentials per call. Env vars remain the simplest path for single-instance setups.

☁️ Coolify Cloud

awesome-coolify-mcp works with Coolify Cloud using the same 19 tools — team-scoped tokens, structured cloud error codes (COOLIFY_CLOUD_FORBIDDEN, COOLIFY_CLOUD_UNSUPPORTED), and local instance action cloud-info for discovery.

Run instance({ action: "cloud-info" }) before your first Cloud session — it returns isCloud, resolved url, credential source (registry | env | infer), knownLimits, and a docs link. No live API call.

Full setup, smoke test, and known limits → docs/en/cloud.md

💬 MCP Prompts

Six parameterized workflow prompts return numbered step guidance (English bodies) that orchestrate existing tools. Most arguments are optional — open any prompt without prefill.

Prompt	Args (all optional unless noted)	Purpose
`deploy`	`instance?`, `uuid?`, `force?`	Deploy an application and monitor until terminal status
`diagnose`	`instance?`, `uuid?`	Investigate app, server, or fleet-wide issues (includes `diagnose.analyze`)
`new-project`	`instance?`, `name?`, `server_uuid?`	Create project, environment, and optional server linkage
`incident`	`instance?`, `uuid?`, `project_uuid?`	Triage with `diagnose.analyze`, logs, restart, or emergency redeploy
`rollback`	`instance?`, `uuid?`, `name?`	Preview then confirm-gated `deployment.rollback` (STOP for human approval)
`maintenance-window`	`instance?`, `uuid?`, `resource_type`	Guided change window using existing confirm-gated mutations

Prompt handlers never read .coolify/manifest.json from disk — they steer the agent to resolve UUIDs from manifest or ask the user. Playbooks never auto-set confirm: true.

🧰 Tools reference

Every domain is exposed as one MCP tool with an action discriminator, so your agent's tool list stays short while the capability surface stays wide.

system({ action: "health" })
application({ action: "deploy", uuid: "<app-uuid>", wait: false })
deployment({ action: "watch", deployment_uuid: "<deployment_uuid>", timeout: 300 })
emergency({ action: "stop_all", confirm: true })

🖥️ `system` — connectivity & overview

Your first call in any session: is Coolify reachable, and what does the fleet look like right now?

Action	Purpose
`health`	Verify Coolify API reachability
`version`	Coolify instance version string
`verify`	Authenticate; returns connectivity + version in one call
`infrastructure_overview`	Aggregate counts across servers, projects, applications, services, databases

🏷️ `meta` — server identity

Action	Purpose
`version`	awesome-coolify-mcp's own package name + semver — no Coolify call at all

🔎 `resource` — discovery

For when you know roughly what you're looking for but not its exact UUID.

Action	Purpose
`list`	Applications, services, and databases as summary projections, with pagination `_meta`
`find`	Fuzzy search by name, domain, or IP across servers and resources — ranked, capped at 10

🩺 `diagnose` — investigation

The tool you reach for when something feels wrong but you don't yet know what.

Action	Purpose
`app`	App status, health, env var count, and recent deployments
`server`	Server resources, domains, and reachability
`scan`	Fleet-wide issues grouped by severity — the "what's on fire" button
`logs`	Resolve an application, return triage context, and optionally include bounded runtime or deployment logs
`analyze`	Log Brain — rule-based pattern triage on runtime (and optional build) logs; advisory-only (`crash_loop`, OOM, etc.)

🚀 `application` — app operations

Action	Purpose
`get`	Detailed application configuration
`start` / `stop` / `restart`	Container lifecycle control
`deploy`	Trigger a deploy with optional `force` rebuild; use `wait: false` + `deployment.watch` (recommended) or legacy `wait: true` poll
`logs`	Bounded runtime logs, or bounded follow mode with idle and overall timeouts
`envs:list` / `envs:get`	List or fetch env vars (values masked as `***` unless `reveal: true`)
`envs:create` / `envs:update`	Create or update individual env vars (supports `is_preview`, `is_literal`, `is_multiline`, `is_shown_once`)
`envs:delete`	Delete one env var — requires `confirm: true`
`envs:bulk-update`	Patch many env vars at once — requires `confirm: true`
`envs:sync`	Diff/apply a local `.env` file or inline content — application only; see Resource env vars
`envs:promote`	Compare and promote env vars between two applications in the same Coolify instance (product name: env.promote); preview by default — see Resource env vars

📈 `deployment` — deploy tracking

Action	Purpose
`list`	Deployments for a given application
`get`	Status, commit, and timing details for one deployment
`watch`	Poll until terminal with bounded timeout, backoff, and jitter
`cancel`	Cancel an in-flight deployment cleanly
`logs`	Bounded deployment build logs by deployment UUID, or newest deployment for an application
`preflight`	Advisory read-only deploy risk check: `instance_health`, `env_completeness`, `recent_deployment_failures`, `dns_readiness` → `risk_score` / `risk_level`; env values masked; no live DNS probes
`rollback`	Confirm-gated recovery to prior successful `finished` deployment when the newest deployment is already `finished`; errors with `COOLIFY_ROLLBACK_UNAVAILABLE` when only one successful deployment exists — git apps pin `git_commit_sha` via `updateApplication` then `triggerDeploy`; preview without `confirm: true`

🛡️ Deploy guard (`preflight` + `rollback`)

Action	Safety
`preflight`	Read-only — never calls deploy/mutate APIs; `advisory: true`; `blocking` when risk is critical or a deploy is in progress
`rollback`	Two-step like emergency ops: omit `confirm` → `COOLIFY_CONFIRM_REQUIRED` + `rollback_target` preview (prior successful `finished`, not the current tip when already finished); `confirm: true` → composite pin+deploy (no dedicated Coolify rollback REST endpoint)

deployment({ action: "preflight", uuid: "<app-uuid>" })
// risk acceptable → follow recommended_actions to application.deploy
deployment({ action: "rollback", uuid: "<app-uuid>" }) // preview
deployment({ action: "rollback", uuid: "<app-uuid>", confirm: true, wait: true })

⏱️ Watch — bounded deploy monitoring

After application.deploy with wait: false, call deployment.watch — do not loop deployment.get manually.

Behavior	Detail
Default timeout	300 seconds
Poll interval	Starts at 3s, caps at 30s with equal-jitter backoff
Timeout recovery	Re-call `deployment.watch` with the same `deployment_uuid` (raise `timeout` for slow builds)
Failed / cancelled	Tool returns a clear error — do not treat as success
Legacy	`application.deploy wait:true` still works but is back-compat only; prefer watch

application({ action: "deploy", uuid: "<app-uuid>", wait: false })
deployment({ action: "watch", deployment_uuid: "<deployment_uuid>", timeout: 300 })

The shipped IDE skill packs use this same bounded watch flow and document timeout recovery.

🧩 `service` / `database` — sidecar lifecycle

Tool	Actions
`service`	`get`, `start`, `stop`, `restart`, `deploy`, `create` (one-click type XOR compose), `update`, `delete`, `delete_preview`, `envs:list`, `envs:get`, `envs:create`, `envs:update`, `envs:delete`, `envs:bulk-update`
`database`	`get`, `start`, `stop`, `restart`, `create` (8 engines), `update`, `delete`, `delete_preview`, `envs:list`, `envs:get`, `envs:create`, `envs:update`, `envs:delete`, `envs:bulk-update`, `backup:create`, `backup:list`, `backup:update`, `backup:delete`, `backup:now`, `backup:history`

🍳 `recipe` — multi-resource orchestration

One MCP call to stand up common workload patterns — application + database wiring, git apps, or validated one-click services.

Action	Purpose
`create-git-app`	Create a git-backed application with local `build_pack` detection (`Dockerfile` / `Dockerfile.*` glob)
`create-app-db`	Create a database + application and wire `DATABASE_URL` (or custom `env_key`) between them
`create-one-click`	Create a one-click service after validating `type` against the live service-templates catalog
`recommend`	Advisory stack suggestion from the live service-templates catalog — never creates resources

Safety: Recipe creates are intentional — no confirm gate. No dry-run / preview. Partial failure does not auto-rollback; created UUIDs are returned in error.data. Connection strings are masked unless reveal: true. recommend is read-only / advisory.

recipe({ action: "create-git-app", server_uuid, git_repository, git_branch, repo_path: "/path/to/repo" })
recipe({ action: "create-app-db", server_uuid, app_name, db_name, db_engine: "postgresql" })
recipe({ action: "create-one-click", server_uuid, type: "gitea" })
recipe({ action: "recommend", stack: "Next.js + Postgres" })

Also use service.list-types to discover valid one-click type IDs before create-one-click.

🌱 Resource environment variables (`envs:*`)

Manage Coolify runtime configuration on applications, services, and databases through envs:* actions on the existing domain tools — no separate env MCP tool.

Tool	`envs:*` actions	Notes
`application`	`envs:list`, `envs:get`, `envs:create`, `envs:update`, `envs:delete`, `envs:bulk-update`, `envs:sync`, `envs:promote`	Only tool with local `.env` sync and cross-app env promote
`service`	`envs:list`, `envs:get`, `envs:create`, `envs:update`, `envs:delete`, `envs:bulk-update`	No sync — use `application` for `.env` diff/apply
`database`	`envs:list`, `envs:get`, `envs:create`, `envs:update`, `envs:delete`, `envs:bulk-update`	`is_preview` is not supported on database env vars (Coolify OpenAPI gap)

Confirm gates: envs:delete and envs:bulk-update always require confirm: true on all three tools. On application only, envs:sync requires confirm: true when applying (dry_run: false, the default) or when prune: true. envs:promote requires confirm: true when applying (dry_run: false).

Reveal policy: Env values render as *** by default. Pass reveal: true only after the human explicitly asks for plaintext — the agent must not auto-set reveal: true.

envs:sync semantics (application only): Supply exactly one of env_file (local path) or env_content (inline .env text). dry_run: true returns a diff (added, updated, unchanged, removed, optional conflicts) with no API writes; default dry_run: false applies changes. Remote keys missing locally are never deleted unless prune: true (also requires confirm: true). When local and remote values differ, set conflict_policy to overwrite, keep_remote, or abort after asking the human — apply with conflicts and no policy returns COOLIFY_CONFIRM_REQUIRED.

envs:promote semantics (application only, same instance): Product docs may say env.promote; the implemented action is application.envs:promote. Compare env vars between source_uuid and target_uuid (two applications in one Coolify instance — no cross-instance fan-out). Default dry_run: true returns preview buckets (only_in_source, only_in_target, value_mismatches) plus structured promotion_suggestions with follow-up tool/action hints; values are masked unless reveal: true. Applying copies into the target requires confirm: true. Default conflict_policy is keep_remote — mismatched target keys are skipped unless the human opts into overwrite or abort.

application({ action: "envs:list", uuid: "<app-uuid>" })
application({ action: "envs:sync", uuid: "<app-uuid>", env_file: "./.env", dry_run: true })
application({ action: "envs:sync", uuid: "<app-uuid>", env_content: "API_KEY=EXAMPLE_VALUE\n", confirm: true, conflict_policy: "overwrite" })
application({ action: "envs:promote", source_uuid: "<source-app-uuid>", target_uuid: "<target-app-uuid>", dry_run: true })
application({ action: "envs:promote", source_uuid: "<source-app-uuid>", target_uuid: "<target-app-uuid>", dry_run: false, confirm: true, conflict_policy: "keep_remote" })

💾 Database backups (`backup:*`)

Configure, list, update, delete, and trigger backup schedules — and inspect execution history — on the existing database tool. No separate backup MCP tool.

Action	Purpose
`backup:create`	Create a backup schedule (frequency required; optional S3, retention, `backup_now: true`)
`backup:list`	List backup schedules for a database
`backup:update`	Update schedule fields (frequency, retention, S3 flags)
`backup:delete`	Remove a schedule — requires `confirm: true`
`backup:now`	Trigger an immediate backup run
`backup:history`	List executions for a schedule (status, timestamps, size)

Parent identity: All backup actions require the parent database via uuid or name. Schedule-scoped actions (backup:update, backup:delete, backup:now, backup:history) also require scheduled_backup_uuid.

Confirm gates: backup:delete requires confirm: true — otherwise COOLIFY_CONFIRM_REQUIRED. delete_s3 defaults false (config-only delete). When delete_s3: true, deletion still requires confirm: true — purging S3 artifacts is treated as destructive.

Frequency (Pitfall 1): backup:create accepts OpenAPI named presets (every_minute, hourly, daily, weekly, monthly, yearly) or a cron expression. backup:update accepts presets only — passing cron on update returns COOLIFY_VALIDATION_ERROR.

backup:now semantics: Maps to Coolify PATCH with { backup_now: true } on the schedule — no separate trigger endpoint. Requires scheduled_backup_uuid.

Reveal policy: S3-related credentials in backup config responses are masked as *** by default. Pass reveal: true only after the human explicitly asks for plaintext — the agent must not auto-set reveal: true.

Out of scope (v2.x+): Backup execution delete, restore/import from backup, and S3 storage destination CRUD are not available in this release.

database({ action: "backup:list", uuid: "<db-uuid>" })
database({ action: "backup:create", uuid: "<db-uuid>", frequency: "daily", save_s3: false })
database({ action: "backup:now", uuid: "<db-uuid>", scheduled_backup_uuid: "<schedule-uuid>" })
database({ action: "backup:delete", uuid: "<db-uuid>", scheduled_backup_uuid: "<schedule-uuid>", confirm: true })

🔑 `private_key` — SSH key CRUD

Manage Coolify private keys with PEM content masked by default.

Action	Purpose
`list` / `get`	List or fetch a key (PEM masked unless `reveal: true`)
`create` / `update`	Add or rotate SSH keys
`delete` / `delete_preview`	Remove a key, or preview dependents before delete

🖧 `server` — server CRUD & validation

Action	Purpose
`get`	Server details, domains, and reachability
`create` / `update`	Register or reconfigure a server
`validate`	Trigger Coolify's server validation check
`delete` / `delete_preview`	Remove a server, or preview dependents first

📁 `project` — project CRUD

Action	Purpose
`list` / `get`	Discover or inspect projects
`create` / `update`	Stand up or rename projects
`delete` / `delete_preview`	Delete a project, or preview blast radius first

🌍 `environment` — environment CRUD

Action	Purpose
`list` / `get`	List or inspect environments inside a project
`create`	Add a new environment to a project
`delete` / `delete_preview`	Remove an environment, or preview dependents first

📚 `docs` — offline guides

Action	Purpose
`search`	Search a bundled, curated Coolify troubleshooting index — not a live web fetch, so it works offline and can't be used as an external fetch vector

🚨 `emergency` — high-impact ops (gated)

Reach for these only when you mean it — every action below is behind a confirmation gate.

Action	Purpose
`stop_all`	Stop every running application, fleet-wide — requires `confirm: true`
`redeploy_project`	Redeploy every app in a project — requires `confirm: true`
`restart_project`	Restart every app in a project — requires `confirm: true`

🗂️ `instance` — multi-instance registry

Manage named Coolify instances in ~/.coolify-mcp/instances.json. Per-call credential resolution — no cross-instance leakage.

Action	Purpose
`list`	List registered instances (tokens masked)
`get`	Fetch one instance by name
`add`	Register a new instance (`name`, `url`, `token`, optional `type: "cloud"`)
`update`	Rotate URL or token for an existing instance
`delete`	Remove an instance — requires `confirm: true`
`set-default`	Set the default instance for ops without an explicit `instance` param
`import-env`	Opt-in: copy `COOLIFY_URL` + `COOLIFY_TOKEN` from process env into the registry
`cloud-info`	Local Cloud discovery — `isCloud`, `url`, `source`, `knownLimits`, docs link (no API call)

instance({ action: "add", name: "prod", url: "https://coolify.example.com", token: "<token>" })
instance({ action: "list" })
instance({ action: "cloud-info" })

📜 `manifest` — local cache

Read/write/sync .coolify/manifest.json — a workspace cache, not source of truth. Remote wins on UUID conflict.

Action	Purpose
`get`	Read the local manifest file
`upsert`	Merge projects/servers/resources into the cache
`set`	Replace a manifest section
`remove`	Remove a cached resource entry
`clear`	Wipe the manifest — requires `confirm: true`
`sync`	Reconcile cache against live Coolify API (optional `dry_run`, `prune` with `confirm`)
`diff`	Non-destructive diff report — always safe to run
`audit`	Read-only / advisory drift audit: severity-tagged `findings[]` with structured remediation hints (which tool/action to call next); optional `diff_support` detail — never mutates manifest or live state

manifest({ action: "sync", dry_run: true })
manifest({ action: "diff" })
manifest({ action: "audit" })

NOTE

manifest.audit compares local .coolify/manifest.json vs live Coolify inventory for the scoped instance. Findings name follow-up actions such as manifest.sync or manifest.upsert — hints are advisory only; nothing auto-heals. Keep using manifest.diff for the raw structural reconciliation report. Best-effort auto-hooks update the manifest after app/service/DB mutations. Stale UUID 404s elsewhere surface _meta.manifestWarning — run manifest({ action: "sync" }) to reconcile.

🧭 `setup` — guided project wiring

Action	Purpose
`preflight`	Check GitHub CLI and workspace prerequisites without changing the project
`wire`	Link an existing workload or provision a greenfield project, with optional domains, env sync, recipe, manifest, and deploy watch steps
`resume`	Continue a paused setup after authentication or another recoverable prerequisite

wire never auto-pushes. The setup flow pauses cleanly when gh authentication is missing and resumes from completed steps.

🎨 Branding (`serverInfo.icons`)

The MCP server advertises icons in initialize via an embedded PNG data URI (primary) and jsDelivr CDN URLs for mcp-icon-192.png and favicon-32.png. Cursor may still show a letter fallback — see maintainer verify record. Not a Coolify API call.

🛡️ Safety model

Confirmation gate

Destructive emergency actions follow a strict two-step pattern:

Call with confirm omitted or false → you get back a would_affect preview and error code COOLIFY_CONFIRM_REQUIRED — nothing is mutated.
Call again with confirm: true → the action actually executes.

Regular app/service/database mutations (start, stop, deploy, …) are not behind this gate — they simply follow Coolify's own API semantics, since they're scoped to one resource rather than your whole fleet.

Environment variables: envs:delete and envs:bulk-update require confirm: true on application, service, and database. envs:sync apply (dry_run: false) and envs:sync with prune: true require confirm: true on application only. dry_run: true sync previews never mutate. envs:promote apply (dry_run: false) requires confirm: true on application; default conflict_policy is keep_remote.

Drift & heal (read-only audit, preview-first promote): manifest.audit is advisory-only — it never writes manifest or live state. application.envs:promote (product name env.promote) previews by default; values stay masked unless reveal: true. Both stay within one Coolify instance per call.

Deploy guard (advisory preflight, confirm-gated rollback): deployment.preflight is read-only and returns a risk_score with four named factors — no external DNS/HTTP probes. deployment.rollback requires confirm: true before mutating; git rollbacks PATCH the target commit then POST /deploy (MCP composite, not a Coolify rollback API).

Secret masking

Keys matching password, token, secret, private, or env render as *** by default in tool output.
Pass reveal: true only when you explicitly need plaintext — for example, to copy an env var into another system. Ask the human first before setting reveal: true on any envs:* call.
Log line bodies are not masked. Treat raw logs like you would any other sensitive output: don't paste them into long-lived agent memory or public tickets.

WARNING

Registry files (~/.coolify-mcp/instances.json) are written with 0o700 directory and 0o600 file permissions. Tokens are never echoed in tool output unless you explicitly pass reveal: true.

⚠️ Structured errors & retries

Every API failure comes back as a parseable envelope your agent can reason about, instead of a raw stack trace:

{
  "code": "COOLIFY_401",
  "message": "Unauthorized — invalid or expired API token",
  "recoveryHints": [
    "Verify the token in Coolify UI → Keys & Tokens",
    "Ensure the token has the required team permissions"
  ],
  "httpStatus": 401
}

Code	Meaning
`COOLIFY_401`	Invalid or missing token
`COOLIFY_404`	Resource not found
`COOLIFY_422`	Validation error
`COOLIFY_500`	Coolify server error
`COOLIFY_NETWORK`	Connection failed
`COOLIFY_TIMEOUT`	Request timed out
`COOLIFY_CONFIRM_REQUIRED`	Emergency preview — pass `confirm: true` to proceed
`COOLIFY_AMBIGUOUS_MATCH`	Name matched multiple resources — pick a UUID from the ranked list
`COOLIFY_CLOUD_FORBIDDEN`	Cloud token or team permission issue (HTTP 403)
`COOLIFY_CLOUD_UNSUPPORTED`	Endpoint not available on Coolify Cloud (HTTP 404)

Transient failures (HTTP 429, 5xx, or network errors) retry automatically up to 3 times with exponential backoff (1s → 2s → 4s) before giving up and returning the error to your agent.

💬 Example agent workflows

"Is my Coolify reachable, and what do I have?"

system({ action: "verify" })
system({ action: "infrastructure_overview" })
resource({ action: "list" })

"Find the nginx app, deploy it, then show me the logs."

resource({ action: "find", query: "nginx" })
application({ action: "deploy", uuid: "<uuid>", wait: false })
deployment({ action: "watch", deployment_uuid: "<deployment_uuid>", timeout: 300 })
application({ action: "logs", uuid: "<uuid>" })

"Something feels wrong across the fleet."

diagnose({ action: "scan" })
diagnose({ action: "app", uuid: "<suspect>" })
diagnose({ action: "server", uuid: "<server>" })

"Emergency: stop everything, but let me see the blast radius first."

emergency({ action: "stop_all" })                 // preview — would_affect, no mutation
emergency({ action: "stop_all", confirm: true })  // execute

"Multi-instance: list registered instances and verify each."

instance({ action: "list" })
system({ action: "verify" })

✅ Status today

Package 1.1.4 ships 19 tools and six MCP prompts for Coolify API 4.1.x:

Capability	Status
Verify connectivity + infrastructure overview	✅ Shipped
Discovery: `resource.list` / `resource.find`	✅ Shipped
Diagnose: app, server, fleet-wide scan + follow-up hints	✅ Shipped
Log Brain (`diagnose.analyze`) + playbooks (`incident`, `rollback`, `maintenance-window`)	✅ Shipped
Deploy lifecycle: start/stop/restart, deploy with wait-mode + force rebuild	✅ Shipped
Deployment tracking: list / get / cancel	✅ Shipped
Deployment watch and bounded build logs	✅ Shipped
Application runtime logs, bounded follow, and `diagnose.logs`	✅ Shipped
Instance intelligence (`intelligence.scorecard`, `graph`, `impact`, `janitor`, `cleanup`)	✅ Shipped
Drift & heal (`manifest.audit`, `application.envs:promote` / env.promote)	✅ Shipped
Deploy guard (`deployment.preflight`, `deployment.rollback`)	✅ Shipped
Application, service, and database CRUD	✅ Shipped
Dynamic one-click type discovery, recipes, and `recipe.recommend`	✅ Shipped
Setup wizard and four IDE workflow skills	✅ Shipped
Emergency ops: stop-all, project redeploy/restart, behind confirm gate	✅ Shipped
SSH key CRUD (`private_key`) with PEM masking	✅ Shipped
Server CRUD + validation (`server`)	✅ Shipped
Project & environment CRUD (`project`, `environment`)	✅ Shipped
Secret masking with explicit `reveal` opt-in	✅ Shipped
Structured errors, recovery hints, automatic retries	✅ Shipped
npm distribution + install configurator for 15+ clients	✅ Shipped
Multi-instance registry (`instance`, `instances.json`)	✅ Shipped
Coolify Cloud path (`cloud-info`, team-scoped tokens)	✅ Shipped
Local manifest sync (`.coolify/manifest.json`, auto-hooks)	✅ Shipped
Live UAT harness (`npm run uat:live`)	✅ Shipped
Capability discovery via `system.version`	✅ Shipped
Deployment build logs via `deployment.logs`	✅ Shipped

Capability discovery & build logs: system({ action: "version" }) returns coolifyVersion (replacing the legacy version field), mcpVersion, and a capabilities map of Coolify 4.1.2 feature flags. For app triage + bounded runtime tail in one call, use diagnose({ action: "logs", mode: "full", uuid: "..." }) — check capabilities.diagnose_logs. For Log Brain pattern triage, use diagnose({ action: "analyze", uuid: "..." }) — check capabilities.diagnose_analyze. For advisory stack picks from the live catalog, use recipe({ action: "recommend", stack: "..." }) — check capabilities.recipe_recommend. For instance health, dependency graph, impact, and janitor/cleanup, use intelligence({ action: "scorecard" | "graph" | "impact" | "janitor" | "cleanup", ... }) — check capabilities.intelligence_scorecard (and sibling intelligence_* keys); cleanup requires confirm: true. For manifest drift audit and cross-app env promote, use manifest({ action: "audit" }) and application({ action: "envs:promote", source_uuid, target_uuid, ... }) — check capabilities.manifest_audit and capabilities.envs_promote (MCP composites over existing reads/env CRUD, not Coolify-native REST endpoints). For deployment build logs, prefer deployment({ action: "logs", deployment_uuid: "..." }) (or application_uuid to resolve the newest deployment). The application.logs path with deployment_uuid still works for back-compat. For runtime log follow, use application({ action: "logs", uuid: "...", follow: true }) — bounded MCP polling until idle or timeout; check capabilities.application_logs_follow via system.version.

WARNING

Coolify 4.1.x does not expose stable service or database log endpoints. This server therefore does not claim or register service/database log actions. Use application runtime logs and deployment build logs until compatible upstream APIs are available.

🔮 Coming soon

Future work stays bounded by verifiable upstream and repository constraints:

Add service/database logs when compatible Coolify APIs are stable and available.
Close tracked REST mappings in docs/COVERAGE.md where they add useful agent workflows.
Revisit cross-instance fan-out only with explicit rate-limit and credential-isolation guarantees.

No release date or compatibility promise is attached to these boundaries. Use GitHub Issues for concrete requests.

🛠️ Local development

git clone https://github.com/clezcoding/awesome-coolify.git
cd awesome-coolify
pnpm install
pnpm run build    # tsup → dist/
pnpm test         # vitest
pnpm run dev      # watch mode

Logs go to stderr only — stdout is reserved exclusively for the MCP protocol.

The maintainer publish flow (build → pack --dry-run → publish) is documented in CONTRIBUTING.md.

NOTE

Maintainers can run live UAT against a real Coolify instance withnpm run uat:live. See CONTRIBUTING.md — Live UAT Harness for prerequisites and report output — do not duplicate the runbook here.

🔗 Links

Resource	URL
Install configurator	clezcoding.github.io/awesome-coolify/install.html
Install landing page	clezcoding.github.io/awesome-coolify/
Example MCP JSON	docs/mcp.example.json
Brand assets	docs/assets/
Coolify	coolify.io
MCP specification	modelcontextprotocol.io
Issues & feature requests	GitHub Issues
Contributing	CONTRIBUTING.md
Changelog	CHANGELOG.md
Security policy	SECURITY.md
License	MIT

Available Tools

19 tools

applicationA

Application lifecycle, deploy, log, and environment-variable actions — list via resource tool. Actions: get(uuid, format?, projection?, reveal?) · start(uuid) · stop(uuid) · restart(uuid) · deploy(uuid, force?) · logs(uuid, lines?, follow?, timeout?, idle_timeout?, min_interval?, max_interval?) — follow runtime only; check system.version capabilities.application_logs_follow · create(source_type, server_uuid) · update(uuid) · delete(uuid, confirm) · delete_preview(uuid) · envs:list(uuid) · envs:get(uuid, key) · envs:create(uuid, key, value) · envs:update(uuid, key, value) · envs:delete(uuid, env_uuid, confirm) · envs:bulk-update(uuid, entries, confirm) · envs:sync(uuid, env_file?, env_content?, dry_run?, confirm?, conflict_policy?) · envs:promote(source_uuid, target_uuid, dry_run?, confirm?, conflict_policy?, reveal?) Safety: confirm for destructive ops · optional instance · reveal opt-in only

ParametersJSON Schema

Name	Required	Description
`key`	No	Environment variable key
`tag`	No	Single tag batch expand
`fqdn`	No	Application FQDN substring
`name`	No	Application name substring
`page`	No	Page number for pagination
`tags`	No	Batch deploy tags
`type`	No	Filter build-logs entries by type (default all — no filter). Applies only to the deployment_uuid (build-logs) path; ignored on runtime logs path.
`uuid`	No	Application UUID
`wait`	No	Poll until terminal or timeout
`force`	No	Force rebuild without cache
`lines`	No	Number of log lines to retrieve
`prune`	No	Delete remote env keys absent from local
`uuids`	No	Batch deploy UUIDs
`value`	No	Environment variable value
`action`	Yes	The action to run
`follow`	No	Poll runtime logs until idle or timeout (runtime identity only)
`format`	No	Output format (default pretty)
`is_spa`	No
`offset`	No	Skip first K log lines
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`confirm`	No	Explicit confirmation for destructive ops
`domains`	No	Comma-separated domain list
`dry_run`	No	Preview diff only
`entries`	No
`timeout`	No	Wait-mode timeout in seconds (deploy wait min 10; follow logs min 1)
`env_file`	No	Local filesystem path to a .env file
`env_uuid`	No	Environment variable UUID
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`per_page`	No	Items per page
`redirect`	No
`is_static`	No
`max_chars`	No	Max formatted output characters (default 16000)
`build_pack`	No	Build pack
`dockerfile`	No	Dockerfile content
`git_branch`	No	Git branch
`is_literal`	No
`is_preview`	No
`projection`	No	Detail projection depth
`description`	No	Application description
`env_content`	No	Inline .env file content
`server_uuid`	No	Server UUID (required for create)
`source_type`	No	Application source type for create
`source_uuid`	No	Source application UUID for envs:promote
`target_uuid`	No	Target application UUID for envs:promote
`watch_paths`	No
`idle_timeout`	No	Follow idle stop in seconds (default 60 when follow:true)
`include_full`	No	Alias for projection: full
`is_multiline`	No
`max_interval`	No	Follow max poll interval in seconds (default 30 when follow:true)
`min_interval`	No	Follow min poll interval in seconds (default 3 when follow:true)
`project_name`	No	Project name for lookup
`project_uuid`	No	Project UUID
`build_command`	No
`custom_labels`	No
`is_shown_once`	No
`ports_exposes`	No	Ports to expose
`start_command`	No
`base_directory`	No
`delete_volumes`	No
`docker_cleanup`	No
`git_commit_sha`	No	Git commit SHA
`git_repository`	No	Git repository URL
`include_hidden`	No	Include entries with hidden:true in build-logs output (default false — hidden entries are filtered out)
`instant_deploy`	No	Queue deploy immediately after create
`ports_mappings`	No	Port mappings
`conflict_policy`	No	How to resolve value conflicts on apply
`deployment_uuid`	No	Deployment UUID for build logs
`github_app_uuid`	No	GitHub app UUID
`install_command`	No
`environment_name`	No	Environment name
`environment_uuid`	No	Environment UUID
`private_key_uuid`	No	Private deploy key UUID
`use_build_server`	No
`health_check_host`	No
`health_check_path`	No
`health_check_port`	No
`publish_directory`	No
`health_check_method`	No
`health_check_scheme`	No
`health_check_enabled`	No
`health_check_retries`	No
`health_check_timeout`	No
`delete_configurations`	No
`force_domain_override`	No	Override domain conflict
`health_check_interval`	No
`is_auto_deploy_enabled`	No
`is_force_https_enabled`	No
`health_check_return_code`	No
`http_basic_auth_password`	No
`http_basic_auth_username`	No
`connect_to_docker_network`	No
`custom_docker_run_options`	No
`delete_connected_networks`	No
`docker_registry_image_tag`	No	Docker registry image tag
`health_check_start_period`	No
`docker_registry_image_name`	No	Docker registry image name
`health_check_response_text`	No
`is_http_basic_auth_enabled`	No
`is_preserve_repository_enabled`	No
`is_container_label_escape_enabled`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds meaningful behavioral details beyond the sparse openWorldHint annotation: destructive operations require explicit confirmation, instance is optional, and reveal is opt-in only for sensitive values. It also flags the runtime-only follow capability check, giving the agent useful safety context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but efficiently structured: a one-line scope statement, a compact action list with signatures, and a safety note. Every sentence adds actionable information, and the format is easy to scan for action selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 100-parameter tool with many actions, the description provides a strong overview, action signatures, safety rules, and a capability check. It falls short of full completeness by not mentioning the build-logs path via deployment_uuid or elaborating on open-world side effects, but the output schema and sibling context fill some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100 parameters and only 59% schema coverage, the description compensates by listing per-action signatures (e.g., get(uuid, format?, projection?, reveal?)) and required fields like server_uuid for create and confirm for destructive ops. However, the logs signature omits build-logs parameters such as deployment_uuid, type, and include_hidden, leaving a minor gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly names the resource domain ('Application lifecycle, deploy, log, and environment-variable actions') and enumerates every supported action with its signature. It also distinguishes itself from the sibling resource tool by saying 'list via resource tool,' making the scope clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides concrete guidance for when to use certain actions, such as 'list via resource tool' and 'follow runtime only; check system.version capabilities.application_logs_follow.' It does not comprehensively contrast with all sibling tools like deployment or environment, but the key alternatives and conditional requirements are present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

databaseA

Database CRUD, lifecycle, env vars, and backup-schedule actions — list via resource tool. Actions: get(uuid?, name?) · start(uuid?) · stop(uuid?) · restart(uuid?) · create(engine, server_uuid) · update(uuid?) · delete(uuid?, confirm) · delete_preview(uuid?, name?) · envs:list(uuid?) · envs:get(uuid?, env_uuid?, key?) · envs:create(uuid?, key, value) · envs:update(uuid?, env_uuid?, key?, value) · envs:delete(uuid?, env_uuid, confirm) · envs:bulk-update(uuid?, entries, confirm) · backup:create(uuid?, frequency) · backup:list(uuid?) · backup:history(uuid?, scheduled_backup_uuid) · backup:update(uuid?, scheduled_backup_uuid) · backup:delete(uuid?, scheduled_backup_uuid, confirm) · backup:now(uuid?, scheduled_backup_uuid) Safety: confirm for destructive ops · optional instance · reveal opt-in only

ParametersJSON Schema

Name	Required	Description
`key`	No	Environment variable key
`name`	No	Database name substring
`page`	No	Page number for pagination
`uuid`	No	Database UUID
`image`	No	Custom database image
`value`	No	Environment variable value
`action`	Yes	The action to run
`engine`	No	Database engine (required for create)
`format`	No	Output format (default pretty)
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`confirm`	No	Confirm destructive or public exposure ops
`enabled`	No	Enable schedule
`entries`	No
`save_s3`	No	Upload backups to S3
`timeout`	No	Backup timeout in seconds
`dump_all`	No
`env_uuid`	No	Environment variable UUID
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`per_page`	No	Items per page
`delete_s3`	No	Also delete S3 backup artifacts
`frequency`	No	Backup frequency preset or cron expression
`is_public`	No	Expose database port publicly
`max_chars`	No	Max formatted output characters (default 16000)
`backup_now`	No
`is_literal`	No
`mysql_user`	No
`projection`	No	Detail projection depth
`description`	No	Database description
`limits_cpus`	No
`postgres_db`	No
`public_port`	No	Public port when is_public
`server_uuid`	No	Target server UUID
`include_full`	No	Alias for projection: full
`is_multiline`	No
`mariadb_user`	No
`project_name`	No	Project name
`project_uuid`	No	Project UUID
`is_shown_once`	No
`limits_cpuset`	No
`limits_memory`	No
`postgres_conf`	No
`postgres_user`	No
`delete_volumes`	No
`docker_cleanup`	No
`instant_deploy`	No	Start database after create
`keydb_password`	No
`mysql_database`	No
`mysql_password`	No
`redis_password`	No
`s3_storage_uuid`	No	S3 storage destination UUID
`destination_uuid`	No
`environment_name`	No	Environment name
`environment_uuid`	No	Environment UUID
`mariadb_database`	No
`mariadb_password`	No
`limits_cpu_shares`	No
`postgres_password`	No
`dragonfly_password`	No
`limits_memory_swap`	No
`databases_to_backup`	No
`mysql_root_password`	No
`public_port_timeout`	No	Public port mapping timeout
`postgres_initdb_args`	No
`clickhouse_admin_user`	No
`delete_configurations`	No
`mariadb_root_password`	No
`mongo_initdb_database`	No
`scheduled_backup_uuid`	No	Backup schedule UUID
`limits_memory_swappiness`	No
`clickhouse_admin_password`	No
`delete_connected_networks`	No
`limits_memory_reservation`	No
`postgres_host_auth_method`	No
`mongo_initdb_root_password`	No
`database_backup_retention_days_s3`	No
`database_backup_retention_amount_s3`	No
`database_backup_retention_days_locally`	No
`database_backup_retention_amount_locally`	No
`database_backup_retention_max_storage_s3`	No
`database_backup_retention_max_storage_locally`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses behavioral traits such as safety confirmations for destructive ops, optional instance parameter, and reveal opt-in. While annotations only include openWorldHint, the description adds useful context beyond that. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with a compact list of actions and safety notes. However, it is lengthy due to the many actions listed. It could be more concise by grouping or summarizing less common actions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (80 parameters, numerous actions) and the presence of an output schema, the description is incomplete. It does not explain return values, common parameter combinations, or prerequisites beyond basic safety.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 43%, and the description adds little meaning beyond listing actions with parenthesized parameters (e.g., 'get(uuid?, name?)'). Many of the 80 parameters are not explained in the description, leaving gaps for the agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Database CRUD, lifecycle, env vars, and backup-schedule actions'. It lists specific actions and distinguishes from sibling tools by noting 'list via resource tool'. The scope is well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides guidance on when to use this tool versus others (e.g., 'list via resource tool'). It also includes safety notes for destructive ops. However, it does not explicitly differentiate from other sibling tools like 'application' or 'service'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

deploymentA

List per-app deployments, get deployment details, or cancel an in-flight deployment. Actions: list(application_uuid, format?, page?, per_page?) · get(deployment_uuid, format?, projection?, reveal?) · cancel(deployment_uuid, format?, max_chars?) · watch(deployment_uuid, timeout?, min_interval?, max_interval?, include_logs?, format?, max_chars?, instance?) · logs(deployment_uuid|application_uuid, lines?, offset?, include_hidden?, type?, format?, max_chars?, instance?) · preflight(uuid|name|fqdn, format?, max_chars?, instance?) · rollback(uuid|name|fqdn, confirm?, force?, wait?, timeout?, format?, max_chars?, instance?) Safety: confirm for destructive ops · preflight is advisory read-only · rollback requires confirm:true · optional instance · reveal opt-in only

ParametersJSON Schema

Name	Required	Description
`fqdn`	No	Application FQDN for preflight/rollback
`name`	No	Application name for preflight/rollback
`page`	No	Page number for pagination
`type`	No	Filter build-logs entries by type (default all — no filter). Applies only to the deployment_uuid (build-logs) path; ignored on runtime logs path.
`uuid`	No	Application UUID for preflight/rollback
`wait`	No	Poll rollback deployment until terminal (rollback)
`force`	No	Force deploy on rollback (default false)
`lines`	No	Number of log lines to retrieve
`action`	Yes	The action to run
`format`	No	Output format style
`offset`	No	Skip first K lines of the FLATTENED log blob before applying lines (build-logs pagination applied AFTER parse+filter+flatten)
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`confirm`	No	Required true for rollback mutations
`timeout`	No	Watch timeout in seconds (default 300)
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`per_page`	No	Items per page
`max_chars`	No	Maximum characters in text response before truncation
`projection`	No	Detail projection depth
`include_full`	No	Alias for projection: full
`include_logs`	No	Attach capped build logs on success (default false)
`max_interval`	No	Maximum poll interval in seconds (default 30)
`min_interval`	No	Minimum poll interval in seconds (default 3)
`include_hidden`	No	Include entries with hidden:true in build-logs output (default false — hidden entries are filtered out)
`deployment_uuid`	No	Deployment UUID
`application_uuid`	No	Application UUID to list deployments for

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Given annotations only include openWorldHint, the description carries the burden of behavioral disclosure. It openly states that cancel and rollback are destructive ('confirm for destructive ops', 'rollback requires confirm:true'), preflight is read-only, and reveal is opt-in. This goes beyond annotations and adds meaningful safety context, though it does not detail watch or logs behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and efficient: an overview sentence, a compact action list with parameter signatures, and a safety note. Every line carries distinct information with no redundancy, making it easy to parse despite the breadth of actions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 25 parameters, an output schema, and 7 actions, the description provides a comprehensive overview, action signatures, and safety caveats. It does not delve into when to prefer one action over another (e.g., watch vs. logs), but the schema and output schema fill many gaps. Overall, it is sufficiently complete for an agent to select and invoke actions correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100% (baseline 3), the description adds value by grouping parameters into action signatures and clarifying alternative inputs (e.g., 'deployment_uuid|application_uuid' for logs, 'uuid|name|fqdn' for preflight/rollback). The safety notes also clarify semantic constraints (confirm required, reveal opt-in), enriching beyond the schema's descriptive text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'List per-app deployments, get deployment details, or cancel an in-flight deployment,' which clearly identifies the tool as deployment management. The subsequent 'Actions:' list enumerates all seven operations, distinguishing it from sibling tools like 'application' or 'service' by explicitly focusing on deployment lifecycle.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides contextual usage guidance through the 'Safety:' note, indicating that confirm is required for destructive operations, preflight is advisory read-only, and rollback requires confirm:true. It lacks explicit 'when not to use' or alternative tool references, but the action names and parameter lists imply appropriate scenarios, giving clear context without exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

diagnoseA

Synthesizes diagnose views for applications and servers, or runs a global fleet scan. Actions: app(query?, uuid?, name?, domain?, limit?) · server(query?, uuid?, name?, ip?, trigger_validate?) · scan(format?, page?, per_page?) · logs(query?, uuid?, name?, domain?, mode?, deployment_uuid?, lines?, offset?, include_hidden?, type?, format?, max_chars?, instance?) · analyze(query?, uuid?, name?, domain?, deployment_uuid?, lines?, offset?, max_chars?, instance?) — pattern triage on runtime logs (advisory) Safety: confirm for destructive ops · analyze is advisory-only (no restart/redeploy/rollback) · optional instance · reveal opt-in only

ParametersJSON Schema

Name	Required	Description	Default
`ip`	No	Explicit server IP substring
`mode`	No	full = diagnose triage + logs (default); logs-only = skip diagnose	full
`name`	No	Explicit name substring
`page`	No	Page number for pagination
`type`	No	Filter build-logs entries by type (default all — no filter). Applies only to the deployment_uuid (build-logs) path; ignored on runtime logs path.
`uuid`	No	Explicit resource UUID
`limit`	No	Max recent deployments to include (default 10, max 50)
`lines`	No	Number of log lines to retrieve
`query`	No	Fuzzy query string (UUID, name, or FQDN/IP)
`action`	Yes	The action to run
`domain`	No	Explicit application FQDN substring
`format`	No	Output format style
`offset`	No	Skip first K lines of the log blob before applying lines (runtime or build)
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`per_page`	No	Items per page
`max_chars`	No	Maximum characters in response before truncation
`projection`	No	Detail projection depth
`include_full`	No	Alias for projection: full
`include_hidden`	No	Include entries with hidden:true in build-logs output (default false — hidden entries are filtered out)
`deployment_uuid`	No	Fetch build logs for this deployment only (XOR with runtime identifiers)
`trigger_validate`	No	Triggers non-blocking server verification (D-10)

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite sparse annotations (only openWorldHint), the description voluntarily discloses important behavioral traits: analyze is advisory-only, reveal is opt-in only, and confirm is needed for destructive ops. This goes beyond the schema and annotations, though it could still elaborate on which specific actions are destructive or how confirmation is triggered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and structured: first a one-line purpose, then a dense action list with parameter signatures, then a safety section. Every sentence conveys necessary information without fluff, and the line breaks make it scannable for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (22 parameters, 5 actions) and the existence of an output schema, the description covers the purpose, action breakdown, and safety constraints sufficiently. It does not explain return values (unnecessary due to output schema) but adequately orients the agent on the tool's scope and boundaries.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage for all 22 parameters, so the schema already documents each parameter well. The description's action list repeats parameter names but adds only marginal semantics (e.g., 'pattern triage on runtime logs' for analyze). This meets the baseline for schema-covered parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool synthesizes diagnose views for applications and servers or runs a global fleet scan, then enumerates five distinct actions (app, server, scan, logs, analyze) with their parameter signatures. This provides a specific verb+resource mapping for each action, fully distinguishing it from sibling tools like resource or server.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear intra-tool guidance: analyze is explicitly advisory-only with no restart/redeploy/rollback, and safety notes confirm for destructive ops. However, it does not explicitly compare to sibling tools (e.g., when to use diagnose vs resource or system), so it lacks alternative exclusions but still provides actionable context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

docsA

Read-only

Search static Coolify documentation guides. Actions: search(query, format?, max_chars?) Safety: reveal opt-in only

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number for pagination
`query`	Yes	Documentation search query
`action`	Yes	The action to run
`format`	No	Output format style
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`per_page`	No	Items per page
`max_chars`	No	Maximum characters in text response before truncation
`projection`	No	Detail projection depth
`include_full`	No	Alias for projection: full

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=true; description enhances with 'Safety: reveal opt-in only', indicating sensitive values are masked unless reveal is set. 'Static' also clarifies the data source. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely compact: two sentences, front-loaded with the primary action. Each clause carries meaning—purpose, signature, and safety caveat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with a full output schema and 100% schema parameter coverage, the description covers the core behavior and safety. It does not mention pagination or projection, but schema covers these; the main gap is the misleading signature omitting the required action parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema documents all 9 parameters. The description's signature is minimal and omits action, pagination, and projection params, adding no new semantics beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly identifies the tool as searching static Coolify documentation guides, with a specific verb ('search') and resource ('documentation guides'). This distinguishes it from sibling operational tools like deployment, server, and database.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the tool is for searching static documentation, placing it in clear context relative to operational siblings. However, it does not explicitly mention alternatives or when not to use it, so no exclusions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

emergencyA

Emergency and bulk operations (stop_all, redeploy_project, restart_project). Actions: stop_all(confirm) · redeploy_project(project_uuid?, project_name?, confirm, force?, wait?) · restart_project(project_uuid?, project_name?, confirm) Safety: confirm for destructive ops · optional instance

ParametersJSON Schema

Name	Required	Description
`wait`	No	Poll each deployment to terminal — ask the human before enabling
`force`	No	Force rebuild without cache (mirror P4 application.deploy)
`action`	Yes	The action to run
`format`	No	Output format (default pretty)
`confirm`	No	Explicit confirmation required
`timeout`	No	Per-app wait timeout in seconds
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`max_chars`	No	Max formatted output characters (default 16000)
`project_name`	No	Project name substring (case-insensitive contains-match)
`project_uuid`	No	Project UUID

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that operations are destructive and require confirmation ('Safety: confirm for destructive ops'), which adds behavioral context beyond the openWorldHint annotation. However, it does not detail potential side effects, the return format, or what happens on failure, leaving gaps given the open-world hint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: a single introductory sentence followed by a compact list of action signatures and a safety note. Every part serves a purpose, and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters (all described in schema) and an output schema existing, the description covers the main actions and safety. However, it omits explanatory context about the grouping rationale or cross-tool relationships, which would help an agent decide when to invoke this tool over siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description doesn't need to compensate heavily. However, it adds value by showing the action signatures (e.g., 'stop_all(confirm)') and indicating which parameters are relevant per action, clarifying usage beyond the schema's general descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly lists the three actions (stop_all, redeploy_project, restart_project) and states 'Emergency and bulk operations', providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'deployment' or 'application', which could also handle similar actions individually.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'Emergency and bulk operations' but offers no guidance on when to use this tool versus its siblings. It doesn't mention prerequisites, exclusions, or suggest alternatives for non-emergency or single-item operations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

environmentA

Environment CRUD scoped to a parent project — no update action. Actions: list(project_uuid?, project_name?, format?, page?, per_page?) · get(project_uuid?, project_name?, uuid?, name?) · create(project_uuid?, project_name?, name) · delete(project_uuid?, project_name?, uuid?, name?, confirm) · delete_preview(project_uuid?, project_name?, uuid?, name?) Safety: confirm for destructive ops · optional instance · reveal opt-in only

ParametersJSON Schema

Name	Required	Description
`name`	No	Environment name (substring match)
`page`	No	Page number for pagination
`uuid`	No	Environment UUID
`action`	Yes	The action to run
`format`	No	Output format (default pretty)
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`confirm`	No	Explicit confirmation required for destructive delete
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`per_page`	No	Items per page
`max_chars`	No	Max formatted output characters (default 16000)
`projection`	No	Detail projection depth
`include_full`	No	Alias for projection: full
`project_name`	No	Parent project name (substring match)
`project_uuid`	No	Parent project UUID

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds meaningful safety context beyond the sparse openWorldHint annotation: it notes that delete requires explicit confirmation, that reveal is opt-in, and that instance is optional. It does not cover broader behaviors like auth or error handling, but the safety flags are relevant and actionable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured into scope, action list, and safety notes. Every sentence earns its place, and the use of a single-line signature per action keeps it scannable without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter, multi-action tool with an output schema, the description covers the action set, scope, required confirmations, and param action-specificity. It lacks examples or deeper return semantics, but the output schema and per-action signatures make the tool sufficiently complete for an agent to select and invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The action signatures in the description add per-action applicability and optionality that the flat schema doesn't convey, such as 'name' being required for create and optional query parameters for list/get/delete. Since schema descriptions cover 100% of parameters, the baseline is 3, but the action grouping adds meaningful selection semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as 'Environment CRUD scoped to a parent project', with an explicit note that there is no update action. It enumerates all five actions, making the tool's purpose and scope immediately distinct from siblings like project or deployment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: it's for environment operations scoped to a parent project and explicitly excludes the update action. It does not name alternative tools or provide direct when-not-to-use guidance beyond the no-update caveat, but the action list and scope define suitable usage well.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

instanceA

Multi-instance registry CRUD for ~/.coolify-mcp/instances.json. Actions: list(reveal?) · get(name, reveal?) · add(name, url, token, type) · update(name) · delete(name, confirm) · set-default(name) · import-env(name?) · cloud-info(instance?) Safety: confirm for destructive ops · reveal opt-in only

ParametersJSON Schema

Name	Required	Description
`url`	No
`name`	No	Instance name (lowercase, 2–32 chars)
`type`	No
`force`	No	Required when deleting the default or last remaining instance
`token`	No
`action`	Yes	The action to run
`reveal`	No	Reveal token values (default masked)
`confirm`	No	Explicit confirmation required for destructive delete
`instance`	No	Optional instance name to inspect; defaults to env/default resolution
`verifySsl`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose key safety behaviors: destructive ops require confirm, and reveal is opt-in (tokens masked by default). However, it does not mention how tokens are stored, whether operations are idempotent, or the consequences of delete beyond requiring confirm. The file path and action list add useful context, but the description remains somewhat thin for a tool with this many actions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise, starting with the resource and file path, then listing actions and safety constraints in a structured, scannable format. Every sentence adds value, and the length is appropriate for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 10 parameters, 8 actions, and an output schema, the description does a good job covering the essential actions and safety rules. It omits nuance around import-env and cloud-info but those are niche. The presence of an output schema means return values need not be described, so the description is adequately complete for the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is low at 60%, so the description compensates somewhat by mapping parameters to actions (e.g., list(reveal?), delete(name, confirm)). This clarifies which optional parameters apply to each action, which the schema alone does not convey. However, it does not explain the meaning of verifySsl or token beyond what the schema already provides, missing an opportunity to fully compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Multi-instance registry CRUD' and enumerates the exact actions, giving a specific verb+resource focus. It differentiates from sibling tools by pointing to a specific config file and instance management domain, but it does not explicitly contrast with alternatives like server or resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for managing instances but does not provide explicit guidance on when to choose this tool over alternatives. It mentions safety confirm and reveal opt-in, which are behavioral constraints rather than usage context. No examples of when this tool is preferred are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

intelligenceA

Instance health scorecard, dependency graph, impact analysis, and janitor cleanup. Actions: scorecard(format?, max_chars?, instance?) · graph(format?, max_chars?, instance?) · impact(uuid, type, intent?, max_depth?, instance?) · janitor(stopped_days?, format?, instance?) · cleanup(targets, confirm, delete_volumes?, delete_configurations?, instance?) Safety: cleanup requires confirm:true · delete_volumes/configurations default false · advisory impact only

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number for pagination
`type`	No	Resource type (impact)
`uuid`	No	Resource UUID (impact)
`action`	Yes	The action to run
`format`	No	Output format style
`intent`	No	Impact intent (advisory)
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`confirm`	No	Explicit confirm for cleanup mutations
`targets`	No	Cleanup target list (explicit UUIDs only)
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`per_page`	No	Items per page
`max_chars`	No	Maximum characters in text response before truncation
`max_depth`	No	Max transitive depth for impact (default 3)
`projection`	No	Detail projection depth
`include_full`	No	Alias for projection: full
`stopped_days`	No	Janitor long-exited threshold in days (default 7)
`delete_volumes`	No	Pass-through to domain delete (default false)
`delete_configurations`	No	Pass-through to domain delete (default false)

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With only openWorldHint as an annotation, the description carries the burden of safety disclosure. It does well by stating 'advisory impact only' and cleanup safeguards/defaults, which tells the agent that impact is non-mutating and destructive actions require explicit confirmation. It does not elaborate on open-world effects or output behavior, but the output schema partially covers returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a purpose line, action signatures, and a safety line. Every word contributes useful information, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 18-parameter, five-action tool, the description covers purpose, action signatures, and mutation safety well, and an output schema exists for returns. It falls short only by omitting mapping for pagination/projection parameters and lacking any guidance on choosing among sibling tools, but overall it is highly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value by grouping parameters per action (e.g., impact(uuid, type, intent?, max_depth?, instance?)) and noting defaults like 'delete_volumes/configurations default false', which the schema does not convey. However, some params (page, per_page, reveal, projection, include_full) are not mapped to any action in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly defines the tool as an 'Instance health scorecard, dependency graph, impact analysis, and janitor cleanup' and then enumerates five distinct actions with their signatures. This clearly differentiates it from sibling tools like instance or diagnose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides per-action signatures and safety rules (e.g., 'cleanup requires confirm:true · delete_volumes/configurations default false'), giving actionable invocation context. However, it does not explicitly state when to use this tool vs alternatives or provide when-not-to-use exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

manifestA

Local manifest cache CRUD and sync/diff for .coolify/manifest.json. Actions: get() · upsert(resource, project_uuid, environment_uuid) · set(manifest) · remove(uuid) · clear(confirm) · sync(dry_run?, confirm?, prune?) · diff() · audit() Safety: confirm for destructive ops · optional instance

ParametersJSON Schema

Name	Required	Description
`uuid`	No
`prune`	No
`action`	Yes	The action to run
`confirm`	No
`dry_run`	No
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`manifest`	No
`resource`	No
`project_name`	No
`project_uuid`	No
`environment_name`	No
`environment_uuid`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With only openWorldHint and no readOnly/destructive annotations, the description adds behavioral value by specifying the local file path, listing action signatures, and stating 'confirm for destructive ops' and 'optional instance'. It does not detail side effects of sync/prune or audit output, but it provides meaningful safety and scope context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences: the first states purpose and resource, the second lists action signatures and safety information. The content is front-loaded and scannable, with no redundant words or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-action CRUD/sync/diff tool with 12 parameters and a rich nested schema, the description provides the essential action-parameter matrix and safety caveat. Combined with the output schema, this covers most operational needs, though it does not explain the semantics of sync/diff/audit actions or clarify UUID-vs-name alternatives.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 17%, and the description compensates by mapping each action to its valid parameters, marking optional ones with '?' (e.g., sync(dry_run?, confirm?, prune?)). This adds clear meaning beyond the raw schema. However, it omits the name-based alternatives (project_name/environment_name) present in the schema, leaving minor ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Local manifest cache CRUD and sync/diff for .coolify/manifest.json', naming exactly the file/resource and the operation families. The action enumeration (get, upsert, set, remove, clear, sync, diff, audit) gives specific verbs and distinguishes this from sibling tools like resource or deployment by scoping it to the local manifest cache.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by targeting the local manifest cache, but it lacks explicit 'when to use' or 'when not to use' guidance relative to sibling tools. The action signatures and safety note provide context, but there is no direct statement like 'use this for cache-only operations' or 'use resource for remote operations'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

metaA

Read-only

MCP server metadata (version). Actions: version() Safety: read-only meta tool

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes	The action to run

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true. Description adds 'Safety: read-only meta tool', reinforcing the non-destructive nature but not adding additional behavioral context beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is brief (two lines) and front-loaded with purpose. Every sentence serves a purpose, though structure could be slightly improved (e.g., separate sections).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple metadata tool with output schema, description sufficiently covers purpose and safety. No major gaps given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers parameter 'action' with enum and description at 100% coverage. Description only reiterates 'version()' without adding new semantic meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'MCP server metadata (version)' and specifies action 'version()', making purpose clear. However, it does not differentiate from sibling tools like system or resource, which could also return metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage when version info is needed, but no explicit when-not or alternative tools. The simplicity makes this adequate but not exemplary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

private_keyA

Private key CRUD for SSH keys registered in Coolify. Actions: list(format?, page?, per_page?) · get(uuid, format?, projection?, reveal?) · create(name, private_key?, key_file?) · update(uuid) · delete(uuid, confirm) · delete_preview(uuid) Safety: confirm for destructive ops · optional instance · reveal opt-in only

ParametersJSON Schema

Name	Required	Description
`name`	No	Private key name
`page`	No	Page number for pagination
`uuid`	No	Private key UUID
`action`	Yes	The action to run
`format`	No	Output format (default pretty)
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`confirm`	No	Explicit confirmation required for destructive delete
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`key_file`	No	Local filesystem path to PEM file
`per_page`	No	Items per page
`max_chars`	No	Max formatted output characters (default 16000)
`projection`	No	Detail projection depth
`description`	No	Optional description
`private_key`	No	Inline PEM material
`include_full`	No	Alias for projection: full

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations include openWorldHint=true, indicating potential unknown side effects. The description mentions safety confirm for destructive ops, adding some context, but does not detail permissions, irreversible consequences, or other behavioral traits beyond CRUD.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: a one-line purpose, action signatures, and a safety line. All information is front-loaded and no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a 100% schema coverage, output schema present, and clear action signatures, the description is largely complete. Minor omission: no mention of response formats or errors, but these are covered by the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are fully documented in the schema. The description adds value by grouping parameters per action (e.g., list(format?, page?, per_page?)), showing required vs optional, but does not explain parameter details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a "Private key CRUD for SSH keys registered in Coolify." and explicitly lists each action with parameters, making the purpose very clear. It distinguishes itself from sibling tools which are high-level categories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides safety guidance for destructive operations (confirm) and reveals (reveal opt-in only). Implicitly guides when to use each action via the parameter signatures, but does not explicitly compare to alternatives or state when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

projectA

Project CRUD for Coolify organizational containers. Actions: list(format?, page?, per_page?) · get(uuid?, name?, format?, projection?, reveal?) · create(name, initial_environment?) · update(uuid?, name?) · delete(uuid?, name?, confirm) · delete_preview(uuid?, name?) Safety: confirm for destructive ops · optional instance · reveal opt-in only

ParametersJSON Schema

Name	Required	Description
`name`	No	Project name (substring match)
`page`	No	Page number for pagination
`uuid`	No	Project UUID
`action`	Yes	The action to run
`format`	No	Output format (default pretty)
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`confirm`	No	Explicit confirmation required for destructive delete
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`new_name`	No	New project name when resolving by name only
`per_page`	No	Items per page
`max_chars`	No	Max formatted output characters (default 16000)
`projection`	No	Detail projection depth
`description`	No	Optional project description
`include_full`	No	Alias for projection: full
`initial_environment`	No	Initial environment name (required — ask user for production vs custom per D-09/D-10)

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only include openWorldHint: true. The description adds behavioral context: safety notes for destructive operations ('confirm'), optional instance, and reveal opt-in. It also notes that initial_environment requires user input per D-09/D-10, which is non-obvious behavior not captured by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (3 lines) and well-structured: first line states purpose, second line action signatures, third line safety/behavior notes. Every sentence earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (15 parameters, 6 actions, output schema exists), the description covers all crucial aspects: action signatures, parameter semantics, safety, optional instance, reveal behavior, and output format options. It leaves no major gaps for an AI agent to understand usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. However, the description adds value by grouping parameters per action (e.g., 'create(name, initial_environment?)') and providing semantic guidance like 'ask user for production vs custom per D-09/D-10' for initial_environment, which goes beyond the schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Project CRUD for Coolify organizational containers' and enumerates specific actions (list, get, create, update, delete, delete_preview), making the tool's purpose distinct from siblings like 'system' or 'application'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lists actions and safety notes but does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied through action names and parameter hints (e.g., 'confirm for destructive ops'), but no direct comparison to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recipeB

Multi-resource orchestration recipes & dynamic provisioning. Actions: create-git-app(server_uuid, git_repository, git_branch, repo_path?, build_pack?) · create-app-db(server_uuid, app_name, db_name, db_engine, env_key?) · create-one-click(server_uuid, type, instant_deploy?) · recommend(stack, server_uuid?, project_uuid?, environment_name?) Safety: optional instance · reveal opt-in only

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number for pagination
`type`	No	One-click service type
`stack`	No	Free-text stack description for recommend (e.g. "Next.js + Postgres")
`action`	Yes	The action to run
`format`	No	Output format (default pretty)
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`db_name`	No	Database name
`env_key`	No	Env key to wire (default DATABASE_URL)
`app_name`	No	Application name
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`per_page`	No	Items per page
`db_engine`	No	Database engine
`max_chars`	No	Max formatted output characters (default 16000)
`repo_path`	No	Local filesystem path to repo
`build_pack`	No	Build pack override
`git_branch`	No	Git branch
`projection`	No	Detail projection depth
`server_uuid`	No	Target server UUID
`include_full`	No	Alias for projection: full
`project_name`	No	Project name for lookup
`project_uuid`	No	Project UUID
`git_repository`	No	Git repository URL
`instant_deploy`	No	Start immediately (default true)
`environment_name`	No	Environment name
`environment_uuid`	No	Environment UUID

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only provide openWorldHint=true, so the description carries the burden of disclosing side effects. It states 'Safety: optional instance · reveal opt-in only', but this largely duplicates schema descriptions (e.g., instance optional, reveal default false). It does not disclose that create actions provision real resources, require specific permissions, or are irreversible. No contradiction with annotations, but insufficient transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded with the purpose, and lists actions in a structured signature format. The safety line is brief and informative, though somewhat cryptic. No wasted sentences, but could be slightly clearer in the safety section.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 25 parameters, 4 actions, and an output schema, the description provides action signatures and a safety note, covering the core structure. However, it lacks usage selection guidance, behavioral details beyond the schema, and context on what 'recipes' entails. The output schema covers return values, but the description is not fully complete for a complex orchestration tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, giving a baseline of 3. The description adds significant value by mapping actions to their specific parameter groups (e.g., create-git-app(server_uuid, git_repository, git_branch, repo_path?, build_pack?)), which the schema does not provide since it lists all parameters flatly. This helps agents know which parameters apply to each action, exceeding the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as multi-resource orchestration with specific action names (create-git-app, create-app-db, create-one-click, recommend) and parameter signatures. It is distinct from sibling tools focused on single resources, though it does not explicitly name an alternative. The verb 'orchestration' and action list make the purpose concrete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives like application, database, or service. The 'multi-resource orchestration' phrase implies it is for combined workflows, but there are no exclusions, prerequisites, or comparisons. The action signatures show what can be done, but not when to choose this over sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resourceA

Read-only

Unified resource listing and cross-type discovery. Actions: list(type?, format?, page?, per_page?) · find(query?, uuid?, name?, domain?, ip?, format?, page?, per_page?) Safety: confirm for destructive ops · optional instance · reveal opt-in only

ParametersJSON Schema

Name	Required	Description
`ip`	No
`name`	No
`page`	No	Page number for pagination
`type`	No
`uuid`	No
`query`	No
`action`	Yes	The action to run
`domain`	No
`format`	No	Output format style
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`per_page`	No	Items per page
`max_chars`	No	Maximum characters in text response before truncation
`projection`	No	Detail projection depth
`include_full`	No	Alias for projection: full

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds safe behaviors like 'optional instance' and 'reveal opt-in only', but the note 'confirm for destructive ops' contradicts the readOnlyHint, creating confusion. The added value over annotations is limited.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with purpose in one sentence and action/safety notes in another. It is front-loaded and without fluff, though it could be slightly more organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (15 parameters, output schema exists), the description is brief. It lacks details on pagination behavior, parameter interactions, and result format. The output schema covers return values, but the description could provide more guidance for a 15-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description maps parameters to actions (e.g., list(type?, format?, page?, per_page?)), adding clarity beyond the schema. However, not all 15 parameters are explained (e.g., max_chars, include_full), and schema coverage is 60%, so the description partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Unified resource listing and cross-type discovery,' which sets it apart from sibling tools that focus on specific resource types (application, service, etc.). The actions 'list' and 'find' are enumerated, making the purpose explicit and distinctive.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing/finding across all resource types, but does not explicitly guide when to use this tool versus sibling tools for specific types. No exclusions or alternatives are mentioned, leaving the agent to infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

serverA

Server CRUD and validate — servers listed via resource tool with type=server. Actions: get(uuid, format?, projection?, reveal?) · create(name, ip, private_key_uuid) · update(uuid) · delete(uuid, confirm) · delete_preview(uuid) · validate(uuid, timeout?) Safety: confirm for destructive ops · optional instance · reveal opt-in only

ParametersJSON Schema

Name	Required	Description
`ip`	No	Server IP address or hostname
`name`	No	Server display name
`page`	No	Page number for pagination
`port`	No	SSH port (default 22)
`user`	No	SSH user (default root)
`uuid`	No	Server UUID
`action`	Yes	The action to run
`format`	No	Output format (default pretty)
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`confirm`	No	Explicit confirmation required for destructive delete
`timeout`	No	Validation poll timeout in seconds (default 30)
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`per_page`	No	Items per page
`validate`	No	Auto-run reachability validation after create (default true)
`max_chars`	No	Max formatted output characters (default 16000)
`projection`	No	Detail projection depth
`proxy_type`	No	Proxy type on the server
`description`	No	Updated description
`include_full`	No	Alias for projection: full
`delete_volumes`	No	Also delete attached volumes (default false)
`dynamic_timeout`	No	Dynamic timeout seconds
`is_build_server`	No	Mark as build server
`private_key_uuid`	No	Private key UUID for SSH auth
`concurrent_builds`	No	Concurrent build limit
`connection_timeout`	No	Connection timeout seconds
`deployment_queue_limit`	No	Deployment queue limit

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no readOnly/destructive annotations besides openWorldHint, the description adds useful safety context: 'confirm for destructive ops,' 'reveal opt-in only,' and optional instance selection. It discloses secret-masking defaults and the need for confirmation, which is valuable behavioral transparency, though it does not mention all side effects like volume deletion.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense, front-loaded sentences deliver purpose, action signatures, and safety notes with zero filler. Every phrase earns its place, and the structure is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 26-parameter tool with an output schema, the description covers the key decision points: action selection, safety, and high-level parameters. The action signatures and safety section are sufficient for initial invocation, though a few action-specific fields and the meaning of openWorldHint are not elaborated, leaving minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, but the description goes beyond it by grouping parameters per action (e.g., get(uuid, format?, projection?, reveal?), create(name, ip, private_key_uuid)). This action-to-parameter mapping adds significant semantic meaning not obvious from the flat schema, though some update fields remain unlisted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Server CRUD and validate,' naming the exact resource and operations. It uniquely identifies the tool's scope and explicitly distinguishes it from the resource tool for listing servers, resolving possible sibling ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly states that server listing is handled by the resource tool, not this tool, and enumerates the specific actions. It does not explicitly discuss when not to use the tool for adjacent operations, but the action list and the pointer to resource for listing provide solid selection guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

serviceA

Service CRUD, lifecycle, and environment-variable actions — list via resource tool. Actions: get(uuid, format?, projection?, reveal?) · list-types(format?, projection?) · create(server_uuid, type?, compose?) · update(uuid) · delete(uuid, confirm) · delete_preview(uuid) · start(uuid) · stop(uuid) · restart(uuid) · deploy(uuid) · envs:list(uuid) · envs:get(uuid, key) · envs:create(uuid, key, value) · envs:update(uuid, key, value) · envs:delete(uuid, env_uuid, confirm) · envs:bulk-update(uuid, entries, confirm) Safety: confirm for destructive ops · optional instance · reveal opt-in only

ParametersJSON Schema

Name	Required	Description
`key`	No	Environment variable key
`fqdn`	No	Application FQDN substring
`name`	No	Service name substring
`page`	No	Page number for pagination
`type`	No	One-click service type, e.g. actualbudget, calibre-web, gitea-with-mysql
`urls`	No	Optional domain URLs
`uuid`	No	Service UUID
`value`	No	Environment variable value
`action`	Yes	The action to run
`format`	No	Output format (default pretty)
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`compose`	No	Inline Docker Compose YAML
`confirm`	No	Explicit confirmation for destructive ops
`entries`	No	Bulk env entries (min 1, max 100 per call)
`env_uuid`	No	Environment variable UUID
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`per_page`	No	Items per page
`max_chars`	No	Max formatted output characters (default 16000)
`is_literal`	No	Literal flag
`is_preview`	No	Preview variable
`projection`	No	Detail projection depth
`description`	No	Service description
`pull_latest`	No	Pull latest Docker images before restart
`server_uuid`	No	Target server UUID
`compose_file`	No	Local path to a docker-compose.yml file (max 1 MiB)
`include_full`	No	Alias for projection: full
`is_multiline`	No	Multiline flag
`project_name`	No	Project name
`project_uuid`	No	Project UUID
`is_shown_once`	No	Show-once flag
`delete_volumes`	No	Also delete attached volumes
`docker_cleanup`	No	Run Docker cleanup on stop
`instant_deploy`	No	Start/deploy immediately after create
`destination_uuid`	No	Destination UUID
`environment_name`	No	Environment name
`environment_uuid`	No	Environment UUID
`delete_configurations`	No	Also delete configurations
`force_domain_override`	No	Override domain conflict
`connect_to_docker_network`	No	Connect to Docker network
`delete_connected_networks`	No	Delete connected networks
`is_container_label_escape_enabled`	No	Container label escape enabled

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations include openWorldHint, indicating potential side effects. Description adds safety requirement for destructive operations and reveals opt-in behavior, but does not detail other side effects, error behavior, or state changes beyond these notes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is compact, front-loaded with purpose, and uses a clear list of actions. Every sentence adds value without repetition, though formatting could be improved for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 41 parameters and 16 actions, the description is too brief. It does not explain per-action parameters, dependencies, or return values. An output schema exists but is not shown; the description should provide more guidance for such complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond listing action signatures, which are already in the enum. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Service CRUD, lifecycle, and environment-variable actions' and distinguishes from sibling 'resource' tool by noting 'list via resource tool'. Enumerates all actions, establishing a specific verb+resource mapping.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides safety notes on 'confirm for destructive ops' and mentions optional instance and reveal opt-in. However, lacks explicit guidance on when to use this tool versus siblings like 'application' or 'deployment', and no when-not-to instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

setupB

Workspace setup: gh preflight, Coolify linkage, optional greenfield provisioning. Actions: preflight() · wire(mode, set_env?, env_file?, env_content?, ...) · resume(mode?, set_env?, env_file?, env_content?, ...) Safety: optional instance · no auto-push · gh soft-pause

ParametersJSON Schema

Name	Required	Description
`mode`	No	Setup mode for wire/resume
`page`	No	Page number for pagination
`push`	No	Push to GitHub after repo create (default false)
`type`	No	One-click service type
`action`	Yes	The action to run
`format`	No	Output format style
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`db_name`	No	Database name for create-app-db
`domains`	No	Comma-separated domains when include_domains
`env_key`	No	Env key for create-app-db
`set_env`	No	Sync env vars after wire (default false)
`skip_gh`	No	Skip gh preflight (link-existing without repo step)
`app_name`	No	Application name for create-app-db
`env_file`	No	Local filesystem path to a .env file
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`per_page`	No	Items per page
`db_engine`	No	Database engine for create-app-db
`max_chars`	No	Maximum characters in text response before truncation
`repo_name`	No	GitHub repo name for greenfield create
`repo_path`	No	Local repo path for create-git-app
`build_pack`	No	Build pack for create-git-app
`git_branch`	No	Git branch for create-git-app
`projection`	No	Detail projection depth
`env_content`	No	Inline .env file content
`recipe_type`	No	Recipe action for greenfield wire
`server_uuid`	No	Target server UUID
`include_full`	No	Alias for projection: full
`project_name`	No	Project name for lookup
`project_uuid`	No	Project UUID
`git_repository`	No	Git repository URL for create-git-app
`instant_deploy`	No	Instant deploy for recipe create
`include_domains`	No	Attach domains after wire (default false)
`application_uuid`	No	Existing application UUID for link-existing manifest
`deploy_and_watch`	No	Deploy and watch after wire (default false)
`environment_name`	No	Environment name
`environment_uuid`	No	Environment UUID
`initial_environment`	No	Initial environment name for greenfield project create

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds safety-related behavior beyond the annotations, such as 'no auto-push' and 'optional instance', which is useful. However, it doesn't disclose other important traits like auth requirements, rate limits, or side effects, and the 'gh soft-pause' note is cryptic and unclear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise, using three short lines to convey purpose, actions, and safety. Each sentence has a distinct role, and there is no wasted wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's high complexity (37 parameters, 3 actions), the description is too brief. It doesn't explain the differences between actions, which parameters belong to which action, or how the output schema relates to the tool's behavior. The description leaves many questions unanswered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% parameter descriptions, so the baseline is 3. The description's action signatures (e.g., wire(mode, set_env?, ...)) do not add meaningful semantics beyond what the schema already offers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is for workspace setup, involving gh preflight, Coolify linkage, and optional greenfield provisioning. It lists specific actions (preflight, wire, resume), giving a general sense of the tool's scope, but it doesn't fully explain what each action does, so it's not as clear as it could be.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternative tools like deployment or resource. There's no mention of when to use preflight vs wire vs resume, or any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

systemA

Read-only

System actions for Coolify (health, version, verify, infrastructure_overview). Actions: health() · version() → { coolifyVersion, mcpVersion, serverName, capabilities } (not legacy { version }) · verify() · infrastructure_overview(format?, max_chars?) Safety: confirm for destructive ops · optional instance · reveal opt-in only

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number for pagination
`action`	Yes	The action to run
`format`	No	Output format style
`reveal`	No	Reveal sensitive/masked values in full projection (default false — secrets masked as ***)
`instance`	No	Coolify instance name from registry (optional — uses env credentials or registry default)
`per_page`	No	Items per page
`max_chars`	No	Maximum characters in text response before truncation
`projection`	No	Detail projection depth
`include_full`	No	Alias for projection: full

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`_meta`	No
`error`	No
`_size_warning`	No
`_formattedText`	No

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds important behavioral details beyond the annotations: version() returns a specific structure and explicitly warns 'not legacy { version }', clarifying a potential breaking change. It also discloses 'reveal opt-in only', which informs the agent that sensitive values are masked unless opted in. These details are not present in annotations (readOnlyHint true, openWorldHint true). No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: first sentence states the purpose and lists actions, second gives return type info for version, third covers safety and options. No redundant filler; every clause adds information. It is well-structured for quick scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 sub-actions, 9 parameters, and an output schema, the description covers the key points: it enumerates actions, clarifies the version return shape, and mentions safety. However, it does not explain pagination parameters (page, per_page) or how they relate to infrastructure_overview, and the 'confirm for destructive ops' line is vague since all listed actions are read-only. Still, with a rich schema and output schema, it is fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage for all 9 parameters, so schema alone is strong. The description adds value by linking 'format?' and 'max_chars?' specifically to infrastructure_overview, helping the agent know which parameters apply to which action. Without this, the agent might not know the action-parameter mapping. This goes beyond the generic schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states this tool provides 'System actions for Coolify' and enumerates the four specific actions: health, version, verify, and infrastructure_overview. This is a specific verb-resource combination that distinguishes it from sibling tools that handle deployments, servers, databases, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives some usage context: 'Safety: confirm for destructive ops · optional instance · reveal opt-in only'. It indicates that destructive operations (if any) require confirmation, that an optional instance can be specified, and that reveal is opt-in. However, it does not explicitly say when to prefer this tool over siblings or exclude alternatives. The usage is implied by listing the actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation3/5

While each tool targets a distinct domain (applications, databases, servers, etc.), there is notable cross-tool overlap: multiple tools expose `logs` actions (application, deployment, diagnose), and `version` appears in both `system` and `meta`. Also, `resource.list/find` competes with domain-specific listing tools, creating potential for agent misselection.

Naming Consistency5/5

All tool names are lowercase nouns in a consistent singular style (application, private_key, environment), and actions follow a predictable verb pattern (get, list, create, update, delete, start, stop, restart, deploy). Child actions use a uniform colon syntax (envs:list, backup:now), with no mixed casing or stylistic chaos.

Tool Count4/5

With 19 tools, the server is in the 'heavy but reasonable' range. Each tool addresses a meaningful aspect of Coolify administration, though some could be consolidated (e.g., meta/system overlap, resource vs domain-specific lists). The count is not excessive given the domain's complexity.

Completeness4/5

The tool surface covers a broad range of Coolify resources, including applications, services, databases, servers, projects, environments, private keys, and deployments. Minor gaps exist, such as no update action for environments and no application backup actions (database backups are covered), but these are workaround-able and core workflows are well supported.

Maintenance

ActivityActive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
SupabaseOAuth
com.supabase
MCP server for interacting with the Supabase platform
Cloud Platforms Databases Developer Tools
32,887
serverOAuth
com.devopness.mcp
Devopness MCP server for DevOps happiness! Empower AI Agents to deploy apps and infra, to any cloud.
Cloud Platforms CI/CD & DevOps Developer Tools
3
server B
io.cycloid.mcp
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
Developer Tools CI/CD & DevOps Cloud Platforms
62

Related MCP Servers

coolify-mcp
Cloud Platforms Databases Shell Access
jimrarras
A
license
A
quality
B
maintenance
MCP server for managing a self-hosted Coolify instance. Provides full REST CRUD, deploy/watch capabilities, and an optional host-ops tier for live log streaming, SSH, Docker, and database access.
Updated 10 days ago (2026-08-24 21:23 UTC)
22
14
MIT
coolify-mcp
Cloud Platforms Developer Tools CI/CD & DevOps
0xtlt
A
license
B
quality
B
maintenance
MCP server for managing Coolify instances, enabling control of applications, databases, services, servers, and more via natural language.
Updated 22 days ago (2026-08-12 15:08 UTC)
116
157
MIT
awesome-coolify-mcp
Cloud Platforms CI/CD & DevOps
clezcoding
A
license
Not graded
quality
C
maintenance
Enables managing multiple self-hosted Coolify instances via MCP, with tools for deploying, monitoring, and emergency operations.
Updated 2 months ago (2026-07-16 19:29 UTC)
MIT
coolify-mcp
CI/CD & DevOps Developer Tools
frndchagas
A
license
B
quality
A
maintenance
MCP server for Coolify API that enables full deployment workflows from zero to production, including project, server, and application management.
Updated 10 days ago (2026-08-24 02:41 UTC)
65
462
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/clezcoding/awesome-coolify'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

📋 Table of contents

🔭 Overview

🆚 Why awesome-coolify-mcp

✨ Features

🏗️ How it works

🚀 Quick start

📦 Install

1. One-click deeplink

2. Install configurator (GitHub Pages)

3. Manual MCP config

IDE skills (Cursor, Claude Code, Codex)

🖥️ Supported clients

🔐 Environment variables

☁️ Coolify Cloud

💬 MCP Prompts

🧰 Tools reference

🖥️ system — connectivity & overview

🏷️ meta — server identity

🔎 resource — discovery

🩺 diagnose — investigation

🚀 application — app operations

📈 deployment — deploy tracking

🛡️ Deploy guard (preflight + rollback)

⏱️ Watch — bounded deploy monitoring

🧩 service / database — sidecar lifecycle

🍳 recipe — multi-resource orchestration

🌱 Resource environment variables (envs:*)

💾 Database backups (backup:*)

🔑 private_key — SSH key CRUD

🖧 server — server CRUD & validation

📁 project — project CRUD

🌍 environment — environment CRUD

📚 docs — offline guides

🚨 emergency — high-impact ops (gated)

🗂️ instance — multi-instance registry

📜 manifest — local cache

🧭 setup — guided project wiring

🎨 Branding (serverInfo.icons)

🛡️ Safety model

Confirmation gate

Secret masking

⚠️ Structured errors & retries

💬 Example agent workflows

✅ Status today

🔮 Coming soon

🛠️ Local development

🔗 Links

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

🖥️ `system` — connectivity & overview

🏷️ `meta` — server identity

🔎 `resource` — discovery

🩺 `diagnose` — investigation

🚀 `application` — app operations

📈 `deployment` — deploy tracking

🛡️ Deploy guard (`preflight` + `rollback`)

🧩 `service` / `database` — sidecar lifecycle

🍳 `recipe` — multi-resource orchestration

🌱 Resource environment variables (`envs:*`)

💾 Database backups (`backup:*`)

🔑 `private_key` — SSH key CRUD

🖧 `server` — server CRUD & validation

📁 `project` — project CRUD

🌍 `environment` — environment CRUD

📚 `docs` — offline guides

🚨 `emergency` — high-impact ops (gated)

🗂️ `instance` — multi-instance registry

📜 `manifest` — local cache

🧭 `setup` — guided project wiring

🎨 Branding (`serverInfo.icons`)