Manage Coolify from AI agents through a local MCP server with API discovery, composed workflows, and dry-run request plans.
Three well-structured tools with comprehensive descriptions and proper input schemas. Tool names are action-oriented (guide, search, execute). Descriptions are detailed and include workflow guidance (194 - 392 chars, within baseline). All parameters have types and descriptions. Tool annotations present (readOnlyHint, destructiveHint, idempotentHint). Key gaps: output schemas are not formally documented in the tool definitions; error handling guidance is minimal; no pagination or result-limiting parameters despite tools returning potentially large datasets.
Execute model-written JavaScript against Coolify with an authenticated request helper. Use this tool when: - you need to read live Coolify state; - you need to perform one or more dependent API calls in one MCP call; - you need to deploy, inspect deployments/logs, manage environment variables, or operate resources. Recommended workflow: 1. Search first unless operation IDs and params are already known. 2. Resolve names to UUIDs before acting. If more than one resource matches, return the choices instead of guessing. 3. Use throwOnError: true when partial completion would be confusing. 4. Return summaries, compact tables, or selected fields. Do not return entire lists/log payloads unless asked. 5. Use codemode.redactSecrets() before returning env vars, tokens, keys, or credentials. 6. For DELETE: run dryRun when practical, then require allowDestructive: true only after explicit user intent. 7. For operational actions (deploy/start/stop/restart/cancel): clearly return the affected UUIDs and Coolify response. Available APIs: - all search APIs - await codemode.request({ operationId, pathParams, query, body, headers, throwOnError }) - await codemode.request({ method, path, pathParams, query, body, headers, throwOnError }) The Coolify API token is never exposed to generated code. DELETE requests require allowDestructive: true on this outer tool call.
Get Coolify-specific operating guidance before using search or execute. Use this when the user asks for deployments, logs, environment variables, lifecycle actions, deletes, backups, resource discovery, or output formatting and you need the safest workflow. This is the local Coolify equivalent of a docs/workflow tool; it does not require credentials.
Search the embedded Coolify OpenAPI document and operation catalog with model-written JavaScript. Use this tool when: - you need operationId values, paths, parameters, request body shape, or response codes; - the user names a Coolify resource but not a UUID; - you are about to mutate Coolify and need to confirm the safest operation; - you need to inspect safetyCategory before execute. Recommended workflow: 1. Start with codemode.findOperations({ query, tags, safetyCategories, limit }). 2. Use codemode.operation(operationId) for one operation's parameters and safetyCategory. 3. Use codemode.guide(topic) for Coolify workflow guidance. 4. Avoid returning codemode.spec() wholesale; search narrowly. Available APIs: - await codemode.spec() - codemode.specPath() - await codemode.operations() - await codemode.operation(operationId) - await codemode.findOperations({ query, tags, methods, safetyCategories, actionTypes, risks, mutates, destructive, pathIncludes, limit }) - await codemode.classifyOperation(operationId) - await codemode.describeOperation(operationId) - codemode.guide(topic?) - codemode.format.tsv(rows) - codemode.format.compact(rows, columns?) - codemode.redactSecrets(value)
Output schemas not formally documented. Tool descriptions explain what APIs are available (codemode.findOperations, codemode.request) but do not specify the structure of returned data. LLMs cannot plan downstream tool calls or extract fields without knowing response shape.
No pagination or result-limiting parameters. search and execute can return large operation catalogs or API responses. Without limit/offset/cursor parameters and documented caps, LLMs risk context window exhaustion.
Error handling guidance is implicit. Descriptions mention 'throwOnError' and 'dryRun' but do not explain what errors are retryable, what user-fixable errors look like, or how to recover from timeouts or API failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
Code parameter accepts arbitrary JavaScript with no input validation or sandboxing guarantees documented. Descriptions mention 'sandbox' but do not specify what injection attacks are prevented or what the LLM should assume about safety.
guide tool topic parameter is optional with no enum constraint. Descriptions list valid topics (overview, discovery, deployments, logs, environment, lifecycle, deletion, backups, formatting) but do not enforce them as an enum, inviting hallucinated topic values.