Loading ToolBench
MCP server that exposes Coolify instance inspection and management over the Model Context Protocol, allowing agents to inspect applications, view logs, and manage deployments
Cooldeck demonstrates solid tool design with clear verb-noun naming (list_applications, get_application, deploy_application, etc.) and comprehensive descriptions (avg 150-180 chars). All 10 tools have explicit descriptions and input schemas with typed parameters. Parameter descriptions are present and contextual (e.g., 'UUID of the application, as returned by list_applications'). However, output schemas are not documented in the visible code, the tool definitions show input schemas via jsonschema tags but no explicit return type documentation. Error handling is present (toolError function) but recovery guidance is minimal. Tool composition is clean: each tool has one responsibility, and tools chain well (list_applications returns UUIDs that downstream tools accept). Security is strong: no credentials in parameters, mutations gated behind AllowMutations flag. Minor gaps: no enum constraints on optional parameters, no explicit pagination documentation in list_deployments/get_runtime_logs despite having limit/lines parameters.
Queue a deployment for an application. Returns immediately with the queued deployment's UUID; follow it with list_deployments or get_deployment_logs.
Full detail for one application: configuration, domains, health check, and its recent deployment history.
Build and deployment log for one deployment - this is where a failed build explains itself.
Which Coolify instance this server talks to: URL, version, team, measured latency and which operations the token is allowed to perform. Never includes the token.
Runtime logs of a running application - what the container is printing now. Use this to diagnose an application that is up but misbehaving. For why a build failed, use get_deployment_logs instead.
Output schemas not documented. Tool definitions show input schemas via jsonschema tags but no explicit return type documentation. LLMs cannot plan downstream calls or extract fields without knowing what each tool returns.
Pagination limits (maxLogLines=2000, maxDeployments=200) are clamped silently without informing the LLM. Tool descriptions should state 'Results capped at 100 lines' or similar so agents know they may not get all data.
Error handling maps domain errors to toolError but recovery guidance is not visible in code. Descriptions do not hint at what to do if a UUID is invalid or a deployment fails (e.g., 'If deployment fails, check get_deployment_logs for build errors').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2025-06-18+ | v2 |
List every application on the Coolify instance with its current status, project, environment and last deployment, plus the deployments currently in flight. Start here: the other tools take UUIDs this returns.
Deployment history for one application, newest first, with status, commit and duration.
Restart a running application.
Start a stopped application.
Stop a running application. The application stays stopped until started again.
Mutating tools (deploy_application, restart_application, start_application, stop_application) lack confirmation or dry-run support. Agents cannot preview consequences before executing irreversible operations.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) not present in mcp.Tool definitions. This prevents clients from visually distinguishing safe reads from destructive writes.