Loading ToolBench
MCP server for Coolify — enables AI assistants to manage Coolify deployments through the Model Context Protocol
Coolify MCP has 15 tools with consistent naming (verb_noun pattern) and documented schemas. All tools have descriptions and input parameters with types. However, descriptions are generic (avg ~50 chars, well below the 194-char baseline), lack actionable context for LLM selection, and omit error recovery guidance. Output schemas are not documented. Parameter descriptions are minimal, many lack format constraints, ranges, or dependency hints. No tool annotations (readOnlyHint/destructiveHint). Error handling is absent from visible code. The server follows basic structure but lacks the depth needed for production-grade agent reasoning.
Set multiple environment variables at once
Create a Docker Compose application
Create an application from a prebuilt Docker image
Create an application with a Dockerfile
Create an application from a private repository using a deploy key
Create an application from a private repository using GitHub App
Descriptions are too brief (avg ~45 chars vs 194-char baseline). Missing WHEN to use, prerequisites, and error recovery hints. LLMs cannot distinguish between similar tools (e.g., create_application_* variants) or know what to do on failure.
Parameter descriptions lack format constraints, ranges, and dependency hints. E.g., 'branch' has no guidance on valid formats; 'status' filter has no enum of valid values; no indication that some create_application_* tools are mutually exclusive.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Create an application from a public repository
Get details of a specific application
Get the status of a deployment
Get deployment or application logs
List applications with optional filtering
List environment variables for an application
List all Coolify projects
Set a single environment variable
Trigger a new deployment
Output schemas are not documented. Callers cannot know what fields to expect from list_applications, get_application, or create_* tools. This breaks tool chaining and forces LLMs to guess field names for downstream calls.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe reads from destructive writes (trigger_deploy, set_env, bulk_set_envs) without explicit hints. This risks accidental deployments or env var overwrites.
No error handling or recovery guidance visible in tool implementations. Validation errors are generic ('Validation failed: ...'). LLMs have no guidance on retryability, user-fixable issues, or next steps on failure.