The Coolify MCP Server enables comprehensive programmatic management and automation of Coolify instances through the Coolify API, providing control over infrastructure and application lifecycle operations.
System Health & Monitoring: Check Coolify version information, API health status, retrieve application logs, and monitor deployment status and history
Team Management: List teams, get team details, view members, and access current authenticated team context
Project & Environment Organization: Create and list projects to organize resources; create and list environments within projects for different deployment stages (production, staging, development)
Server Infrastructure: Create servers with SSH configuration, list and validate servers, monitor server resources and connectivity, view deployed applications, and manage server domains and proxy settings (Nginx/Caddy)
Application Lifecycle Management: Create applications from Git repositories, start/stop/restart applications, execute commands in running containers, configure exposed ports for external access, and retrieve logs for troubleshooting
Service Management: Create services (MySQL, Redis, PostgreSQL, MongoDB, or custom Docker Compose), start/stop/restart services, list all services, and deploy with custom Docker Compose configurations
Deployment Operations: List all deployments, get detailed deployment information, and track deployment history
Security & Access: Create and manage SSH private keys for server authentication and Git repository access
Enhanced Features: Improved error reporting, UUID format compatibility, and automatic version detection for Coolify 4.0.0-beta.380+
Allows creating and managing ClickHouse databases in Coolify.
Allows deploying applications using Dockerfiles, Docker images, or Docker Compose configurations.
Allows integrating GitHub repositories and managing GitHub Apps for automatic deployments.
Allows provisioning and managing Hetzner cloud servers, including creating servers with various configurations.
Allows creating and managing MariaDB databases in Coolify.
Allows creating and managing MongoDB databases in Coolify.
Allows creating and managing MySQL databases in Coolify.
Allows creating and managing PostgreSQL databases in Coolify.
Allows creating and managing Redis databases in Coolify.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Coolify MCP Server list my projects and show their current environments"
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.
A Model Context Protocol (MCP) server providing full coverage of the Coolify v4.3.1 REST API. Manage applications, databases, services, servers, deployments, and more — all from any MCP-compatible AI client.
Compatibility: Coolify v4.x. API base:
https://<your-coolify-instance>/api/v1
Coolify v4.2.0 made state-changing endpoints POST-only; the former GET routes now
return This endpoint has changed to a POST request. This server issues POST for
all of them. Lifecycle and deploy operations remain compatible with earlier v4.x
releases, which accepted both methods. Three tools — enable_api, disable_api
and validate_server — call endpoints that were GET-only before v4.2.0 and so
require Coolify v4.2.0 or newer.
Node.js 18 or higher
A running Coolify v4 instance (v4.2.0+ for the three tools noted above)
A Coolify API token (from Security → API Tokens in the dashboard)
Related MCP server: Enhanced Coolify MCP Server
# Install globally
npm install -g coolify-mcp-server
# Or use with npx (no install needed)
npx coolify-mcp-serverSet two environment variables:
Variable | Description |
| Base URL of your Coolify instance (e.g. |
| Your Coolify API Bearer token |
{
"mcpServers": {
"coolify": {
"command": "npx",
"args": ["-y", "coolify-mcp-server"],
"env": {
"COOLIFY_BASE_URL": "https://your-coolify-instance",
"COOLIFY_TOKEN": "your-api-token"
}
}
}
}Windows users (Cline/cmd):
{
"mcpServers": {
"coolify": {
"command": "cmd",
"args": ["/c", "npx", "-y", "coolify-mcp-server"],
"env": {
"COOLIFY_BASE_URL": "https://your-coolify-instance",
"COOLIFY_TOKEN": "your-api-token"
}
}
}
}get_version — Get Coolify version
health_check — API health check (no auth)
enable_api / disable_api — Enable/disable the API (root token)
enable_mcp / disable_mcp — Enable/disable built-in MCP endpoint (root token)
list_teams, get_team, get_team_members
get_current_team, get_current_team_members
list_servers, get_server, create_server, update_server, delete_server
validate_server, get_server_resources, get_server_domains
create_hetzner_server
list_projects, get_project, create_project, update_project, delete_project
list_environments, get_environment, create_environment, delete_environment
list_applications, get_application
create_public_application, create_private_github_app_application, create_private_deploy_key_application
create_dockerfile_application, create_dockerimage_application
update_application, delete_application
start_application, stop_application, restart_application
get_application_logs
list_application_envs, create_application_env, update_application_env, bulk_update_application_envs, delete_application_env
list_application_storages, create_application_storage, delete_application_storage
list_application_scheduled_tasks, create_application_scheduled_task, delete_application_scheduled_task
To create a resource from a raw Docker Compose file, use
create_servicewithdocker_compose_raw. Coolify has no application-level compose creation endpoint.
list_databases, get_database, update_database, delete_database
create_postgresql_database, create_mysql_database, create_mariadb_database, create_mongodb_database
create_redis_database, create_keydb_database, create_dragonfly_database, create_clickhouse_database
start_database, stop_database, restart_database
get_database_backups, create_database_backup, list_database_backup_executions
list_database_envs, create_database_env, delete_database_env
list_services, get_service, create_service, update_service, delete_service
start_service, stop_service, restart_service
list_service_envs, create_service_env, delete_service_env
list_service_scheduled_tasks, create_service_scheduled_task, delete_service_scheduled_task
list_deployments, get_deployment, cancel_deployment
list_deployments_by_application, deploy_by_tag_or_uuid
list_private_keys, get_private_key, create_private_key, update_private_key, delete_private_key
list_github_apps, create_github_app, delete_github_app, list_github_app_repositories
list_cloud_tokens, create_cloud_token, delete_cloud_token
get_hetzner_locations, get_hetzner_server_types, get_hetzner_images, get_hetzner_ssh_keys
create_hetzner_server
list_resources — All resources across the instance
MIT
Create a new application in Coolify. Applications are deployable units that can be sourced from Git repositories.
| Name | Required | Description | Default |
|---|---|---|---|
| destination_uuid | Yes | UUID of the destination server where this application will be deployed. Get this from list_servers. | |
| environment_name | Yes | Name of the deployment environment (e.g., production, staging, development) | |
| environment_uuid | No | Optional UUID of an existing environment to use | |
| git_repository | No | URL of the Git repository containing the application code | |
| ports_exposes | No | Comma-separated list of ports to expose (e.g., "3000,8080"). These ports will be accessible from outside the container. | |
| project_uuid | Yes | UUID of the project this application belongs to. Projects help organize related applications. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool creates something, implying a mutation, but doesn't cover critical aspects: whether this triggers a deployment, what permissions are needed, if it's idempotent, error handling, or what the return value contains. The Git repository mention hints at source, but lacks depth on behavioral impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste. The first sentence states the core purpose, and the second adds useful context about applications without redundancy. It's appropriately sized and front-loaded, with every sentence earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral details (e.g., deployment consequences, error cases), usage prerequisites, and output expectations. The agent must rely heavily on schema and trial-and-error, which is inadequate for a creation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 6 parameters thoroughly. The description adds no parameter-specific information beyond the general context of Git repositories, which is implied by the git_repository parameter. This meets the baseline of 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new application') and resource ('in Coolify'), with additional context about what applications are ('deployable units that can be sourced from Git repositories'). It distinguishes from siblings like create_environment or create_project by focusing specifically on applications, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. It doesn't mention prerequisites (e.g., needing a project or server first), when to choose this over other creation tools, or any constraints like permissions or quotas. The agent must infer usage from parameter requirements alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new environment within a project.
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | Optional description of the environment | |
| name | Yes | Name of the environment | |
| project_uuid | Yes | UUID of the project where this environment will be created |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a creation operation but doesn't mention any behavioral traits: no information about permissions required, whether this is idempotent, what happens on duplicate names, rate limits, or what the response contains. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place, and there's no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects (permissions, idempotency, error conditions) or explain what the tool returns. Given the complexity of creating a resource and the lack of structured fields to compensate, the description should provide more context about how this operation works.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (it doesn't explain parameter relationships, constraints, or provide usage examples). The baseline score of 3 reflects adequate but minimal value added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new environment within a project'), making the purpose immediately understandable. It distinguishes from siblings like 'create_project' by specifying the resource type, though it doesn't explicitly contrast with other environment-related tools like 'list_environments'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. It doesn't mention prerequisites (like needing an existing project), when not to use it, or how it differs from other creation tools (e.g., 'create_project' for projects vs. 'create_environment' for environments within projects).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new SSH private key in Coolify for server authentication or Git repository access.
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | Optional description of the key's purpose or usage | |
| name | Yes | A unique, human-readable name for the private key | |
| private_key | Yes | The SSH private key content in PEM format. Must be a valid SSH private key. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool creates a key but doesn't disclose behavioral traits such as whether this requires admin permissions, if the key is stored securely, potential rate limits, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and purpose without unnecessary words. Every part of the sentence contributes to understanding the tool's function, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 3 parameters), no annotations, and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose and usage context but lacks details on behavioral aspects, error handling, or return values, which are crucial for a tool that creates sensitive resources like SSH keys.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't clarify format constraints or usage examples for parameters). Baseline 3 is appropriate when the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new SSH private key') and the resource ('in Coolify'), with specific purposes mentioned ('for server authentication or Git repository access'). It distinguishes from siblings like list_private_keys by focusing on creation rather than listing, though it doesn't explicitly contrast with all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('for server authentication or Git repository access'), suggesting when this tool might be appropriate. However, it lacks explicit guidance on when to use alternatives (e.g., list_private_keys for viewing existing keys) or any prerequisites, leaving usage somewhat inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new project to organize applications and services.
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | Optional description of the project | |
| name | Yes | Name of the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool creates a project but lacks details on permissions required, whether creation is idempotent, what happens on duplicate names, or the response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without redundancy. It is front-loaded with the core action and resource, making it easy to parse. Every word earns its place, with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation (create) with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like error conditions, response structure, or integration with sibling tools (e.g., how projects relate to applications/services). For a creation tool in this context, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for both parameters (name and description). The description adds no additional parameter semantics beyond what the schema provides, such as naming constraints or description usage. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new project') and the resource ('project'), specifying its purpose is 'to organize applications and services.' This distinguishes it from other creation tools like create_application or create_service by focusing on project-level organization. However, it doesn't explicitly contrast with siblings like get_project or list_projects beyond the verb difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. It doesn't mention prerequisites (e.g., needing a team context from get_current_team), exclusions, or comparisons to siblings like list_projects for viewing existing projects. Usage is implied only through the verb 'Create,' with no contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new server in Coolify. Requires SSH access details and a private key for authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | Optional description of the server's purpose or configuration | |
| instant_validate | No | Whether to validate the server configuration immediately after creation | |
| ip | Yes | IP address of the server. Can be IPv4 or IPv6. | |
| is_build_server | No | Whether this server should be used for building applications | |
| name | Yes | A unique, human-readable name for the server | |
| port | Yes | SSH port number | |
| private_key_uuid | Yes | UUID of the private key to use for SSH authentication. Obtain this from list_private_keys. | |
| proxy_type | No | Type of proxy to use for this server | nginx |
| user | Yes | SSH username for authentication |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions authentication requirements, which is useful, but fails to describe other critical behaviors: whether this is a mutating operation (implied by 'Create'), potential side effects, error handling, or what happens on success (e.g., server state). For a creation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Create a new server') and includes essential prerequisites. Every word earns its place with no redundancy or waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a server creation tool with 9 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on what the tool returns, error conditions, or detailed behavioral context. For a mutation tool with significant parameters, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 9 parameters thoroughly. The description adds minimal value beyond the schema by mentioning SSH access and private keys, which relate to parameters like 'private_key_uuid' and 'user,' but doesn't provide additional syntax or format details. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new server in Coolify'), making the purpose unambiguous. It distinguishes from siblings like 'create_application' or 'create_project' by specifying server creation. However, it doesn't explicitly contrast with similar tools like 'validate_server'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'Requires SSH access details and a private key for authentication,' suggesting prerequisites. However, it doesn't explicitly state when to use this tool versus alternatives like 'validate_server' or 'list_servers,' nor does it provide exclusions or clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new service on a specified server. Services are containerized applications that run on your Coolify servers. Either "type" or "docker_compose_raw" must be provided - you cannot specify both.
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | Optional description of the service's purpose or configuration | |
| docker_compose_raw | No | Raw Docker Compose configuration for the service. Required if type is not provided. Cannot be used together with type. | |
| environment_name | No | Name of the environment (e.g., production, staging, development) | |
| environment_uuid | No | Optional UUID of an existing environment to use | |
| name | Yes | A unique, human-readable name for the service | |
| project_uuid | Yes | UUID of the project this service belongs to. Projects help organize related services. | |
| server_uuid | Yes | UUID of the server where this service will run. Obtain this from list_servers. | |
| type | No | Type of service to create. Required if docker_compose_raw is not provided. Cannot be used together with docker_compose_raw. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the type/docker_compose_raw constraint, it doesn't describe what happens after creation (e.g., does the service start automatically?), what permissions are required, whether this is an idempotent operation, or what error conditions might occur. For a creation tool with significant impact, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - two sentences that each earn their place. The first establishes purpose and context, the second provides a critical constraint. No wasted words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what a successful creation returns, what happens to the service after creation, or potential side effects. The agent would need to guess about the outcome format and behavioral consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 8 parameters thoroughly. The description adds the important constraint about type/docker_compose_raw mutual exclusivity, which provides context beyond the individual parameter descriptions. However, it doesn't add significant semantic value beyond what's already in the well-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new service') and the resource ('on a specified server'), with specific context about services being 'containerized applications that run on your Coolify servers.' It distinguishes from siblings like create_application by focusing specifically on services rather than applications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (creating containerized services) and includes an important constraint ('Either "type" or "docker_compose_raw" must be provided - you cannot specify both'). However, it doesn't explicitly differentiate when to use create_service versus create_application or other creation tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a command inside a running application container. Useful for debugging, maintenance, or running one-off tasks. Note: This endpoint may not be available in all Coolify versions.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The command to execute inside the container. This can be any valid shell command. | |
| uuid | Yes | UUID of the application where the command will be executed. Get this from list_applications. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool executes commands in a container (implying mutation/action) and notes availability constraints ('may not be available in all Coolify versions'), which is useful context. However, it lacks details on permissions, side effects, rate limits, or response format, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage context and a note on availability. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a mutation tool. It covers purpose and basic usage but lacks details on behavioral traits (e.g., security implications, error handling) and output expectations, which are critical for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description does not add meaning beyond the schema (e.g., it doesn't explain command syntax or UUID sourcing further). Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('execute a command') and target ('inside a running application container'), distinguishing it from siblings like 'get_application_logs' (read-only logs) or 'restart_application' (restart operations). It provides a verb+resource+scope combination that is precise and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('useful for debugging, maintenance, or running one-off tasks'), giving clear context. However, it does not specify when NOT to use it or name alternatives (e.g., vs. 'get_application_logs' for read-only access), missing full sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get application logs by UUID. Essential for debugging and monitoring application behavior, errors, and performance issues. Retrieve logs from running applications to troubleshoot deployment issues and monitor application health.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Number of lines to show from the end of the logs. Controls log volume for performance. Default is 100 lines. | |
| uuid | Yes | UUID of the application to retrieve logs for. Get this from list_applications. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the tool is for 'debugging and monitoring' and 'retrieve logs from running applications,' it doesn't disclose important behavioral traits like whether this is a read-only operation, if it requires specific permissions, rate limits, pagination behavior, or what format/log-level the logs are returned in. For a tool with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that are front-loaded with the core purpose. However, the second and third sentences are somewhat redundant ('debugging and monitoring' vs 'troubleshoot deployment issues and monitor application health'), which slightly reduces efficiency. Overall, it's well-structured but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic purpose and usage context but lacks critical behavioral details (e.g., read-only nature, permissions, return format). For a tool with 2 parameters and 100% schema coverage, the description is minimally adequate but incomplete for safe and effective use by an AI agent without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (uuid and lines). The description doesn't add any parameter-specific semantics beyond what's in the schema—it doesn't explain UUID format constraints, line count implications, or provide additional usage examples. Baseline 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get application logs by UUID' with specific verbs ('get', 'retrieve') and resource ('application logs'). It distinguishes from siblings like list_applications (which lists applications rather than retrieving logs) but doesn't explicitly differentiate from other logging or monitoring tools that might exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context: 'Essential for debugging and monitoring application behavior, errors, and performance issues' and 'to troubleshoot deployment issues and monitor application health.' However, it doesn't explicitly state when to use this tool versus alternatives (like other logging tools or monitoring endpoints) or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of the currently authenticated team. This is the team associated with your API token.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates the tool is a read-only operation returning team details based on authentication, but it does not disclose potential fields returned, permissions required, or any side effects. The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the key action. Every word adds value, with no redundancy or filler. It is highly concise and efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with no output schema, the description provides the core purpose. However, it lacks details about the returned data structure, leaving the agent to infer 'details' without specifics. Additional context about the response format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is trivially 100%. According to guidelines, 0 parameters warrants a baseline of 4. The description does not need to add parameter meaning, and it correctly states the tool requires no input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details of the currently authenticated team. It distinguishes from siblings like 'get_team' (likely by ID) and 'list_teams' (returns all teams), making its specific purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when you need information about your own team associated with the API token. It implicitly differentiates from 'get_team' and 'list_teams', but does not explicitly state when not to use or mention alternatives. Clear context is provided, but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all members in the currently authenticated team. Shows who has access to team resources.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lacks disclosure of side effects, auth requirements, rate limits, error scenarios, or return format. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no wasted words. Front-loaded with action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, yet description doesn't clarify the return structure (e.g., fields, pagination). Simple tool but incomplete for an agent to process results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100% trivially, so baseline is 4. Description adds nothing beyond the schema, which is acceptable for zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves members of the current team, distinct from sibling tools like get_current_team (team info) and list_teams (all teams). The verb 'get' and resource 'members' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives, no when-not-to-use conditions, and no mention of prerequisites. The purpose is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific deployment. Use this to monitor deployment status and troubleshoot issues.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the deployment to retrieve. Obtain this from list_deployments or from deployment event responses. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves 'detailed information' but doesn't disclose behavioral traits like what information is included, whether it's read-only (implied by 'Get'), error conditions, authentication needs, or rate limits. The description is minimal and lacks essential context for a tool that likely returns complex deployment data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose. Every word earns its place: the first sentence defines the action, and the second provides usage context. There's no redundancy or unnecessary elaboration, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (likely returning detailed deployment data), no annotations, and no output schema, the description is insufficient. It doesn't explain what 'detailed information' includes, potential response formats, or error handling. For a tool in a deployment management context with many siblings, more completeness is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'uuid' well-documented in the schema. The description adds no parameter-specific information beyond what the schema provides (e.g., no additional constraints or examples). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about a specific deployment', which is specific and unambiguous. It distinguishes from siblings like list_deployments by focusing on a single deployment rather than listing multiple. However, it doesn't explicitly differentiate from other get_* tools (e.g., get_application_logs) beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context with 'to monitor deployment status and troubleshoot issues', suggesting when this tool is appropriate. It doesn't explicitly state when NOT to use it or name alternatives, but the context implies it's for detailed views rather than listings. No explicit comparison to siblings like list_deployments or other get_* tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific project including its environments.
| Name | Required | Description | Default |
|---|---|---|---|
| project_uuid | Yes | UUID of the project to retrieve. Get this from list_projects. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves project details and environments, but doesn't cover critical aspects like whether it's a read-only operation, authentication requirements, error handling, rate limits, or the format of returned data. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose. It's front-loaded with the main action and includes a useful detail ('including its environments') without unnecessary elaboration. There's zero waste, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' entail, how environments are included, error scenarios, or the response format. For a tool that retrieves project data, more context is needed to understand its full behavior and output, especially without structured fields to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'project_uuid' fully documented in the schema (including description, examples, pattern, and type). The description doesn't add any semantic information beyond what the schema provides, such as clarifying the scope of 'details' or 'environments'. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details of a specific project including its environments.' It uses a specific verb ('Get') and resource ('project'), and mentions the inclusion of environments. However, it doesn't explicitly differentiate from sibling tools like 'list_projects' or 'get_team', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. It doesn't mention sibling tools like 'list_projects' (for listing projects) or 'get_team' (for team details), nor does it specify prerequisites or exclusions. The input schema hints at getting the UUID from 'list_projects', but this isn't stated in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of domains configured for a server. These domains are used for routing traffic to applications and services.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | ID of the server to get domains for. Get this from list_servers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the domains are 'used for routing traffic to applications and services', adding some context, but lacks details on permissions, rate limits, response format, pagination, or error handling for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste, front-loading the core purpose and efficiently explaining the domains' use. Every word contributes meaning without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 1 parameter and no output schema, the description is adequate but incomplete. It covers the basic purpose but lacks guidance on usage, behavioral details, and output expectations, which are needed given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'uuid' fully documented in the schema. The description adds no additional parameter semantics beyond implying the tool fetches domains for a specific server, aligning with but not enhancing the schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a list') and resource ('domains configured for a server'), with the purpose being to retrieve routing information for applications and services. It distinguishes from siblings like 'list_servers' by focusing on domains, but doesn't explicitly differentiate from other 'get_' tools like 'get_server_resources'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a server UUID from 'list_servers'), exclusions, or comparisons to similar tools like 'get_server_resources' or 'list_servers', leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of applications and services running on a server. This provides an overview of all resources deployed on the specified server.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | ID of the server to check. Get this from list_servers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'provides an overview' without detailing behavioral traits like response format, pagination, error handling, or authentication needs. It mentions the server must be specified via UUID but doesn't clarify if this is a read-only operation or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two concise sentences that are front-loaded and waste-free. Each sentence adds value: the first states the core purpose, and the second clarifies the scope as an overview of all resources on the server.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter with full schema coverage and no output schema, the description adequately covers the tool's purpose and scope. However, as a read operation with no annotations, it lacks details on return values, error cases, or behavioral constraints, making it minimally viable but incomplete for optimal agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'uuid' fully documented in the schema as the server ID to check, sourced from list_servers. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'list of applications and services running on a server', specifying it provides an overview of all deployed resources. It distinguishes from siblings like list_applications/list_services by focusing on a specific server's resources, though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 list_applications or list_services is provided. The description implies usage for server-specific resource overviews but lacks context on prerequisites, exclusions, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific team. Requires a team ID obtained from list_teams.
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | ID of the team to retrieve. This is typically a numeric ID obtained from the list_teams response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the requirement for a team ID but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what 'details' include (e.g., team members, settings). This leaves significant gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by a prerequisite. Every word earns its place with no redundancy or fluff, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and prerequisite but lacks details on return values or behavioral context, which would be helpful for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'team_id' well-documented in the schema. The description adds minimal value by reinforcing that the ID comes from 'list_teams', but doesn't provide additional semantics beyond what the schema already covers, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get details') and resource ('a specific team'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_current_team' or 'list_teams', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying that a team ID from 'list_teams' is required, which helps guide usage. It doesn't explicitly state when to use this versus alternatives like 'get_current_team' or exclude other scenarios, preventing a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Coolify version information. Returns the current version of the Coolify instance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it returns version info but does not elaborate on side effects, read-only nature, or response structure. For a simple read operation, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. Every word adds value, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description provides sufficient context for a version check. It could optionally mention the output format, but the current level is adequate for a simple info tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds no extra meaning beyond the schema, but the absence of parameters makes this baseline appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves version information from Coolify, with a specific verb ('get') and resource ('version'), distinct from all sibling tools which manage applications, servers, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for using the tool to check the current version, though it does not explicitly exclude any scenarios or mention alternatives. Given its straightforward nature, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Coolify API health status. Note: This endpoint may not be available in all Coolify versions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about version-dependent availability, which isn't captured in structured fields. However, it doesn't describe other behavioral traits such as response format, error handling, authentication requirements, or rate limits, leaving gaps for a tool that likely returns system status information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, consisting of two sentences that directly state the purpose and a key constraint. Every sentence earns its place by providing essential information without redundancy or fluff, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but has clear gaps. It covers the basic purpose and a version constraint, but without annotations or output schema, it doesn't explain what the health check returns (e.g., status codes, metrics) or other contextual details like authentication needs. This makes it minimally viable but incomplete for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it appropriately avoids redundant information. A baseline of 4 is applied as per the rules for zero-parameter tools, since no parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as checking the Coolify API health status with a specific verb ('Check') and resource ('Coolify API health status'). It distinguishes itself from sibling tools which are focused on CRUD operations for applications, servers, projects, etc., rather than system health monitoring. However, it doesn't explicitly contrast with potential alternatives like 'get_version' which might provide related system information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by noting that the endpoint may not be available in all Coolify versions, suggesting it should be used cautiously in version-dependent contexts. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'get_version' for version checks or other health-related tools if they existed), and doesn't specify prerequisites or exclusions beyond version availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all applications across your Coolify instance. Applications are deployable units sourced from Git repositories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description implies a read-only operation by using 'List.' However, it does not disclose potential side effects, rate limits, or authentication requirements. The behavior is straightforward but lacks explicit transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loads the primary purpose. Every sentence earns its place: the first states the action, the second clarifies the resource definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not specify the return format or structure of listed applications. For a simple list tool, this is a minor gap. It adequately conveys the tool's function but leaves output details implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage). The description adds no parameter details, which is acceptable since there are none. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all applications across your Coolify instance.' It uses a specific verb-resource combination and distinguishes from siblings like create_application or restart_application by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_services or list_teams. There is no mention of prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all deployments across your Coolify instance. Deployments represent the history of application and service deployments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only list operation, which is non-destructive. However, with no annotations, the description lacks details on pagination, rate limits, or any other behavioral traits beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences that directly state the purpose. It is front-loaded with the verb and resource, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, simple list operation), the description is nearly complete. It could mention if there is any default ordering or limit, but overall it suffices for an agent to understand the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and 100% schema description coverage. The description does not add any parameter-specific meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists all deployments across the Coolify instance, with a specific verb and resource. It distinguishes itself from sibling tools like get_deployment, which is singular.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives like get_deployment. The usage context is implied by the name and description, but no when-not or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all environments in a project. Environments separate different deployment stages like production, staging, development.
| Name | Required | Description | Default |
|---|---|---|---|
| project_uuid | Yes | UUID of the project to list environments for. Get this from list_projects. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a listing operation, implying it's read-only and non-destructive, but doesn't confirm this explicitly. It misses details like pagination, rate limits, authentication needs, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: the first states the core purpose, and the second adds useful context about environments. Every sentence earns its place by clarifying the tool's scope without redundancy. It's front-loaded with the main action and avoids unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally complete. It covers the basic purpose and context but lacks details on behavior, usage scenarios, or output format. Without annotations or output schema, the description should do more to compensate, such as hinting at return values or error cases, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention any parameters, but the input schema has 100% coverage with a well-documented 'project_uuid' parameter. Since schema_description_coverage is high, the baseline score is 3. The description adds no parameter semantics beyond what the schema provides, such as clarifying the relationship between projects and environments, but this doesn't detract from the adequate schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all environments in a project'), making the purpose specific and understandable. It distinguishes from siblings like 'get_project' or 'list_applications' by focusing on environments, though it doesn't explicitly contrast with them. The addition of 'Environments separate different deployment stages...' provides helpful context but doesn't fully differentiate from similar listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'project' context and deployment stages, suggesting it's for viewing environment configurations. However, it lacks explicit guidance on when to use this versus alternatives like 'list_applications' or 'get_project', and doesn't mention prerequisites or exclusions. The input schema hints at needing 'project_uuid' from 'list_projects', but this isn't stated in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all SSH private keys stored in Coolify. These keys are used for server authentication and Git repository access.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It does not mention that this is a read-only safe operation, or provide any information about performance, rate limits, or side effects. The description is minimal and fails to disclose important behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that efficiently convey the action and additional context. Every word adds value, and it is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description is minimal but adequate for a parameterless list tool. However, it could be more complete by mentioning the type of data returned (e.g., key names, IDs).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. According to guidelines, baseline is 4 when no parameters exist. The description does not need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the exact resource 'SSH private keys stored in Coolify', also explaining their use for server authentication and Git repository access. This clearly distinguishes it from sibling tools like create_private_key or list_applications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 is provided. The description simply states what it does, leaving the agent to infer usage. For a simple list-all tool, this is adequate but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all projects accessible by the current user. Projects organize applications and services into logical groups.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists projects but lacks details on behavior like pagination, sorting, error handling, or authentication requirements. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first states the purpose clearly, and the second adds useful context about what projects organize. It's front-loaded and wastes no words, though the second sentence could be considered slightly extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain return values, error cases, or behavioral traits like rate limits. For a list operation, this leaves gaps in understanding how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('projects'), specifying that it retrieves all projects accessible by the current user. It distinguishes from siblings like 'get_project' by indicating it lists multiple items rather than fetching a single one, though it doesn't explicitly contrast with other list tools like 'list_applications'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing authentication, or compare it to similar tools like 'get_project' for single-project retrieval or 'list_teams' for other resources, leaving usage context implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all servers registered in your Coolify instance. Use this to get server UUIDs needed for other operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions listing but does not explicitly state it is read-only or non-destructive. The value added is the mention of UUID retrieval, but more detail on side effects or permissions would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with the primary action. Every sentence serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is adequate. It explains what the tool does and why it's useful. It could optionally mention that the output is a list of server objects, but the current description is sufficiently complete for its low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage. The description adds no parameter info because none exist, which is appropriate. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all servers and specifies the purpose: to get server UUIDs for other operations, distinguishing it from sibling tools like create_server or validate_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use this to get server UUIDs needed for other operations.' It implies when to use but does not specify when not to use, though for a list tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all services across your Coolify instance. Services are containerized applications running on your servers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the tool lists all services, but does not mention if the list is complete, whether pagination exists, what fields are returned, or any side effects (like read-only nature). The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with the key action. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what is returned. It does not mention output structure (e.g., list of service names, IDs). However, given the simplicity and zero parameters, the description is marginally adequate for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the input schema is empty (100% coverage). According to the rubric, 0 parameters yields a baseline score of 4. The description does not need to elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'services'. It also defines what a service is ('containerized applications running on your servers'), which adds clarity beyond the name 'list_services'. This distinguishes it from sibling tools like 'list_applications'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For instance, there is no mention of filtering, pagination, or comparison with 'list_applications' or 'list_servers'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all teams the authenticated user has access to. Use this to get team UUIDs needed for other operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It states 'list all teams', implying a read-only, non-destructive operation. However, it does not disclose potential pagination, sorting, or response format details. This is adequate for a simple list tool but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The first sentence states the primary purpose, and the second sentence provides a usage hint. It is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers the essential aspects: what it lists and why to use it. It could be considered complete for an agent to understand its function, though minor details like ordering are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not required to explain parameter semantics. It adds value by explaining that the output contains team UUIDs for use in other operations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and resource 'teams' with scope 'the authenticated user has access to'. It also specifies the purpose of getting team UUIDs, which distinguishes it from sibling tools like get_current_team.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to get team UUIDs needed for other operations', providing clear guidance on when to use this tool. However, it does not mention when not to use it, but given the lack of alternatives for listing teams, this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart an application by stopping and starting it again. Useful for applying configuration changes or recovering from issues.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the application to restart. Get this from list_applications. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the action ('stopping and starting') but lacks details on permissions needed, downtime implications, whether it's reversible, or error handling. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and followed by usage context. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a mutation tool with no annotations and no output schema, the description should do more to explain behavioral aspects like side effects or return values. It covers purpose and basic usage but lacks depth for safe operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'uuid' well-documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('restart') and resource ('application'), specifying it involves 'stopping and starting it again'. It distinguishes from siblings like start_application and stop_application by describing the full restart cycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it ('useful for applying configuration changes or recovering from issues'), but does not explicitly mention when not to use it or name alternatives like restart_service for similar operations on different resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart a service by stopping and starting it again. Useful for applying configuration changes or recovering from issues.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the service to restart. Get this from list_services. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the action (restart) but lacks details on permissions needed, whether it's destructive (likely yes, as it stops and starts), potential downtime, error handling, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste: the first defines the action, and the second provides usage context. It's front-loaded with the core purpose and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation (restart) with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, permissions, or return values, which are crucial for an agent to use it correctly. The high schema coverage helps with parameters, but overall context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'uuid' fully documented in the schema (including description, pattern, and type). The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('restart a service') and the mechanism ('by stopping and starting it again'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'restart_application' or 'start_service/stop_service', which would require mentioning it's for services specifically (though implied by the name).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context ('useful for applying configuration changes or recovering from issues'), which gives general guidance on when to use it. However, it doesn't explicitly state when not to use it or name alternatives like 'start_service' or 'stop_service' for partial operations, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a previously created application. This will initialize the application container and make it accessible.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the application to start. Obtain this from list_applications or from the create_application response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions initialization and accessibility, but lacks critical details: whether this requires specific permissions, potential side effects (e.g., resource consumption), expected runtime, error conditions, or what 'accessible' means operationally. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that directly address the tool's purpose and effect. Every word earns its place, with no redundant information or fluff. It's front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after starting (e.g., how to verify success, what 'accessible' means, potential errors, or return values). Given the complexity of starting an application container, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the UUID parameter well-documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema (which explains how to obtain the UUID). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('start') and resource ('previously created application'), specifying that it initializes the container and makes it accessible. It distinguishes from 'create_application' by focusing on starting existing applications, but doesn't explicitly differentiate from similar tools like 'restart_application' or 'start_service'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'previously created application' and referencing where to obtain the UUID, suggesting it should be used after creation. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'restart_application' or 'start_service', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a previously created service. This will initialize the service container and make it accessible.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the service to start. Obtain this from list_services or from the create_service response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions initialization and accessibility but lacks details on permissions, side effects, error conditions, or response format. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste, front-loaded with the core purpose. Every word earns its place, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It should cover more behavioral aspects like what 'accessible' means, potential errors, or confirmation of success, but it only provides basic operational info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the 'uuid' parameter thoroughly. The description adds no additional parameter information beyond what's in the schema, meeting the baseline of 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start') and resource ('a previously created service'), specifying it initializes the container and makes it accessible. However, it doesn't explicitly differentiate from sibling tools like 'restart_service' or 'start_application', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives like 'restart_service' or 'start_application', nor does it mention prerequisites or exclusions. It only states what the tool does, not when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running application. This will gracefully shut down the application container.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the application to stop. Get this from list_applications. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action will 'gracefully shut down the application container,' which implies a controlled, non-destructive operation, but it does not cover potential side effects, permissions required, or error conditions. This is a moderate disclosure but lacks depth for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are front-loaded and waste-free. The first sentence states the core action, and the second adds important behavioral context ('gracefully shut down'), making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a simple input schema, the description is somewhat complete but could be improved. It covers the action and behavioral intent but lacks details on outcomes, errors, or dependencies, which are important for a mutation tool like stopping an application.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the uuid parameter fully documented in the schema. The description does not add any additional meaning or context beyond what the schema provides, such as format details or usage examples, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('stop') and resource ('a running application'), specifying it performs a graceful shutdown of the application container. This distinguishes it from sibling tools like restart_application (which restarts) and start_application (which starts), making the purpose specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an application needs to be stopped gracefully, but it does not explicitly state when to use this tool versus alternatives like restart_application or stop_service. No exclusions or prerequisites are mentioned, leaving some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running service. This will gracefully shut down the service container.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | UUID of the service to stop. Get this from list_services. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool 'gracefully shut[s] down the service container', which implies a controlled stop rather than immediate termination. However, it doesn't disclose important behavioral aspects like required permissions, whether the stop is reversible, error conditions, or what happens to dependent resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first states the core purpose, the second adds important behavioral context about graceful shutdown. No wasted words or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation (stopping a service) with no annotations and no output schema, the description provides basic purpose and behavioral context but lacks important details. It doesn't explain what 'gracefully' means operationally, what the response looks like, or potential side effects. Given the complexity of stopping a running service, more completeness would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'uuid' well-documented in the schema. The description doesn't add any parameter information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('stop') and resource ('a running service'), specifying it's a graceful shutdown of the service container. It distinguishes from siblings like 'restart_service' and 'stop_application' by focusing specifically on stopping services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a service needs to be stopped gracefully, but doesn't explicitly state when to use this vs alternatives like 'restart_service' or 'stop_application'. It mentions getting the UUID from 'list_services', which provides some context but not explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a server's configuration and connectivity. Use this to verify server setup and troubleshoot connection issues.
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | ID of the server to validate. Get this from list_servers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a read-only operation, what permissions are required, what happens during validation, whether it modifies anything, what the output format is, or any error conditions. The description adds minimal behavioral context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the core purpose, the second provides usage context. No wasted words, well-structured, and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation/diagnostic tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'validate' entails, what aspects are checked, what the expected output looks like, or how to interpret results. Given the complexity of server validation and the lack of structured output documentation, more detail would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'uuid' well-documented in the schema itself. The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('validate', 'verify', 'troubleshoot') and resource ('server's configuration and connectivity'). It distinguishes from most siblings that create, get, list, or control resources, but doesn't explicitly differentiate from 'health_check' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context ('verify server setup and troubleshoot connection issues') but doesn't explicitly state when to use this tool versus alternatives like 'health_check' or other diagnostic tools. No explicit exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create_applicationcreate_environmentcreate_private_keycreate_projectcreate_servercreate_serviceexecute_command_applicationget_application_logsget_current_teamget_current_team_membersget_deploymentget_projectget_server_domainsget_server_resourcesget_teamget_versionhealth_checklist_applicationslist_deploymentslist_environmentslist_private_keyslist_projectslist_serverslist_serviceslist_teamsrestart_applicationrestart_servicestart_applicationstart_servicestop_applicationstop_servicevalidate_serverScored across 32 tools
Most tools have distinct purposes targeting specific resources (applications, services, servers, projects, teams) and actions (create, get, list, restart, start, stop), with clear boundaries. However, some overlap exists between application and service tools (e.g., restart_application vs restart_service) that could cause confusion if the distinction between 'applications' and 'services' isn't fully understood, though descriptions help clarify.
Tool names follow a highly consistent verb_noun pattern throughout, such as create_application, list_servers, get_project, restart_service, and stop_application. All tools use snake_case without deviations, making them predictable and easy to parse for agents.
With 32 tools, the count is borderline high for a deployment management server, potentially feeling heavy and overwhelming. While it covers many operations, it might include redundant or overly granular tools that could be consolidated, such as separate start/stop/restart for applications and services.
The tool set provides comprehensive CRUD and lifecycle coverage for the Coolify domain, including creation, listing, retrieval, management (start/stop/restart), logging, deployment tracking, and validation. No obvious gaps exist; it supports full workflows from server setup to application deployment and monitoring.
Devopness MCP server for DevOps happiness! Empower AI Agents to deploy apps and infra, to any cloud.
A MCP server built for developers enabling Git based project management with project and personal…
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
