Loading ToolBench
Model Context Protocol (MCP) server for Coolify API integration
The server defines 36 tools with basic input schemas and descriptions, but falls short of production-grade quality. All tools have descriptions (10-50 chars) and explicit enum/typed parameters in JSON Schema format. However, descriptions are consistently minimal, most under 50 chars, many under 30, offering little LLM guidance on *when* or *why* to call each tool. No output schemas are documented, making it impossible for agents to plan downstream calls. Most tools lack dependency hints, error recovery guidance, and natural-language parameter acceptance. The tool suite shows good naming (verb_noun pattern) and comprehensive coverage of the Coolify API surface, but the implementation prioritizes API fidelity over agent ergonomics. Schema definitions are present and mostly typed, but output documentation and error handling are absent.
Bulk update environment variables for an application
Bulk update environment variables for a service
Create a new application in Coolify
Create an environment variable for an application
Create a new private key in Coolify
Create a new server in Coolify
Create a new service in Coolify
No output schemas documented. Agents cannot plan downstream tool calls or extract required fields (e.g., team_id, server_uuid) for chaining. Returns are JSON-stringified text blobs with no declared structure.
Descriptions consistently too brief (10-50 chars). Most under 30 chars. Lack context on when to call vs similar tools, prerequisites, or side effects. E.g., 'Restart a service' tells an LLM nothing about why this differs from stop+start or whether it's idempotent.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Create an environment variable for a service
Delete an environment variable from an application
Delete an environment variable from a service
Get the current team details
Get members of the current team
Get details of a specific deployment
Get domains of a specific server
Get resources of a specific server
Get details for a specific team by ID
Get the version of the Coolify API
Perform a health check on the Coolify API
List deployments for a specific application
List environment variables for a specific application
List all applications in the Coolify instance
List all deployments in the Coolify instance
List all private keys in the Coolify instance
List all servers available in the Coolify instance
List environment variables for a specific service
List all services in the Coolify instance
List all teams available in the Coolify instance
Restart an application
Restart a service
Start an application
Start a service
Stop an application
Stop a service
Update an environment variable for an application
Update an environment variable for a service
Validate a server by UUID
No pagination support visible in list_* tools. No 'limit', 'offset', 'skip', 'take' parameters documented in tool specs. Large result sets will consume context and risk degraded reasoning. Example: list_teams, list_servers, list_services, list_applications, list_deployments.
No error recovery guidance. No indication of retryable vs fatal errors, what the LLM should do on failure, or how to self-correct. E.g., 'Server not found. Did you mean: …?' would enable agent self-correction without an extra call.
Destructive operations (delete_application_env, delete_service_env) lack dry-run or confirmation patterns. No indication that these are irreversible. Agents may call them inadvertently.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in tool definitions. Agents cannot infer risk level from metadata.
Parameter descriptions are generic and often omit format/constraint hints. E.g., 'Server UUID' does not specify format (UUID4?), length, or case sensitivity. 'Private key UUID' does not explain how to find it. Agents cannot validate before calling.
Required API key/token injected via environment (good), but no documentation of required permissions or scopes. Tool descriptions do not mention what credentials/roles are needed.
No audit logging or permission gating visible in tool implementations. Destructive operations like delete_application_env and delete_service_env do not check authorization before executing.
LLM is expected to pass opaque UUIDs (server_uuid, project_uuid, env_uuid). No tools or guidance to resolve human-friendly names (e.g., 'production', 'api-server') to UUIDs. Agents must call list_* first, extract IDs from unstructured text, then make the real call, wasteful and error-prone.