coolify-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v4.0.0
Disambiguation4/5
Tools are consistently prefixed by resource type (e.g., coolify_application, coolify_database), making them distinct within their sub-domains. However, the duplication of storage, env, and backup operations across applications, databases, and services creates some ambiguity; an agent might struggle to pick between similar tools for different resources without careful context management.
Naming Consistency5/5
All 116 tools follow a flawless coolify_<resource>_<action> snake_case pattern (e.g., coolify_list_applications, coolify_create_database, coolify_delete_service_env). The naming is highly predictable, with consistent verbs like list, create, get, update, delete, start, stop, and restart applied uniformly across resource types.
Tool Count4/5
At 116 tools, the count is at the high end, but it is justified by the comprehensive management of a complex PaaS platform covering applications, databases, services, servers, projects, teams, and more. The weight is noticeable, yet each tool serves a clear purpose, and the set would be incomplete without many of these operations.
Completeness5/5
The tool surface is extraordinarily complete, covering CRUD operations for all major resources (applications, databases, services, servers, projects, environments, private keys, GitHub apps, teams). It also includes lifecycle management (start, stop, restart), environment variables, storage, backups, scheduled tasks, deployments, logs, and health checks. There are no obvious operational gaps for managing a Coolify instance.
Average 3.3/5 across 116 of 116 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It correctly states this is a write operation but does not mention whether updating an existing key overwrites, what the return value is, whether the operation is idempotent, or any side effects (e.g., triggering a redeploy). The description does not contradict anything since there are no annotations, but it is insufficient for understanding behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that clearly states the action and target. It is appropriately concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that creates an environment variable with 8 parameters and no output schema, the description is minimally adequate. It tells the agent the basic action and target, but does not explain what happens after creation (e.g., does the service restart?), nor does it clarify the role of optional parameters like 'is_literal' or 'is_preview' beyond the schema. With no annotation support, more context is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all 3 required parameters have clear schema descriptions. The description adds only the tool-level context that this is an environment variable for a service, but does not add meaning beyond the schema. Since coverage is high, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '[WRITE]' which signals it's a mutation, but then says 'Create a new environment variable for a Coolify service'. While 'Create' and '[WRITE]' are consistent, the description does not differentiate this tool from 'coolify_create_env' which does the same for applications, not services. Without specifying that this targets services, the agent may confuse it with the generic environment variable creation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like 'coolify_create_env' (for applications) or 'coolify_create_database_env'. The description does not mention prerequisites (e.g., the service must exist), nor does it specify when not to use it. This is a critical gap given the large number of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. The [WRITE] prefix suggests mutability, but the description does not state required permissions, side effects, whether fields are overwritten or merged, or the response format. Without annotations, this is a significant gap in transparency 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line, which is concise. However, it is too brief and lacks structure or front-loaded key details. Every sentence should earn its place, and this description misses the opportunity to add value beyond the name. A score of 3 reflects adequate brevity but insufficient content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (all with schema descriptions), no output schema, and no annotations, the description is incomplete. It does not explain the update behavior (e.g., partial vs full update, what happens to unspecified fields), return value, or any prerequisite steps. An 'update' operation with a required 'uuid' suggests the project must exist, but this is not mentioned. For a tool with this complexity, the description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (name, uuid, description) has a schema description. However, the description itself adds nothing beyond the schema—it simply says 'Update a Coolify project' with no additional context on parameter semantics. For example, it doesn't clarify that 'uuid' is the identifier, that 'name' and 'description' are optional and what happens if omitted, or any value constraints. With a baseline of 3 due to high coverage, the lack of added value reduces the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says '[WRITE] Update a Coolify project', which clearly states the verb (update) and resource (Coolify project). The [WRITE] prefix hints at a mutation operation, distinguishing it from list/get tools. However, the description does not differentiate this from the sibling coolify_update_application or other update tools, and the title is null, missing an opportunity for further clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. With many sibling tools like coolify_update_application, coolify_update_server, coolify_update_database, etc., the description fails to specify the context or prerequisites (e.g., needing a project UUID) for using this tool. There are no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. 'Create' implies a mutation (write operation), but it doesn't mention whether the tool has side effects like auto-assigning IDs, creating default environments, or requiring specific permissions. There's no statement about the return value or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence fragment), which is concise but not necessarily well-structured. The '[WRITE]' prefix is unnecessary and adds clutter without value. It could front-load with a more informative verb phrase or omit the prefix entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, no annotations, and vast sibling tools, the description is incomplete. It doesn't explain the project concept, confirm that projects are containers for applications/databases, or hint at the expected output (e.g., created project ID/name). An agent might not understand the role of this tool in the Coldify workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description's lack of parameter details is partially excused. The input schema already documents 'name' (required, project name) and 'description' (optional, project description). The description adds no additional meaning beyond what the schema provides, but the schema is self-sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Create') and resource ('a new Coolify project'), which is clear. However, the '[WRITE]' prefix is redundant with the verb 'Create' and doesn't help differentiate this tool from other creation tools like 'coolify_create_application' or 'coolify_create_database'. It's adequate but not explicit about what a 'project' is in Coolify's context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not mention when to use this tool over alternatives like 'coolify_update_project' or 'coolify_create_environment'. It also lacks context about prerequisites (e.g., whether a team or server must exist first) or that it's typically the first step before creating applications or databases within the project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. However, it only states '[WRITE]' and 'Update a scheduled task', which implies mutation but does not detail side effects, authorization needs, idempotency, or what happens if the task does not exist. The '[WRITE]' tag is a weak substitute for proper behavioral annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line, which is short, but it lacks essential structure for a tool with 8 parameters. The '[WRITE]' prefix is useful, but the main text does not fully capture the tool's purpose or behavior. It is not excessively long, but it is under-specified given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (8) and the absence of annotations or an output schema, the description is insufficient. It does not explain return values, error conditions, or the expected behavior when partially updating fields. The presence of sibling tools for create and delete further demands clear differentiation that the description fails to provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing a baseline of 3, but the description adds no value beyond the schema—it merely repeats 'Update a scheduled task' without explaining parameter relationships or usage context. For a tool with 8 parameters, the description should clarify how parameters like 'name', 'command', 'frequency', and 'enabled' relate to updating a scheduled task, which is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Update' and the resource 'scheduled task for a Coolify service', with the '[WRITE]' prefix clearly indicating write semantics. It distinguishes from sibling tools like 'coolify_create_application_scheduled_task' and 'coolify_delete_application_scheduled_task' by focusing on update, but could be more specific about which aspects of the task can be updated beyond the schema parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus its siblings (create or delete scheduled tasks). The description does not mention prerequisites, such as requiring the service UUID and task UUID, nor does it differentiate from other update operations like 'coolify_update_application_scheduled_task' for applications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While the '[WRITE]' tag and verb 'Add' imply modification, the description does not disclose behavioral details like permissions required, whether the operation is reversible, or side effects on existing storage mounts. This leaves significant gaps for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the purpose. However, given the complexity of 8 parameters and the context of write operations, the description could be slightly more structured to include critical usage notes without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no annotations, no output schema, and the need to distinguish between persistent and file storage types, the single-sentence description is insufficient. It does not explain conditional parameter dependencies (e.g., 'content' for file, 'fs_path' for directory) or return behavior, leaving the agent under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for each parameter (e.g., 'Volume name (required for persistent storages)', 'Storage type: persistent volume or file mount'). However, the description does not add further meaning beyond what the schema provides. Since baseline is 3 for high coverage, this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('a persistent or file storage mount to a Coolify database'). It distinguishes this from sibling tools like 'coolify_list_database_storages' and 'coolify_delete_database_storage' by focusing on creation. The '[WRITE]' tag further indicates it is a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives, such as when to create a persistent volume versus a file mount, or prerequisites like ensuring the database exists. It also does not mention exclusions or related tools for managing storage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 includes a '[DESTRUCTIVE]' tag, which hints at the operation's nature, but it does not disclose whether the operation is irreversible, what happens to the database, or that confirmation is required. The confirm parameter is present in the schema but not mentioned in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence, which is good for front-loading. However, it lacks structure and does not use the available space to add useful information. It is not overly verbose, but it is too sparse to be considered well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and many sibling tools, the description is incomplete. It does not explain the return value, how to interpret the confirmation parameter, or how this tool differs from similar ones like coolify_delete_env. The context signals suggest a need for more detail, but the description provides only a single line.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides. For example, it does not explain the purpose of each parameter or provide context for their values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete an environment variable from a Coolify database'. It uses a specific verb and resource, and the mention of 'from a Coolify database' distinguishes it from sibling tools like coolify_delete_env (which might delete from other contexts). However, it does not elaborate on the exact inputs or scope, which could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. For example, there is no mention of prerequisites (e.g., needing the database UUID and env UUID), when to prefer this over coolify_update_database_envs_bulk, or when not to use it. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'list', implying a read operation, but does not disclose any behavioral traits such as permission requirements, pagination, rate limits, or what happens if the database does not exist. The description adds minimal value beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, which is concise but lacks substance. Every word earns its place, but the brevity sacrifices useful information. It could be expanded slightly to improve clarity without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description does not hint at what the response contains (e.g., fields like name, mount path, size). No annotations are provided. For a simple list tool, the description is incomplete; the agent would need to infer or inspect the API to understand the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'uuid' parameter is fully described in the schema). The description does not add any additional meaning or context about the parameter beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (persistent and file storages for a Coolify database). It distinguishes this tool from siblings like 'coolify_list_databases' (which lists databases) and 'coolify_list_database_backups' (which lists backups) by specifying 'storages'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'coolify_list_application_storages' or 'coolify_list_service_storages'. The context of database-specific storage is implied but not stated as a selection criterion. No when-not-to-use examples are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries full burden for behavioral disclosure. It only states '[WRITE]' to hint mutation but does not explain merge vs. overwrite behavior, required fields beyond uuid, side effects of instant_deploy, or what happens to omitted fields. This is insufficient for a complex 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (7 words including [WRITE]). While it wastes no words, it is underspecified for a tool with 17 parameters. Conciseness is achieved at the cost of completeness, making it minimally adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given high complexity (17 params, nested object, no output schema), the description is incomplete. It does not explain return values, behavior when only uuid is provided, or how instant_deploy interacts with other fields. The agent lacks essential context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 17 parameters, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides (e.g., it doesn't explain how custom_fields override or supplement other fields). The agent must rely solely on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('configuration of a Coolify application'), and the [WRITE] prefix indicates mutation. However, it does not differentiate from siblings like coolify_create_application or coolify_delete_application, leaving ambiguity for the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs. alternatives. It does not specify prerequisites (e.g., application must exist), when to prefer create over update, or mention that instant_deploy triggers a deployment. The description is silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only says 'Update configuration' without revealing side effects (e.g., service restart, downtime), idempotency, or required permissions. This is insufficient for an agent to understand the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is so minimal that it does not fully earn its place. It front-loads '[WRITE]' as a verb hint, but the overall lack of informative content makes it less effective than a more detailed but still concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters (including a nested object and a raw string field), no output schema, and no annotations, the description is severely lacking. It does not explain what happens after updating, how fields interact, or what the agent should expect in return. The description is inadequate for an agent to use this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond the parameter names and brief schema descriptions. For example, it doesn't explain how 'custom_fields' works or the relationship between 'docker_compose_raw' and other fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and identifies the resource ('configuration of a Coolify service'). It distinguishes from sibling tools that update other resources (applications, databases, etc.) by the resource type. However, it does not specify what aspects of configuration are updateable, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like coolify_update_application or coolify_update_database. The description simply states what it does without context on prerequisites, state requirements, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It mentions the operation is a WRITE (though the tag may be part of the overall description, it's helpful) and notes the version requirement. However, it fails to mention what happens upon failure or success, whether the operation is destructive (e.g., if it restarts Docker), what side effects exist, or what permissions are needed. The description partially covers the mutation aspect but is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. It front-loads the purpose and includes a key version constraint. However, the format is somewhat informal with brackets around 'WRITE', and it could be more structured or include more information without becoming verbose. It earns its place but leaves room for more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and no annotations, the description is incomplete. It doesn't explain what a successful or failed validation looks like, whether the 'install' parameter has side effects (e.g., restarting Docker as hinted in the schema), or how to interpret the results. For a validation operation, an agent needs to know what outputs to expect and what constitutes success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 both parameters ('uuid' and 'install'). The description does not add additional context for the parameters—e.g., it doesn't explain the relationship between the install flag and the check for Docker prerequisites. The baseline of 3 is appropriate since the schema covers the parameters, but the description contributes no extra meaning beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose clearly: validating a Coolify server by checking SSH connectivity and Docker prerequisites. The verb 'validate' combined with the specific resources ('SSH connectivity and Docker prerequisites') makes the action well-defined. However, it doesn't explicitly differentiate it from the many sibling tools that also start with 'coolify', though the name 'validate_server' is fairly unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives. While the WRITE tag indicates it's a write operation, and the version requirement 'v4.2+' is helpful, there are no exclusions, no mention of prerequisites or dependencies, and no comparison to sibling tools like 'coolify_get_server' or 'coolify_update_server'. An agent has no context on whether validation is needed before deployment or other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description does not state whether the operation is reversible, what side effects occur (e.g., if a queued deployment is removed entirely), or whether any confirmation or rollback is possible. The only hint is the "[WRITE]" prefix indicating mutation, but deeper behaviors remain opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at a single phrase. However, the "[WRITE]" prefix is a useful semantic marker that adds structure without redundancy. Every element earns its place. It could be slightly more informative while remaining concise, but as it stands it is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description is minimal but adequate for basic invocation. However, it fails to explain important context like what happens after cancellation, whether the operation is synchronous or asynchronous, or how to verify the result. For a cancellation tool, these details matter for an AI agent's execution confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'uuid', including a description that says "UUID of the deployment to cancel". The description does not add any additional meaning beyond what the schema already provides, such as how to obtain the UUID or any format constraints. Given full schema coverage, the baseline is 3, and the description does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with "[WRITE]" to signal the operation type, and then uses a specific verb and resource: "Cancel a running or queued deployment". This clearly states what the tool does and distinguishes it from other deployment tools like coolify_trigger_deploy or coolify_get_deployment. However, it does not explicitly differentiate from coolify_restart_application (which also affects running state), but the resource is clearly deployments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention prerequisites (e.g., needing the deployment UUID from a tool like coolify_list_deployments) or constraints (e.g., only works on running or queued deployments). Without such guidance, an AI agent may attempt to cancel a deployment that has already completed or fail to understand the required input context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'create a new application,' but does not disclose that this is a write operation with potential side effects (e.g., creating resources, possibly triggering deploys), nor does it mention any rate limits, authorization requirements, or whether actions are reversible. The description does not contradict annotations (since none exist), but it provides minimal transparency about the operation's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line, which is concise, but it is too sparse. It conveys the primary purpose but misses opportunities to outline key aspects of usage, such as referencing the need for prerequisite UUIDs or the variety of source types. The brevity is appropriate for a simple reading, but it lacks the informative structure that would make it truly effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 18 parameters and no output schema, and the description does not elaborate on what the creation involves or what the agent should expect in response (e.g., the created application's UUID). The schema documents parameters well, but the description provides no additional context about how the creation process works, potential side effects, or post-creation steps (like deployment). Given the tool's complexity, the description is insufficiently complete to guide an agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all 18 parameters, meaning every parameter has a description. The overall description only mentions 'various sources,' which adds little beyond the schema. Given full schema coverage, a baseline of 3 applies, and the description does not enhance parameter understanding beyond what the schema already provides. No extra context is given for complex parameters like custom_fields or the conditional requirements based on source_type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to create a new Coolify application, using the [WRITE] marker to indicate a write operation. It mentions 'from various sources,' which hints at the multiple source types, providing some differentiation from sibling tools like coolify_list_applications or coolify_update_application. However, it does not explicitly list the source types in the description, requiring the agent to inspect the schema for specifics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives (e.g., coolify_create_database for databases, or coolify_update_application for modifications). It also does not mention prerequisites such as needing an existing project, server, or environment UUIDs. The absence of any usage context beyond the basic 'create' operation fails to help the agent decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only indicates it is a write operation via '[WRITE]' and 'Create'. Missing details: idempotency, side effects, error behavior, or what happens on duplicate names or invalid inputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence. While efficient, it lacks structure like front-loading key context (e.g., mutation type). It earns its place but could benefit from slight expansion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters (4 required) and no output schema or annotations, the description is incomplete. It does not explain return values, prerequisites (e.g., application must exist), or validation details for parameters like 'frequency' or 'timeout'. Significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents each parameter (e.g., 'name', 'frequency'). The tool description adds no extra meaning beyond the schema. Baseline 3 is appropriate as the description does not compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for creating a scheduled task for a Coolify application. It includes a '[WRITE]' hint for mutation type and the verb 'Create' along with the resource 'scheduled task'. It distinguishes from sibling tools like 'coolify_create_service_scheduled_task' by specifying 'application'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., updating or deleting scheduled tasks, or creating service scheduled tasks). No prerequisites or conditions are mentioned, leaving the agent to infer usage context entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 '[WRITE]' indicating a mutation, but does not describe what happens after creation (e.g., whether it's automatically activated, or if it triggers any side effects). The description lacks details on permissions, idempotency, or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the '[WRITE]' marker. Every word is necessary, but it could be slightly more descriptive without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 required parameters, no output schema, and no annotations, the description is too sparse. It does not explain the response format, potential errors, or the relationship between environments and projects. The low complexity is offset by the lack of behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described in the schema (100% coverage), so the baseline is 3. The description does not add any additional meaning beyond what the schema already provides. The schema documents 'name' as 'Environment name (e.g. 'staging', 'production')' and 'project_uuid' as 'UUID of the project', which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '[WRITE]' to indicate a mutation, and clearly states 'Create a new environment in a Coolify project'. The verb 'create' and resource 'environment' are specific. However, it does not differentiate from sibling tools like 'coolify_create_project' or 'coolify_create_application', which also create resources, but the target resource is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites (e.g., project must exist) or when not to use it. Siblings like 'coolify_list_environments' or 'coolify_get_environment' are not referenced for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states 'create' but does not mention if the operation is irreversible, requires special permissions, or has side effects like API rate limits. For a write operation, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is brief and front-loaded. It does not waste words, but could be improved with a bit more detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the tool has only one required parameter, so completeness is partially covered. However, the description does not explain what happens after creation (e.g., does it return an app ID?), and the nested object (custom_fields) may confuse agents without further guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents both parameters. The description adds no additional meaning beyond what the schema provides, such as how the 'name' might be validated or what 'custom_fields' typically expects. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool creates a new GitHub App integration in Coolify, which is clear for a single purpose. However, it does not differentiate from sibling tools like coolify_update_github_app or coolify_delete_github_app, which is a minor gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as creating a GitHub App via the Coolify UI or using other integration tools. No prerequisites or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. The [WRITE] marker implies mutation, but the description does not disclose whether the operation is idempotent, what gets overwritten or destroyed on conflict, whether it requires specific permissions, or what side effects occur (e.g., restarting the service). This is a significant gap for a write tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It is front-loaded with the [WRITE] marker, making the action clear. No unnecessary words, but it could be slightly expanded with behavioral details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count of 9, the lack of annotations, and no output schema, the description is incomplete. It does not explain how the two storage types differ in behavior, what the response looks like, or error handling. For a service sub-resource creation tool with many similar siblings, more contextual completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The description adds minimal semantic value beyond the title and brief phrase. The baseline of 3 applies because the schema does the heavy lifting, but the description could provide more context, such as the relationship between parameters (e.g., when is_directory requires fs_path).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description includes a [WRITE] marker and specifies the verb 'Add' with the resource 'persistent or file storage mount to a Coolify service sub-resource'. This clearly distinguishes it from siblings like coolify_delete_service_storage, coolify_list_service_storages, and coolify_update_service_storage, but does not explicitly differentiate it from coolify_create_application_storage or coolify_create_database_storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other storage creation tools (e.g., for applications vs. databases vs. services). The description does not mention prerequisites such as having a valid service UUID and resource UUID, or when to choose persistent vs. file storage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes the tag '[DESTRUCTIVE]' but provides no additional context about the destructive nature, such as irreversibility, impact on dependent records, or permission requirements. With no annotations provided, the description carries the full burden but fails to disclose more than what the tag implies. The presence of a 'confirm' parameter hints at a confirmation step, but the description doesn't explain its necessity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point. It front-loads the important information (destructive tag, verb, resource). No filler or redundancy. It earns a 4 because it is efficient, though it could be slightly more structured to include usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, output schema, or nested objects, the description is under-specified. It doesn't explain the confirmation parameter's role, the irreversible nature, or how to correctly obtain the necessary UUIDs. With 4 parameters and one being a required confirmation, this needs more context to guide correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all parameters with high coverage (100%), so the description doesn't need to add much. However, the schema descriptions are minimal (e.g., 'UUID of the database') and the description adds nothing about the relationships between parameters (e.g., that execution_uuid belongs to backup_uuid). The baseline of 3 is appropriate since schema coverage is high and the description provides no extra parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a specific backup execution record' which clearly identifies the action (delete) and the resource (backup execution record). While it doesn't explicitly distinguish from sibling tools like coolify_delete_database_backup, the naming and description are clear enough. A score of 4 is appropriate as it lacks explicit differentiation from potentially similar deletion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, or any prerequisites or context. It only states the action without mention of required identification details or confirmation step. There is no mention of avoiding use or alternative tools, leaving the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly marks the tool as [DESTRUCTIVE] and requires environment emptiness, but does not disclose other behaviors like whether the operation is irreversible, if it affects dependent resources, or any permission/authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded with key information: it states the destructive nature, the resource type, the target, and the precondition. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is destructive and has 3 parameters (including a confirm flag), the description should explain when to set confirm, potential return values, or error states (e.g., what happens if the environment is not empty). Without an output schema, the description must compensate but does not. It is underspecified for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; for example, it does not explain the difference between environment_name and environment_uuid, nor that 'confirm' is required for destruction. The description adds no parameter-specific context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it deletes an environment from a Coolify project, with a clear precondition ('must be empty'). The name 'coolify_delete_environment' is descriptive and distinct from siblings like 'coolify_delete_project' and 'coolify_delete_application'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a precondition ('environment must be empty') but does not guide when to use this tool vs. alternatives like updating an environment or listing environments first to verify emptiness. No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'retrieve logs' with filtering, but does not describe read-only nature, side effects, pagination, rate limits, or truncation behavior. The schema's 'tail' and 'limit' parameters hint at behavior, but the description adds no explicit 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 18-word sentence that front-loads the action and resource, then lists filtering options concisely. It is efficient with no wasted words, though it could briefly mention the required 'uuid' parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and no annotations, the description is inadequate. It does not indicate what the returned logs look like (e.g., array of objects, timestamps, structure), nor does it cover potential edge cases like empty results or error conditions. The filtering options are listed, but the overall behavior is underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description summarizes 'filtering by level, time range, or text search', which provides a high-level grouping but no additional semantic meaning beyond the schema descriptions. It does not explain parameter interactions or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses 'Retrieve logs for a Coolify application' which is a specific verb-resource combination. The tool name and context distinguish it from sibling log tools (get_database_logs, get_service_logs), but the description does not explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools (e.g., database logs, service logs) or alternative tools like deployment logs. It does not mention prerequisites (e.g., UUID ownership) 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. The description only says 'Get detailed information' but does not specify that this is a read-only operation, what exactly is returned, or if any side effects occur. It fails to disclose whether the operation is safe (non-destructive) or idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the tool's purpose without extraneous information. It is well-structured and easy to parse for an AI agent. However, it could be slightly more precise (e.g., 'a specific Coolify project' could be 'a Coolify project by UUID').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the sibling tools and the lack of an output schema, the description is insufficient. It does not hint at the structure of the returned information (e.g., project name, environments, status) or how this tool integrates with other project-related tools. The agent may need to infer too much about the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with a detailed field description. The description adds no additional meaning about the 'uuid' parameter beyond what the schema provides. Baseline score of 3 is appropriate since the schema already handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('detailed information about a specific Coolify project'). It effectively distinguishes this tool from siblings like 'coolify_list_projects' (which lists projects) and 'coolify_update_project' (which modifies). However, it does not explicitly contrast with these siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'coolify_list_projects' or 'coolify_get_application'. The description also lacks any prerequisites or context about permissions or the relationship between project UUID and other resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states 'Get detailed information' with no mention of read-only semantics, error handling, authentication requirements, or rate limits. For a get operation, the safety profile is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It is front-loaded with the verb and resource. However, it could benefit from a bit more structure or additional context without becoming verbose. It is not wasteful, but it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should hint at what 'detailed information' includes. Without that, the agent cannot fully understand what data will be returned. Given the tool's simplicity (one parameter), the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage (one parameter, uuid, fully described with type, pattern, and constraints). The description adds no additional meaning beyond the schema, which is acceptable since the schema is complete. Baseline 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and the resource ('a specific Coolify service'). It distinguishes from sibling tools by specifying 'service' rather than applications, databases, etc., though it does not explicitly contrast with other 'get' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The sibling list includes many similar 'get' tools (e.g., coolify_get_application, coolify_get_database), but the description offers no criteria for selection or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states that the tool lists storages but doesn't mention whether it is read-only, what permissions are needed, how pagination or rate limits work, or whether the tool returns a list or single items. The word 'list' implies a read operation, but without annotations to confirm this, the description is insufficient for a safe agent decision.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 9 words in a single sentence, conveying the core action. It front-loads the verb 'List' and the resource, which is good. However, it could be slightly more efficient by removing 'persistent and file' if that is redundant or implied by 'storages', but it's clear and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (single parameter, no output schema), the description is too brief. The tool has a critical sibling 'coolify_delete_application_storage' that suggests storage management is more involved, but the description doesn't hint at the tool's return format, whether it returns a list or array, or any edge cases. With no output schema, the description should provide more context about expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single required parameter 'uuid' documented as 'UUID of the application'. This baseline 3 is appropriate because the schema already fully describes the parameter, and the description adds no further semantics (e.g., where to find the UUID, format hints, or validation constraints). The description does not go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List persistent and file storages for a Coolify application' – it uses the verb 'List', specifies the resource 'storages', and distinguishes it from sibling 'list_*' tools by targeting a specific resource type. However, it could be more precise by stating 'all' or 'the' to confirm scope, and it doesn't differentiate from closely related storage tools like 'coolify_list_database_storages' or 'coolify_list_service_storages' 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.
Usage Guidelines2/5
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. Among siblings, there are list storage tools for databases and services, but the description doesn't mention when an agent should choose this application-specific tool over those. There's also no mention of prerequisites, such as the application needing to exist, or what the tool returns if no storages are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states 'List branches' without disclosing potential side effects, rate limits, authentication requirements, or return format. For a read operation, the description is too minimal to inform an agent of behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately concise for a simple list operation. However, it lacks front-loading of key information such as the required parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema, no annotations), the description is minimally complete. It states the purpose but omits return value details, potential errors, and prerequisites. For a list operation, an agent might infer the response, but more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 each parameter adequately. The description does not add any additional meaning beyond what the schema provides. A baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list branches) and the resource (repository accessible by a GitHub App). It distinguishes from sibling tools like coolify_list_github_app_repositories by specifying branches rather than repositories. However, it could be more explicit about the repository being specified by owner and repo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives such as coolify_list_github_app_repositories. There is no mention of prerequisites, context, or when this tool is appropriate versus other list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 does not state whether this is a read-only operation (implied by 'List'), any rate limits, pagination behavior, or ordering of results. The description only restates the purpose without adding behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is appropriately sized for a simple list tool and front-loads the action ('List') and target ('executions of a scheduled task').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 required parameters, no output schema, and no annotations, the description is too minimal. It does not explain the result format, whether filtering or sorting is supported, or how to interpret the execution data. The sibling tools include many similar list operations, and the description fails to help an agent understand unique constraints or usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides for the two parameters (uuid and task_uuid). It does not explain how to obtain these UUIDs or specify their source (e.g., from the service or task list tools).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists executions of a scheduled task for a service, using a specific verb ('List') and resource ('executions of a scheduled task for a Coolify service'). It effectively distinguishes from sibling tools like 'coolify_list_service_scheduled_tasks' which lists tasks, not executions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. While it is clear what it does, there is no mention of prerequisites (e.g., needing a service UUID and task UUID), no context about the relationship to other list tools, and no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'run an on-demand backup', which implies mutation but doesn't explain side effects, idempotency, asynchronicity, or authorization requirements. The '[WRITE]' prefix is not part of the description and is not a substitute for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action type ('[WRITE]'). It is efficient and avoids unnecessary words. However, it could include more context without being verbose, so not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 required parameters, no output schema, and no annotations, the description should provide more context about the backup process, what happens after invocation, and any success indicators. It fails to explain return values, potential errors, or the effect of the backup. This is inadequate for a potentially impactful operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions in the schema). The description adds no additional meaning beyond the parameter names and their schema descriptions. It does not explain how to obtain the UUIDs or what 'storage' refers to. Baseline score of 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Run an on-demand backup for an application storage'. The verb 'run' and resource 'application storage backup' are specific. It distinguishes from siblings like 'coolify_set_application_storage_backup' (which likely schedules backups) and 'coolify_run_database_storage_backup' (database vs application), though it doesn't explicitly call out the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives (e.g., set vs run, or database vs application). There is no mention of prerequisites, such as needing the application to be running or having a storage configured. The description is purely declarative with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 only states it is a write operation ('[WRITE]') but does not disclose whether the backup is synchronous, how long it might take, what resources are affected, or whether it requires specific permissions. Critical behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and includes the [WRITE] prefix. It wastes no words, but it could be slightly more structured without adding length. It earns points for being efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and many sibling tools, the description should explain what an 'on-demand backup' entails, how it differs from scheduled backups, and what the agent can expect after execution. It fails to provide this context, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters having descriptions ('UUID of the database', 'UUID of the storage'). The tool description adds no additional meaning beyond the schema. Baseline is 3, and the description does not improve on it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run an on-demand backup') and the resource ('database storage'). The [WRITE] prefix signals it's a write operation. This distinguishes it from sibling tools like 'coolify_list_database_backups' and 'coolify_create_database_backup', which involve listing or scheduling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'coolify_create_database_backup' (which might set up recurring backups) or 'coolify_run_application_storage_backup'. There is no mention of prerequisites, preconditions, or when to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The '[WRITE]' tag indicates a mutation, but it does not explain what the update entails (e.g., partial vs. full replacement), side effects, idempotency, or required preconditions (e.g., the task must exist). This is insufficient for a write operation with 8 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the action. It includes a '[WRITE]' tag that is somewhat redundant but not harmful. It could be more informative without becoming verbose, but it earns points for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is too brief. It does not explain return values, error conditions, or how to use the parameters together. Sibling tools exist but no comparative guidance is provided. The tool is complex enough to warrant more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description, so the baseline is 3. The description adds no additional meaning beyond the schema, but the schema itself is sufficient for basic parameter understanding. The description does not clarify parameter relationships or usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update a scheduled task') and the resource ('Coolify application'), which is specific and distinguishes it from sibling tools like 'create' and 'delete' scheduled tasks. However, it does not elaborate on what aspects of the task can be updated, which could be slightly more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., create, delete, or the service scheduled task update). The description simply states the action without context, prerequisites, or exclusions, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 transparency. The description says '[WRITE]' but does not disclose whether updates are applied immediately or require a subsequent action, whether the operation is idempotent, or what happens to the existing backup schedule (e.g., does it overwrite or merge?). For a mutation tool, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the [WRITE] tag and action. It efficiently communicates the core purpose without extraneous words. Slightly more context could improve it without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, nested objects, no output schema) and no annotations, the description is too minimal. It does not explain the relationship between parameters like 'uuid', 'backup_uuid', or the effect of 'enabled'. The tool has many sibling tools for backups, and the description does not help an agent distinguish it from similar update tools. More detail on the expected behavior and dependencies is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond what the schema already provides. The schema itself describes each parameter adequately (e.g., 'Cron frequency for backups'), so the description does not need to repeat this. However, the schema includes a 'custom_fields' object for advanced use, which the description could clarify, but does not. Overall, no additional value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and the resource (database backup schedule configuration). The [WRITE] tag immediately signals a mutation operation, helping distinguish from read-only tools like coolify_list_database_backups. However, it could more explicitly differentiate from sibling tools like coolify_set_database_storage_backup or coolify_run_database_storage_backup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 coolify_set_database_storage_backup or coolify_create_database_backup. It does not mention prerequisites (e.g., needing the database and backup UUIDs) or when not to use it. The required parameters and schema are present, but the description itself offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states '[WRITE]' and 'creates or updates', but fails to disclose idempotency, overwrite behavior, side effects like redeployment, permission needs, or rate limits. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 18-word sentence with a verb prefix. It is concise and front-loaded, though blending the create/update note in parentheses is slightly less clean. Efficient but not perfectly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a bulk update operation, the description should mention what the response contains, whether an application restart is triggered, and any limitations. It provides none of this context, leaving the agent underinformed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the nuance 'creates or updates' beyond the schema's 'Array of environment variables to set'. However, it does not explain optional sub-fields like comment, is_literal, etc. Adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Bulk update' and the resource 'environment variables for a Coolify application', and clarifies it also creates if not existing. It distinguishes from single env tools and database/service bulk tools in the sibling list, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives like coolify_create_env (single) or the database/service bulk variants. The agent receives no context about preferred scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. The description labels the operation as '[WRITE]', implying mutation, but fails to disclose permissions required, side effects, reversibility, idempotency, or response behavior. The custom_fields parameter also hints at advanced behavior that is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (one short sentence with a prefix tag) and front-loaded with the action and resource. However, it is under-specified for a mutation tool with nested parameters, so conciseness borders on insufficient completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (including a nested object), no output schema, and no annotations, the description should provide more context about return values, failure modes, or usage examples. The current text leaves an agent guessing about the outcome and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no further detail about the parameters beyond the schema's own brief descriptions (e.g., 'ID of the GitHub App', 'GitHub App name', 'Additional fields not listed above (advanced)'). It does not clarify how custom_fields interacts with the other parameters, but the schema is self-sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states '[WRITE] Update a GitHub App integration in Coolify', which clearly indicates the verb (update), resource (GitHub App integration), and system (Coolify). This distinguishes it from siblings like coolify_create_github_app and coolify_delete_github_app, but could be more specific about what aspects of the integration can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Given siblings like coolify_update_application or coolify_update_github_app likely targets different resource types, the description does not clarify or offer any context on prerequisites, success conditions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only adds '[WRITE]' which hints at mutation. It does not explain whether the update replaces the entire key, merges fields, or any side effects, leaving the agent underinformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence with a front-loaded '[WRITE]' prefix. However, for a tool with four parameters, more context could be added without bloat; the space is not fully utilized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool modifies an SSH private key with four parameters and no output schema, the description lacks essential context such as which fields are updatable, that uuid is required, and the implications of updating the key. It feels incomplete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 four parameters sufficiently. The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing SSH private key, specifying the verb 'Update' and the resource. It distinguishes from siblings like create or delete by implication, but does not explicitly call out those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 creating a new key or deleting one. No prerequisites or context are provided, leaving the agent to 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states 'Create a backup' without revealing whether the operation is synchronous, whether it triggers a background job, what permissions are needed, or what the return value is. This is severely insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no redundant words. Every word serves a purpose, and the '[WRITE]' prefix provides a quick action hint. No improvement is needed in terms of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has only one parameter and no output schema, the description fails to provide essential context such as the nature of the backup (e.g., immediate vs. scheduled), the expected response, or how it differs from other backup creation tools like 'coolify_run_database_storage_backup'. The description is too minimal to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the 'uuid' parameter. The description adds no additional meaning beyond what the schema already provides, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a backup') and the resource ('a Coolify database'). It uses a specific verb+resource pattern and, given the sibling tools, it distinguishes itself from related backup tools like 'coolify_list_database_backups' and 'coolify_set_database_storage_backup' by focusing on creating a backup of a database entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as 'coolify_set_database_storage_backup' or 'coolify_run_database_storage_backup'. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full responsibility. It accurately indicates a write operation via '[WRITE]' and 'Create'. However, it does not disclose what happens upon successful creation (e.g., return value), whether duplicate tasks are rejected, or if specific authorization is needed. The behavioral context is basic but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise line, which is efficient for a simple mutation. However, it lacks structure—no introduction, no sections for parameters or return values. The '[WRITE]' prefix is a useful signal but is inconsistent with sibling tools that do not use such prefixes. At 7 parameters and no output schema, the description is too terse to be fully effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is under-specified given that there are 7 parameters, no output schema, and no annotations. It does not explain the creation process, success responses, error cases, or required permissions. A user would need to inspect the schema and trial-and-error to understand behavior. For a tool of this complexity, the description should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 7 parameters have descriptions in the schema. However, the tool description itself adds no parameter-level information beyond what the schema already provides. It does not explain relationships between parameters (e.g., that 'frequency' expects a cron expression, or the interplay between 'enabled' and 'timeout'). With no output schema, the description misses an opportunity to clarify parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a scheduled task for a Coolify service', specifying the verb (create) and the resource (scheduled task). The '[WRITE]' prefix signals the mutation nature. While it distinguishes from sibling tools like 'list_service_scheduled_tasks' and 'delete_service_scheduled_task', it could more explicitly contrast with 'update_service_scheduled_task' to justify when to create vs update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates this is for creating new tasks, but provides no guidance on when to use this tool vs. updating an existing task, what prerequisites are needed (e.g., service must exist), or conditions under which creation would fail. There is no explicit mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only labels the operation as '[DESTRUCTIVE]' and states it deletes a configuration. It does not disclose that the 'confirm' parameter must be set to true, that the default behavior does not delete S3 files unless 'delete_s3' is true, or any consequences of deletion. The transparency is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a '[DESTRUCTIVE]' prefix, which is concise. However, it is under-specified and lacks any structure or additional context. It could be improved without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, is destructive, and has no output schema, the description is incomplete. It does not mention prerequisites (e.g., listing backups first), the requirement to set 'confirm' to true, or what the return value indicates. The description fails to cover key contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the parameter names and types already documented in the schema. It does not explain the role of 'confirm' or 'delete_s3' in the context of deletion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'scheduled backup configuration for a Coolify database'. It distinguishes from sibling tools like 'coolify_delete_backup_execution' (which deletes executions) and 'coolify_delete_database' (which deletes the database itself). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. It does not mention that this tool deletes the configuration (not the execution) or that it requires a confirmation parameter. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks important behavioral details. Since no annotations are provided, it does not disclose whether this is a destructive or reversible action, whether it requires specific permissions, what happens if storage already exists, or if the action can fail. The tag '[WRITE]' is present in the description, hinting at mutation, but this is not formalized. The description does not add meaningful behavioral context beyond what the tool name and schema imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the action and scope. It uses '[WRITE]' to signal the operation type. At 14 words, it is concise without being cryptic. The structure is optimal for quick scanning, though it could also briefly mention prerequisites without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8 parameters, 100% schema coverage, and no output schema, the description provides a basic orientation but is not fully complete. Important contextual details are missing: what constitutes a successful invocation (e.g., created storage object details, idempotency, error states), and preconditions (application must exist, user must have appropriate permissions). The sibling tools list includes many similar 'create_storage' tools, so better differentiation would improve completeness. A 3 reflects that while the description pairs well with the schema, an agent would need to infer or test critical behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100% with clear parameter descriptions, so the schema itself is strong. However, the description adds value by summarizing the two storage types ('persistent' or 'file') and hinting at their implications (e.g., 'name' required for persistent, 'content' for file). This helps an agent understand the conditional requirements without parsing all schema details. The description effectively bridges the schema's individual constraints into a coherent usage story.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action is to add storage (persistent or file mount) to a Coolify application. It distinguishes this from sibling tools like `coolify_delete_application_storage`, `coolify_update_application_storage`, and `coolify_list_application_storages` by using the verb 'Create' and specifying 'add'. However, it doesn't differentiate from `coolify_create_database_storage` or `coolify_create_service_storage` beyond the resource type implied in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No prerequisites, constraints, or when-not-to-use scenarios are mentioned. For example, an agent would need to know that the application must exist, or that `uuid` must be from a prior `coolify_get_application` or `coolify_list_applications` call. The description is silent on these practical usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It only includes a '[WRITE]' tag implying mutation but does not describe what happens on success (e.g., returns the created variable?), error conditions, idempotency (does it overwrite existing keys?), or authentication/rate-limit considerations. The behavioral information 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a '[WRITE]' tag, making it very concise. However, it lacks structure (e.g., no separate sections or additional details). While it is not verbose, a few more words could improve clarity without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no output schema, and is a mutation operation. The description only says 'Create a new environment variable for a Coolify database' without explaining return values, error scenarios, or any side effects. Given the complexity (multiple boolean flags, optional comment), this is notably incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any additional meaning beyond the schema; it merely restates the overall action. The schema already fully describes each parameter with names, types, and descriptions. The description adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('environment variable for a Coolify database'), and the '[WRITE]' prefix further clarifies it's a mutating operation. It distinguishes itself from sibling tools like coolify_delete_database_env (delete), coolify_update_database_envs_bulk (bulk update), and coolify_create_env (generic env creation) by specifying it's database-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like coolify_create_env or coolify_create_service_env. It does not mention prerequisites (e.g., needing a database UUID), nor does it explain when not to use it. The description lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 traits. The description only states 'Create a new environment variable' but does not disclose what happens if a variable with the same key already exists (overwrite, error, or skip), whether the operation is idempotent, or any authorization requirements. The '[WRITE]' tag is redundant with 'Create'. For a mutation tool, this lack of behavioral detail 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action. It is concise and avoids fluff. However, the '[WRITE]' prefix is redundant because 'Create' already implies a write operation. Still, it is appropriately sized for a straightforward tool, earning a 4 rather than a 5 due to the slight redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters (3 required), no output schema, and no annotations, the description is incomplete. It does not explain the tool's behavior regarding duplicates, the effect of boolean flags (is_literal, is_preview, etc.) beyond the schema, or what the return value is. The presence of many related env sibling tools (create/update/delete for apps, databases, services) calls for more context to prevent misuse, but the description provides none.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter has a meaningful description (e.g., 'key' says 'Variable name (e.g. DATABASE_URL)', 'uuid' says 'UUID of the application'). The tool description adds no additional meaning beyond the schema. With high schema coverage, the baseline is 3; the description does not elevate it further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 environment variable') and the resource ('for a Coolify application'). The '[WRITE]' prefix reinforces the action. This distinguishes it from sibling tools like coolify_list_envs (list), coolify_update_envs_bulk (update bulk), coolify_delete_env (delete), and coolify_create_database_env (creates for database, not application). The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives (e.g., coolify_create_database_env, coolify_create_service_env). It does not mention that this tool is specifically for application environment variables, nor does it provide prerequisites, exclusions, or context for when it should be chosen over other env creation tools. The agent must infer from the tool name and siblings, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly marks the tool as '[DESTRUCTIVE]', which is helpful for behavioral transparency. With no annotations provided, this is a positive disclosure. However, it does not explain what happens after deletion (e.g., whether it's permanent, if confirmation is required, or if it affects running databases). The presence of a 'confirm' parameter is implied by the behavior but not explicitly stated in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that takes about 15 words to convey the core purpose. The '[DESTRUCTIVE]' tag at the start provides immediate warning. It is front-loaded and to the point. While it could include a bit more guidance, it does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should compensate by explaining what the tool returns upon success or failure (e.g., confirmation message, error if storage not found). It also lacks any mention of error states, idempotency (e.g., deleting already-deleted storage), or dependencies (e.g., backup relationships). For a destructive tool with no annotations or output schema, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adequately. The description adds no additional meaning beyond the schema's parameter descriptions. The tool name and description implicitly clarify that 'uuid' is the database's UUID and 'storage_uuid' is the storage to delete, but 'confirm' is only documented in the schema. With full schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Remove'), resource ('persistent or file storage mount'), and target ('from a Coolify database'). It distinguishes itself from sibling tools like `coolify_delete_application_storage`, `coolify_delete_service_storage`, and `coolify_delete_database_storage_backup` by specifying it targets database storage mounts. However, it could be more precise by noting it deletes a specific storage UUID rather than all storage for a database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Among siblings, `coolify_list_database_storages` lists available storages, `coolify_create_database_storage` creates them, and `coolify_update_database_storage` modifies them, but no mention is made of prerequisites (e.g., listing storages first to get the storage_uuid) or when not to use it (e.g., if storage is in use by backups). The description assumes the agent already knows the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only says 'Get detailed information' but does not specify what details are returned (e.g., status, logs, timestamps), nor mention side effects, permissions, or rate limits. For a read operation, this is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no waste. Could be slightly more structured (e.g., list expected output), but overall efficient for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not explain what 'detailed information' includes. With sibling tools like coolify_list_deployments, it would be helpful to clarify that this returns full details for a specific deployment UUID. Incomplete for a get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description 'UUID of the resource' is clear. The tool description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get detailed information about a specific deployment', using a specific verb ('Get') and resource ('deployment'). This distinguishes it from sibling tools like coolify_list_deployments (list) or coolify_trigger_deploy (action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., list deployments for overview, or cancel deployment for mutation). The description does not mention prerequisites, context, or that the UUID must come from a listing operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Get detailed information' without specifying what 'detailed information' includes, whether it's read-only, or any required permissions. The agent cannot infer the tool's safety profile or output characteristics from this minimal text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. It is appropriately short for a simple read tool, though it could be slightly more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and only one parameter, the description is insufficient. It does not explain the return format, what 'detailed information' entails, or how the output relates to other tools. The agent lacks context to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (1 parameter 'uuid' with description 'UUID of the resource'). The tool description adds no extra meaning beyond what the schema already provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('detailed information about a specific Coolify server'), clearly distinguishing it from sibling tools like 'coolify_list_servers' (which lists servers) and 'coolify_validate_server' (which validates). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Siblings include 'coolify_list_servers' for listing all servers, 'coolify_get_server_resources', and 'coolify_get_server_domains', but no criteria or prerequisites are given to help the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It only states the action but does not clarify if the operation is read-only, what constitutes a 'backup' (configuration vs. snapshots), whether authentication is required, or any side effects. This leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is appropriately succinct for a simple list operation, though it could be front-loaded with key behavioral notes if needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits what the response contains (e.g., backup IDs, timestamps, status) and does not mention pagination, ordering, or typical usage patterns. For a list tool without an output schema, this leaves the AI agent guessing about the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter 'uuid' is 100% with description 'UUID of the database'. The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List backups for a specific database' clearly states the action (list), the resource (backups), and the scope (specific database). It effectively distinguishes from siblings like 'coolify_list_backup_executions' (which lists backup runs) and various create/delete backup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'coolify_list_backup_executions' or how to pair it with 'coolify_create_database_backup' or 'coolify_delete_database_backup'. The description lacks usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action without mentioning that the tool is read-only, what happens if the ID is invalid, authentication requirements, rate limits, or pagination behavior. The description is too minimal for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and efficient. However, it could be slightly more informative without sacrificing conciseness, hence a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is inadequate. It does not explain what the tool returns (e.g., a list of repository names, URLs) or if any additional context is needed. An agent would lack information about the output format, which is critical for subsequent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'id' parameter has a description 'ID of the GitHub App' in the schema). The tool description adds no additional meaning beyond what the schema already provides except for clarifying that the tool lists repositories, which is implicit. With full coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List repositories accessible by a GitHub App' uses a specific verb ('List') and resource ('repositories accessible by a GitHub App'), clearly distinguishing it from sibling tools like 'coolify_list_github_apps' (which lists GitHub apps themselves) and 'coolify_list_github_app_branches' (which lists branches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as when to list all GitHub apps or branches. It does not mention prerequisites, context (e.g., needing the GitHub App ID beforehand), or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states 'Create or replace' and '[WRITE]', but does not explain what happens when a schedule already exists (does it overwrite?), whether the operation is idempotent, or any side effects (e.g., does it delete existing backups?). Critical behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence: '[WRITE] Create or replace a backup schedule for a service persistent volume/directory'. It is efficient and front-loaded with the action. However, it could be slightly more informative (e.g., mentioning the need for uuid and storage_uuid) without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain return values, error conditions, prerequisites (e.g., storage must exist), or how to use retention parameters. For a complex backup schedule tool, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, with 6 out of 15 parameters lacking descriptions. The tool description itself does not add any meaning beyond the schema; it does not explain relationships between parameters (e.g., save_s3 and s3_storage_uuid) or provide examples. With moderate schema coverage, the description adds no extra value, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create or replace'), the resource ('backup schedule'), and the scope ('for a service persistent volume/directory'). The [WRITE] prefix signals it's a mutation. Among siblings, it unambiguously targets service storage backups, differentiating from database/application storage backup tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 `coolify_run_service_storage_backup` (run a backup) or `coolify_delete_service_storage_backup` (delete a schedule). No prerequisites mentioned (e.g., storage must exist). The description simply states the action without context for choosing it over other storage backup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 disclosure. It only states 'Start' and '[WRITE]', which implies mutation but does not explain side effects (e.g., changing status, requiring permissions, or impact on deployments). The description is too brief to give an agent confidence about what happens.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (5 words plus a tag), but it is borderline under-specified. It is front-loaded with the tag but lacks necessary details. Every sentence is earned, but the overall length may leave gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 param, no output schema), the description is minimally adequate. It covers the core action but does not mention error conditions (e.g., what if the application is already running) or the return value. It is complete enough for a simple tool but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the uuid parameter already described. The description adds the context of starting an application but does not add meaning beyond the schema. Baseline 3 is appropriate per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Start' and the resource 'Coolify application', with the prefix '[WRITE]' indicating it's a write operation. It distinguishes itself from sibling tools like coolify_stop_application and coolify_restart_application by specifying it starts a stopped application.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., coolify_restart_application). No prerequisites or context about the application needing to exist or be stopped are provided. The description does not help the agent decide between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only indicates it's a write operation but omits critical details such as what happens if the service is already running, required permissions, or error responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short—one sentence with a clear prefix. It is front-loaded and contains no fluff, though it could be slightly more structured without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 1-parameter input and no output schema, the description is too minimal. It lacks context about when to prefer this tool over service vs application variants, and does not mention return behavior or side effects, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the parameter as 'UUID of the resource'. The description adds no additional meaning beyond that, so it achieves the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start') and the resource ('a stopped Coolify service'), distinguishing it from siblings like stop_service and restart_service. The '[WRITE]' prefix further clarifies the operation type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs similar tools like coolify_start_application or coolify_start_database. The description implies the service must be stopped but does not state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full behavioral burden. It only indicates a write operation via '[WRITE]' and mentions the PATCH body, but fails to disclose important details: idempotency, required permissions, side effects on unspecified fields, or behavior when changing the storage type (persistent vs file). The schema implies type-dependent parameters (e.g., content for file, host_path for persistent) but the description omits these conditional dynamics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a helpful [WRITE] prefix, making it short and front-loaded. However, it is slightly under-specified; adding a brief note about parameter dependencies would improve usability without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description should explain return values, errors, or conditional logic. It does none of these. For a mutation tool updating storage with type-specific requirements, the lack of pre-/post-conditions makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description 'persistent or file storage' and 'storage uuid + type' add minimal new meaning beyond the schema's parameter descriptions. It does not clarify the conditional usage of parameters or provide examples, so it barely meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates persistent or file storage for a Coolify application, specifying the HTTP method (PATCH) and required identifiers (storage uuid + type). This distinguishes it from sibling tools like coolify_create_application_storage and coolify_delete_application_storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 create/delete alternatives, nor any prerequisites like needing to list storages first to obtain the uuid. The description only states what the tool does, not in what context it should be chosen over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only notes that this is a write operation (via [WRITE]) and a PATCH request, but fails to describe side effects (e.g., data loss risk when changing storage type), authorization requirements, rate limits, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the operation type and resource. It is concise and contains no filler, though the parenthetical could be integrated more smoothly. Every part contributes to understanding the tool's core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what the tool returns, error scenarios, or how to handle the conditional nature of parameters based on storage type. Given the complexity and the large sibling set, the description leaves significant gaps for an agent to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema by noting that the PATCH body includes 'storage uuid + type', which reinforces the role of two required parameters. However, it does not clarify the conditional nature of parameters (e.g., 'name' and 'host_path' apply only to persistent type) or provide formatting hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'persistent or file storage for a Coolify database'. It also specifies the HTTP method (PATCH) and key body components (storage uuid + type), distinguishing it from sibling tools like create, delete, list and the general update_database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., create_database_storage, delete_database_storage, update_database). The verb 'Update' implies modifying existing storage, but the description does not mention prerequisites, exclusions, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It correctly signals the tool is a write/create operation via '[WRITE]', but does not disclose what happens upon success (e.g., returns a database UUID?), whether creation is synchronous or asynchronous, or what side effects occur (e.g., immediate deploy only if instant_deploy is true). The description adds some context beyond the schema but is insufficient for a tool with 14 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line), which is concise, but it omits important guidance. The '[WRITE]' prefix is a useful structural cue. However, the description could be slightly longer to include crucial context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (14 parameters, nested objects, no output schema), the description is somewhat complete but lacks essential details like return behavior, error scenarios, or how to effectively configure type_config for different database engines. It is adequate for an AI agent with strong schema knowledge but incomplete for autonomous decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter-specific meaning beyond what the schema already provides. It does not summarize which parameters are essential, how type_config works, or provide examples of valid combinations, all of which would add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '[WRITE] Create a new Coolify database', which uses a specific verb ('Create') and resource ('Coolify database'). It clearly identifies this as a write operation. Among siblings like coolify_list_databases (read) and coolify_get_database (read), this stands out as the only create operation for databases, but it lacks explicit distinction from other write siblings like coolify_create_database_backup or coolify_create_database_storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as when to use coolify_create_application for a full-stack app, or how to choose between creating a database directly versus using a service. It also omits prerequisites like needing a server_uuid and project_uuid, which are required but not explained in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states the creation action but does not explain side effects (e.g., behavior on duplicate name, key validation, persistence, or return value). The '[WRITE]' prefix adds minimal transparency. Critical behavioral traits such as error conditions or idempotency are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a useful '[WRITE]' prefix. Every word carries meaning and there is no redundancy. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema, no annotations), the description is insufficient. It does not explain expected return values, potential failure modes (e.g., duplicate name, invalid key format), or pre-conditions such as the key being unique. The agent lacks critical context to handle the tool robustly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context that the key is used for server/application authentication, which complements the schema parameter descriptions. However, it does not elaborate on specific parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('SSH private key') and its purpose ('for server/application authentication'). The '[WRITE]' prefix explicitly marks it as a write operation. It is distinct from sibling tools like 'coolify_update_private_key' and 'coolify_delete_private_key'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it does not mention that this is for adding a new key before associating it with a server, nor does it differentiate it from 'coolify_update_private_key' or 'coolify_delete_private_key'. No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 notes the action is destructive and permanent, but fails to explain critical requirements such as the mandatory 'confirm' parameter, the impact on volumes, or any irreversible side effects. Important behavioral traits are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. '[DESTRUCTIVE]' immediately signals severity, and the action is succinctly stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive operation with multiple boolean parameters (confirm, delete_volumes, docker_cleanup) and no output schema, the description is unduly brief. It does not explain the deletion process, safety checks, or what happens to associated resources, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all four parameters with descriptions. The description adds no additional semantic information about parameters beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Permanently delete a Coolify database', specifying the action (delete) and resource (database), and explicitly marks it as destructive. This distinguishes it from sibling tools like coolify_stop_database (temporary) and coolify_create_database (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as stopping or restarting the database, nor does it mention prerequisites like the need for a uuid or confirmation. It simply states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. While it marks the tool as [DESTRUCTIVE] and mentions it deletes 'the backup schedule and archives', it doesn't disclose whether this action is irreversible, what happens to in-progress backups, whether it requires specific permissions, or what the response looks like. The 'confirm' parameter in the schema hints that confirmation is needed, but the description doesn't explain that it must be set to true to proceed. The contradiction flag is false because there are no annotations to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately marks the tool as destructive with a bracket prefix. It front-loads the key warning. The sentence could be slightly improved by placing the [DESTRUCTIVE] label at the very beginning before 'Delete' for even clearer emphasis, and by adding a brief note about confirmation, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that parameters are fully covered in the schema, no output schema exists, and the tool is destructive, the description provides adequate but not comprehensive detail. It names the two deleted components (schedule and archives) and warns of destruction, but lacks behavioral context (irreversibility, prerequisites) and usage guidelines. For a destructive operation, more guidance is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all three parameters ('uuid', 'confirm', 'storage_uuid'). The description adds no additional semantic information beyond what's in the schema – it doesn't explain how the uuid and storage_uuid relate (e.g., that uuid is the database's UUID and storage_uuid is the storage's UUID, and both are needed to identify a specific backup schedule). It also doesn't clarify that 'confirm' must be true for the operation to succeed. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the specific resource: 'backup schedule and archives for a database storage'. This distinguishes it from siblings like 'coolify_delete_database_backup' (which likely deletes only a backup execution result) and 'coolify_delete_application_storage_backup'. However, it could be more precise by explicitly noting that this refers to the entire backup schedule, not just a single backup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives some context by labeling it [DESTRUCTIVE], implying it should be used with caution, but it provides no explicit when-to-use or when-not-to-use guidance. There's no mention of alternatives or prerequisites (e.g., that the database and storage must exist). The sibling tools list suggests there are other backup-related tools (like 'coolify_set_database_storage_backup', 'coolify_run_database_storage_backup', 'coolify_delete_database_backup'), but the description doesn't help the agent choose among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It includes the label '[DESTRUCTIVE]' and the schema has a 'confirm' parameter, both hinting at destructiveness. However, it does not explain side effects (e.g., whether deletion triggers a redeploy), permanence, or auth requirements. The label provides some transparency but lacks completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear action and a useful '[DESTRUCTIVE]' prefix. There is no redundant information, and every word contributes to understanding. It is ideally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no output schema and no annotations, the description is too sparse. It does not explain what happens after deletion, how to confirm, what the response looks like, or how the two required UUIDs relate to each other. The presence of the 'confirm' parameter is a key usage detail that the description omits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all parameters have descriptions), so baseline is 3. The tool description adds no extra meaning beyond what the schema already provides (e.g., it does not explain how to obtain the UUIDs or the role of 'confirm'). The schema is self-sufficient, so the description does not degrade but also does not enhance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete') and resource ('environment variable from a Coolify service'), making the core purpose clear. However, it does not differentiate this tool from sibling tools like 'coolify_delete_env' or 'coolify_delete_database_env', which 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.
Usage Guidelines2/5
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 (e.g., coolify_delete_env for applications, coolify_delete_database_env for databases). Prerequisites (e.g., having the service UUID and env_uuid) are not mentioned, and no when-not-to-use conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states it 'Get detailed information', which implies a safe, read-only operation. However, it does not disclose whether the operation requires specific permissions, what 'detailed information' encompasses (e.g., configuration, status, logs), whether it triggers side effects, or if there are rate limits. For a read tool without annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence of 10 words with no wasted language. It is efficient and front-loaded. However, it could be slightly improved by adding a line about UUID source or return value without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter, no output schema, and no annotations, the description provides minimal but sufficient context for a simple retrieval operation. It states the resource type and action. However, for an agent to invoke it correctly, more context would be helpful, such as how to obtain the UUID (e.g., from list results) or the kind of data returned (e.g., 'Returns configuration, status, and deployment details'). It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 100% description coverage ('UUID of the resource'). The description does not add any meaning beyond the schema; it does not clarify what type of UUID (application-specific), nor does it define constraints like format or where to find it. Baseline 3 is appropriate as the schema already fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information about a specific Coolify application', using a specific verb ('Get'), a specific resource ('Coolify application'), and the qualifier 'detailed information' to indicate scope. It effectively distinguishes this tool from siblings like 'coolify_get_database' and list tools like 'coolify_list_applications'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to retrieve details for a single application. However, it provides no explicit guidance on when to use it versus alternatives (e.g., 'coolify_list_applications' for overview, or what 'detailed information' includes), nor does it state prerequisites or exclusions. The context is clear but shallow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states it 'gets' information, which implies a read-only operation, but it does not explicitly mention that it is safe, does not modify data, or any side effects. It also doesn't indicate whether the database must exist or what error occurs if not found. Given the lack of annotations, a simple read operation should at least hint at its safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the tool's purpose with no filler or redundant information. It is appropriately front-loaded with the action and resource. Every word earns its place, contributing to an efficient and clear description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a minimal parameter (one UUID) and no output schema, so the agent has no information about what 'detailed information' means or what the return structure is. The description is vague about the response fields, and with no annotations or output schema, the agent cannot anticipate what data will be available. A more complete description would list examples of the information returned (e.g., status, connection details, configuration).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter 'uuid', including a description ('UUID of the resource') and validation pattern. The description adds no additional semantics about the parameter, but since the schema is complete, a baseline of 3 is appropriate. The description does not clarify what kind of resource (e.g., database ID) the UUID refers to, but the schema's description suffices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get detailed information about a specific Coolify database. It uses the verb 'Get' with the resource 'database', which aligns with the name and distinguishes it from sibling tools like 'list_databases' (which lists all databases) and 'get_database_logs' (which retrieves logs). However, it could be more specific about what 'detailed information' entails, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used to retrieve information about a single database, which is evident from the context. However, it does not explicitly state when to use this tool vs alternatives like 'list_databases' for overview or 'get_database_logs' for logs. There is no mention of when not to use it, but the simplicity of the tool reduces the need for extensive guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool 'gets' information, implying a read-only operation with no side effects. However, it does not mention what happens if the environment doesn't exist (e.g., error vs. null), rate limits, or authentication requirements. A 3 is reasonable as it conveys the basic nature 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, which is very concise. It is front-loaded with the key information. However, it could be slightly improved by adding a brief note about the required parameters or response format without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 required parameters, no output schema, and no annotations, the description is minimally complete. It tells the agent what the tool does and implies the parameters are needed, but doesn't explain what 'detailed information' includes or how to interpret the response. A 3 reflects adequate but not comprehensive coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both parameters described in the schema: 'project_uuid' as 'UUID of the project' and 'environment_name' as 'Name or UUID of the environment'. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information about a specific environment in a project', which is a specific verb+resource combination. It distinguishes from siblings like 'coolify_list_environments' (which lists all environments) and 'coolify_create_environment' (which creates), but 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.
Usage Guidelines2/5
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. Among many sibling tools, there is no indication of prerequisites (e.g., needing a project UUID first), nor when to prefer this over 'coolify_list_environments' (which might be faster for overview). The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Get detailed information', implying a read-only operation, but does not confirm idempotency, discuss auth requirements, rate limits, or what happens if the key does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise single sentence that front-loads the verb and resource. It is efficient, though it could be slightly improved by hinting at the required parameter or return value without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter, the description is adequate but incomplete. It does not mention that the result is a private key object (no output schema), nor does it explain how to interpret the 'detailed information' or any error conditions. Given the large sibling set, a little more context for an AI agent would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the UUID parameter is described in the schema). The tool description adds no additional meaning beyond the schema's property description. Baseline 3 is appropriate as the description neither harms nor significantly improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Get') and the resource ('detailed information about a specific SSH private key'), clearly distinguishing it from sibling tools like 'coolify_list_private_keys' (which lists keys without details) and create/update/delete variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it does not suggest using 'coolify_list_private_keys' first to obtain UUIDs, nor does it specify prerequisites or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to indicate read-only or destructive behavior, and the description does not disclose whether this is a safe, read-only operation. For a simple getter, it likely is read-only, but without explicit statement or annotations, the agent must assume. The description also does not mention any potential side effects (e.g., network call to external service, cost implications), though for a simple version check, these are unlikely. The description is minimal, providing no behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence: 'Get the Coolify instance version'. It is extremely concise, front-loaded, and contains zero wasted words. It perfectly matches the tool's trivial nature – a simple getter with no parameters. There is no superfluous information, making it ideal for quick parsing by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema, no complex logic), the description is adequate but not complete. It tells what it does, but it doesn't explain what the agent should expect as output (e.g., a string version like '4.0.0' or a JSON object). Since there's no output schema, the description could have provided a hint about the return format. Also, it doesn't mention that this might be a read-only operation, which is a minor gap. Overall, it's sufficient for a trivial tool but leaves a few details to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage by definition, as there's nothing to cover). The description correctly implies that no inputs are needed, which is sufficient. Since there are no parameters to explain, the description inherently does not need to add parameter semantics. A score of 4 is given because the description clearly signals 'no arguments required' by its simple phrasing, avoiding any confusion about needing input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: to retrieve the Coolify instance version. The verb 'Get' and the resource 'Coolify instance version' are specific and unambiguous, distinguishing it from sibling tools that focus on applications, databases, or servers. It lacks a bit of nuance (e.g., what 'version' refers to – API version vs. software version), but it's clear enough for an agent to understand its primary purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus others. It does not mention that this is a general-purpose utility to check the Coolify installation's version, nor does it explain that it might be useful before other operations to verify compatibility. Without any context on when to call it (e.g., initial setup, troubleshooting), an agent might overlook it or call it inappropriately. No alternatives are named, but given its uniqueness (no other sibling seems to retrieve instance version), the lack of exclusions is less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It merely states it lists executions, but does not mention that it is read-only, non-destructive, or any side effects. The agent cannot infer safety or impact beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically complete sentence with no unnecessary words. It is front-loaded and highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 required parameters and no output schema. The description does not explain the return format, pagination, ordering, or what constitutes an 'execution'. For a list tool, this is insufficient to fully inform the agent about expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions of both 'uuid' (UUID of the database) and 'backup_uuid' (UUID of the scheduled backup). The description adds no additional meaning beyond what the schema already provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List executions of a database backup schedule' clearly states the action (list) and the resource (executions) with context (database backup schedule). It distinguishes from siblings like coolify_list_database_backups (lists schedules) and coolify_delete_backup_execution (deletes executions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool vs alternatives. It implies usage when you have a database and backup schedule UUID, but does not state when not to use it or mention sibling tools like coolify_list_database_backups or coolify_delete_backup_execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only implies a read operation ('List') but discloses no behavioral traits such as whether it is safe, requires authentication, has rate limits, or returns paginated results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 hint at return values. It only says 'list all environments' without mentioning what fields are returned (e.g., names, UUIDs) or whether the list is filtered. This is insufficient for an agent to fully understand the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter fully described with name, type, pattern, and description). The description adds no extra meaning beyond 'in a Coolify project', which is already implied by the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'List' and resource 'environments in a Coolify project', which distinguishes it from sibling tools like coolify_list_projects (lists projects) and coolify_get_environment (gets a single environment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as coolify_get_environment for a specific environment. There is no mention of prerequisites, filters, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it only states the basic action. It omits whether the operation is read-only, requires specific permissions, returns all tasks or paginates, or any error conditions. This leaves the agent with insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that efficiently conveys the core purpose. No superfluous words. For such a simple tool, this is appropriately concise, though slightly more context could be beneficial without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no nested objects, no output schema). However, the description does not explain what the response contains (e.g., list of scheduled tasks with their IDs, commands, cron expressions). An agent lacks clarity on the return format, which is important for invocation. Given low complexity, 3 is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the only parameter (`uuid`), whose schema description already explains it is 'UUID of the service'. The tool description adds no further meaning or usage details beyond that, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all scheduled tasks for a Coolify service' uses a specific verb ('List') and identifies the resource ('scheduled tasks') scoped to a service. It clearly distinguishes from sibling tools like `coolify_list_application_scheduled_tasks` (for applications) and `coolify_list_service_scheduled_task_executions` (for executions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., create, update, delete, or execution listings). It lacks explicit context for usage, prerequisites, or conditions that would help an agent choose correctly among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It labels the operation as '[DESTRUCTIVE]' and notes 'causes downtime', which is helpful. However, it doesn't clarify whether the action is reversible, whether data might be lost, or what happens to dependent resources (e.g., attached storage). The description adds some value beyond the schema but could be more detailed for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short—two sentences—and front-loads the destructive warning. Every sentence earns its place. Slightly more detail on parameters or behavior would not hurt conciseness significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a 3-parameter destructive operation with no output schema, the description is minimally adequate. It covers the main purpose and the most important effect (downtime). However, it omits return value info (e.g., does it return success status?), error conditions, or idempotency behavior. For a destructive tool, these gaps reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description doesn't add any information about the parameters beyond what the schema provides (e.g., 'uuid', 'confirm', 'docker_cleanup' are already described). No enrichment of parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Stop', the resource 'Coolify service', and the effect 'Causes downtime'. It distinguishes this from sibling tools like 'coolify_stop_application' and 'coolify_stop_database' by using 'service' in the name and description, though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs. alternatives like pausing or scaling down. It doesn't mention prerequisites, ordering of operations, or situations where stopping is inappropriate (e.g., during a deployment). The only usage hint is the [DESTRUCTIVE] tag and 'causes downtime', which is basic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description begins with '[WRITE]' which hints at a write/mutation operation, but since no annotations are provided, the description must fully disclose behavioral traits. It lacks information about whether the update is incremental or replaces all fields, what the effect on running services is, or any required permissions. The description 'Update configuration' is too vague about the mutation's scope and consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise. However, it uses the '[WRITE]' prefix which is not clearly explained and adds minimal value given the description already implies mutation. It is front-loaded with the action verb, but could be slightly more informative without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex context with 8 parameters and no output schema, the description is minimally adequate. It conveys the tool's purpose but does not cover what happens after an update (e.g., does it return the updated server?) or whether all parameters are updatable. The sibling tool list shows many other CRUD operations, but the description doesn't differentiate enough for the agent to know when to use this over coolify_create_server or coolify_get_server.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the schema already does heavy lifting. The description does not add meaning beyond the schema—it simply says 'update configuration' without detailing which parameters are updatable or mandatory. The schema lists 8 optional parameters and 1 required (uuid), but the description doesn't clarify that uuid identifies the server to update, leaving the agent to infer from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update configuration of a Coolify server' which clearly indicates the action (update) and the resource (server configuration). It distinguishes itself from sibling tools like coolify_create_server and coolify_delete_server by using the specific verb 'update', and from coolify_get_server which is read-only. However, it could be more specific by noting that it is used to modify existing server settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for modifying an existing server's configuration after creation, which is a reasonable use case. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., coolify_create_server for new servers, coolify_validate_server for testing). There is no mention of prerequisites or conditions under which the update should be performed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavioral traits. It states '[WRITE]' and 'one-click Docker Compose service', hinting at creation behavior, but lacks details on idempotency, validation steps, required permissions, or return value (no output schema). With zero annotation coverage and minimal description, the agent has insufficient context to anticipate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At one short sentence, the description is concise with no wasted words. However, it could be slightly more informative without sacrificing brevity, e.g., by mentioning required resources (server, project) or that the service type must be one of the supported Docker Compose services. The '[WRITE]' tag is a helpful structural hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (4 required), a nested 'custom_fields' object, no output schema, and dozens of sibling tools, the description is too minimal. It doesn't explain what constitutes a 'service' vs. an 'application' or 'database', what the consequence of 'instant_deploy' is, or how to obtain valid UUIDs for server, project, and environment. The agent lacks enough context to reliably invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds 'one-click Docker Compose service' context but does not elaborate on parameter semantics beyond what the schema already provides. For example, it doesn't clarify how 'custom_fields' or 'instant_deploy' interact with the overall creation flow. Coverage is high, so no penalty, but the description doesn't add significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Create' and resource 'Coolify service', and specifies it's a 'one-click Docker Compose service', which distinguishes it from sibling tools like coolify_create_application or coolify_create_database. The prefix '[WRITE]' further clarifies the operation type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 (e.g., coolify_create_application for custom apps). The description implies usage for pre-packaged Docker Compose services, but does not explain which service types are valid or when to use this instead of coolify_update_service. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description tags '[DESTRUCTIVE]' and the confirm parameter's description ('Set to true to confirm this destructive operation') clearly disclose the destructive nature. Since no annotations are provided, the description carries the full burden and does so adequately for the safety aspect. However, it does not disclose other behavioral traits like idempotency, permission requirements, or side effects (e.g., whether cascading deletions occur).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a useful '[DESTRUCTIVE]' prefix. It is concise and front-loaded with the warning. No extraneous words. Could be slightly expanded (e.g., mentioning the confirm parameter) without losing conciseness, but current form is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is too minimal. It does not explain what happens after deletion (e.g., success/failure response, silent removal), nor does it clarify the relationship between the two required UUIDs. The confirm parameter is mentioned in the schema but not reinforced in the description. More context would help the agent understand the full impact and flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—all three parameters (uuid, task_uuid, confirm) have descriptions in the schema. The tool description adds no additional information about the parameters beyond what is already in the schema. Thus, baseline 3 is appropriate; the schema already documents each parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a scheduled task from a Coolify application'). The verb and resource are specific, and the name differentiates it from sibling tools for different resources (e.g., coolify_delete_application, coolify_delete_service_scheduled_task). However, it does not explicitly distinguish between similar scheduled task delete tools for different parent entities (applications vs. services).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as when to choose delete over update or create. It does not mention prerequisites (e.g., the application must exist) or conditions under which deletion is appropriate. The confirm parameter implies caution, but the description lacks explicit 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are not provided, so the description bears full burden. It marks the operation as '[DESTRUCTIVE]' but does not explain consequences (e.g., the env var is permanently removed, no undo, impact on running application). It also does not confirm whether the confirm parameter is required or what happens if omitted. No side effects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, effective sentence. It front-loads the destructive nature with '[DESTRUCTIVE]', saving the agent from misinterpreting the tool as non-destructive. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 params, no nested objects, no output schema). The description is mostly adequate given the simplicity, but it lacks confirmation about the return value (e.g., success message or error format) and does not state that env_uuid must come from a list call. For a destructive operation, more completeness would be valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all parameters with descriptions. The description adds the label '[DESTRUCTIVE]' which aligns with the confirm parameter's intent, but adds no further semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete an environment variable from a Coolify application'. The verb 'Delete' and resource 'environment variable' are specific. It distinguishes from sibling tools like coolify_create_env, coolify_update_envs_bulk, and coolify_delete_application_storage by naming the exact resource type. However, it does not differentiate from coolify_delete_database_env or coolify_delete_service_env, which are similar delete-env tools for other contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like coolify_list_envs (to find env_uuid) or coolify_delete_database_env. It only implies usage for deleting env vars from applications. No prerequisites or when-not-to-use are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It marks the operation as '[DESTRUCTIVE]' but does not disclose what happens to the integration, any side effects, or the need for the 'confirm' parameter. Important behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with the '[DESTRUCTIVE]' prefix front-loaded. It is concise without unnecessary words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a destructive operation. It does not explain the 'confirm' parameter's role, how to obtain the 'id' (e.g., from coolify_list_github_apps), or what the outcome looks like. Given the simplicity of the tool, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both 'id' and 'confirm' documented. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Delete' and the resource 'GitHub App integration', clearly distinguishing it from sibling tools like coolify_list_github_apps and other delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for deleting GitHub App integrations but provides no explicit guidance on when to use it versus alternatives or what prerequisites are needed. The usage is implied by the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes the destructive nature with '[DESTRUCTIVE]' and the condition 'Blocked if in use'. These are valuable behavioral hints. However, it fails to mention the confirm parameter, which is critical for executing the destructive operation. Without annotations, the description carries full burden and misses this key safety behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using one sentence plus a tag. It is front-loaded with the destructive marker. However, it omits necessary context about the confirm parameter, which would only add minimal length. Slightly under-specified for safe operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with 2 parameters and no output schema, the description should cover the confirm requirement and what the user expects after deletion. It mentions the block-if-in-use constraint but ignores the confirm parameter, which is critical for operation. This leaves the agent potentially unaware of required confirmation, making the tool hazardous to use incorrectly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional parameter information beyond what the schema already provides (uuid and confirm explanations). It does not compensate for or enrich the semantic understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Delete an SSH private key', providing a specific verb and resource. The tool name includes 'delete_private_key', so there is no ambiguity. It distinguishes itself from sibling tools like coolify_create_private_key or coolify_list_private_keys through clear naming and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives (e.g., list keys first or use update). It does not mention prerequisites or scenarios where deletion is appropriate. The only contextual hint is 'Blocked if in use', but that is a constraint rather than usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description correctly labels it as a list operation (non-destructive, read-only). However, it does not disclose any behavioral details such as pagination, ordering, filtering capabilities, or response format. For a basic list tool with no annotations, a score of 3 is appropriate—adequate but not informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that captures the core functionality without any waste. It is front-loaded and efficient, earning its place with zero extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required parameters, no output schema, no nested objects), the description is minimally complete. It communicates the basic function, but for a list tool, additional context about result ordering, limit, or update recency would be helpful. The lack of output schema means the description could have indicated the return type, which it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters (uuid and task_uuid) with descriptions and constraints. The description adds no additional meaning beyond what the schema provides, such as how to obtain the UUIDs or their relationship. Baseline 3 is correct when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 'executions of a scheduled task for a Coolify application'. It distinguishes itself from sibling tools like coolify_list_application_scheduled_tasks (which lists tasks themselves) and coolify_list_service_scheduled_task_executions (which targets services instead of applications). The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. While the sibling set includes similar tools for services and backup executions, there is no mention of prerequisites or conditions (e.g., requiring a valid application and task UUID). The agent must infer usage purely from the name and context, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. However, it only repeats the tool name and parameter description. It does not disclose whether the operation is read-only, whether it requires any permissions, whether results are paginated, or what the response structure looks like. This is a significant gap for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and contains zero wasted words. It efficiently conveys the tool's purpose and scope. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally adequate. It tells what the tool does and identifies the required parameter. However, it does not describe the return format (e.g., a list of scheduled task objects) or any constraints like whether the UUID must be for an existing application. For a bare-bones tool, it is functional but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – the parameter `uuid` has a description ('UUID of the application'). The description adds 'for a Coolify application' which reinforces the parameter's purpose but does not add new meaning beyond what the schema already provides. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('scheduled tasks'), and the scope ('for a Coolify application'). This distinguishes it from sibling tools like `coolify_list_application_scheduled_task_executions` (which lists executions) and `coolify_list_service_scheduled_tasks` (for services). The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 example, there is no mention of prerequisites (e.g., needing a valid application UUID first), or when to use this over `coolify_list_applications` or `coolify_list_application_scheduled_task_executions`. The description is purely declarative without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 is read-only (implied by 'list'), but does not clarify if it returns all variables or only user-defined ones, if it requires specific permissions, or whether the response includes hidden/system variables. The minimal description adds little 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. Every element ('list', 'all', 'environment variables', 'Coolify database') is meaningful and necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 1 parameter (well-documented in schema), no output schema, and no annotations, the description is minimally adequate. It states the core operation but omits context about the response format (e.g., whether it returns values or just keys) and potential edge cases (empty databases, large numbers of variables). For such a simple tool, a 3 reflects it being 'okay but could add one more sentence about response content'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the schema already documents the uuid parameter's type, constraints, and purpose. The description does not add any additional semantic context beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb+resource combination 'List all environment variables for a Coolify database', clearly identifying both the action (list) and the target (database environment variables). It differentiates from siblings like `coolify_list_envs` (which likely lists generic environment variables) by explicitly scoping to databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives like `coolify_list_envs` or environment variable manipulation tools. It does not mention prerequisites (e.g., the database must exist) or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly flags the tool as a write/mutation operation via '[WRITE]'. It mentions 'replace' implying idempotent overwrite behavior, but does not disclose other behavioral traits (e.g., whether it overwrites entirely or merges, whether existing backups are affected, or any rate limits or authorization requirements). This is adequate but not comprehensive 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with a useful '[WRITE]' prefix for quick scanning. It is appropriately concise for a 15-param tool with good schema descriptions. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, no output schema, no annotations), the description is somewhat underspecified. It does not explain that it creates or replaces a backup schedule for a persistent volume/directory, but omits mention of return behavior (e.g., whether it returns the schedule object or just confirmation). The sibling set includes similar backup tools, increasing the need for more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 15 parameters, 3 required, with schema description coverage at 60%. The description itself does not mention any parameters, but the schema descriptions are mostly self-documenting (e.g., 'Cron frequency for the backup'). Given the high schema coverage, the description does not need to add much parameter detail. Credit for not cluttering the description with redundant param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Create or replace a backup schedule') and the resource it targets ('a database persistent volume/directory'). The '[WRITE]' prefix signals mutation, distinguishing it from read tools in the sibling list. However, it does not explicitly distinguish from other database backup tools like 'coolify_create_database_backup' or 'coolify_run_database_storage_backup'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., 'coolify_run_database_storage_backup' for immediate execution vs. scheduling). It does not mention prerequisites, such as requiring existing storage or database UUIDs, or state 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. The [WRITE] prefix indicates a mutation, but the description does not disclose side effects (e.g., cancellation of ongoing deployments), idempotency, auth requirements, or whether the deployment is synchronous. The behavioral transparency is very limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the [WRITE] prefix, which is efficient and front-loaded. It conveys the core action without fluff. However, it could be slightly more structured (e.g., listing resource types in a clearer way) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the tool returns (e.g., deployment ID, status). It also lacks details on prerequisites (resource must exist), error handling, or concurrency behavior. With many siblings, it does not help differentiate from other management actions. The description is incomplete for a tool that triggers an asynchronous operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning both parameters (uuid, force) are already documented in the input schema. The description adds no additional meaning beyond what the schema provides. Baseline is 3, and no extra value is contributed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Trigger a new deployment' and specifies the resource types (application, service, or database). The [WRITE] prefix reinforces the action type. This distinguishes it from sibling tools like start/stop/restart which manage lifecycle but not deployments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 (e.g., start/stop/restart). The context is implied: trigger a deployment when you want to deploy a new version. No exclusions or prerequisites are mentioned. Minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral transparency burden. The '[WRITE]' prefix indicates a mutating operation, which aligns with 'Update' in the description. However, the description doesn't disclose whether changes are immediately applied, require a restart, what happens to unspecified fields (default persistence vs reset), or whether any authorization properties are needed. For a mutation tool without annotations, this is adequate but not comprehensive. It doesn't contradict any annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff. It immediately communicates the action (Update) and resource (configuration of a Coolify database). The '[WRITE]' prefix adds a tiny bit of extra context without becoming verbose. Every word earns its place, making it as concise as possible for a description of this tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters (including one required), no output schema, and no annotations. For a moderately complex update tool, the description is too brief. It doesn't mention what the return value looks like (which is partially excused by no output schema), nor does it clarify that the uuid parameter is essential to identify which database to update. The agent might need to infer that updating a non-existent database could fail. Given the complexity and lack of additional schema/annotation support, a score of 3 is appropriate—minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning every parameter already has a description. The description doesn't add any new meaning beyond the schema—it simply states 'Update configuration of a Coolify database'. With full schema coverage, the baseline score is 3, and since no additional context is provided (e.g., which parameters are commonly used together, or that uuid identifies the target), the score remains 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Update' and resource 'configuration of a Coolify database', which clearly states the tool's purpose. It distinguishes the tool from siblings like coolify_create_database, coolify_delete_database, and others that perform different actions on databases. However, the prefix '[WRITE]' adds context about the operation type, which is useful but not strictly necessary for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 coolify_create_database (for new databases) or the stop/start database tools. It doesn't mention prerequisites (e.g., the database must exist), nor does it note that other update tools exist for specific aspects (e.g., update_database_envs_bulk, update_database_storage). The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as '[DESTRUCTIVE]' and states it deletes both schedule and archives, which provides adequate transparency about its irreversible effects. However, no annotations are provided to offer further context (e.g., destructiveHint, idempotency), so the description carries the full burden. It doesn't disclose whether the operation requires confirmation (the 'confirm' parameter is documented in the schema but not mentioned in the description), nor what happens if schedules/archives don't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at 12 words, fitting the pattern of a clear one-liner. It includes a '[DESTRUCTIVE]' marker upfront that signals danger, which is helpful. Every word adds value—'backup schedule and archives' provides specificity. The description is efficient without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and the tool is destructive with 3 parameters, the description is minimally adequate. It identifies what is deleted but does not explain return behavior (e.g., success/error message), whether it is idempotent, or how to confirm the operation (the 'confirm' parameter). It covers the core intent but leaves gaps about the execution flow and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: all three parameters (uuid, storage_uuid, confirm) have descriptions in the schema. The description adds no additional parameter meaning beyond the schema, which is acceptable since the schema is rich and clear. However, the description does not hint that 'confirm' must be true for the operation to proceed, which could be useful context. With full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete the backup schedule and archives for an application storage', which clearly specifies the verb (delete), resource (backup schedule and archives), and scope (application storage). This differentiates it from siblings like 'coolify_delete_application_storage' (which deletes the storage itself) and backup tools for other resource types (database, service). However, it does not explicitly articulate the nuance of deleting both the schedule and existing archives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you want to remove backups for an application storage) but provides no guidance on when not to use this tool versus alternatives. There is no mention of prerequisites (e.g., needing to identify the storage_uuid first via coolify_list_application_storages) nor warnings about irreversible data loss. A sibling like 'coolify_set_application_storage_backup' suggests a counterpart for setting up backups, but the description does not connect these concepts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes the [DESTRUCTIVE] tag in the text, highlighting irreversible behavior. It also lists parameters like 'delete_volumes' and 'docker_cleanup' that indicate cascading side effects. Since no annotations are provided, the description carries the full burden and does a moderate job disclosing these behaviors, but it could explicitly state that the service, its data, and Docker resources may be permanently removed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core purpose and danger (DESTRUCTIVE). It is front-loaded with the key warning and avoids unnecessary verbiage. It could briefly note the need for confirmation for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is adequate but not thorough. It provides a basic understanding of the destructive nature and references the confirm parameter implicitly, but does not explain the return value (e.g., success status, deleted resource details) or warn about irreversible side effects like volume and Docker cleanup in more specific terms. For a 4-parameter tool with no output schema, more detail would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all four parameters (100% coverage), so the description need not repeat them. The description adds minimal semantics beyond the schema–it implies destruction but does not explain the role of each parameter in the deletion process or how they affect the outcome.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Permanently delete') and the resource ('Coolify service'), which distinguishes it from application- and database-specific delete tools in the sibling list. However, it does not explicitly call out that it targets a 'service' resource specifically, relying on the tool name for that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description marks the operation as [DESTRUCTIVE] and requires a 'confirm' parameter, implying a safety check before performing the deletion. However, it provides no explicit guidance on when to use this tool versus alternatives like 'coolify_delete_application' or 'coolify_delete_environment', nor does it mention prerequisites (e.g., stopping the service first or checking for related resources).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as '[DESTRUCTIVE]', explicitly warning about its irreversible nature. This is helpful beyond the input schema, which includes a 'confirm' parameter for destructive operations. However, with no annotations provided, the description could further detail that deletion is permanent and not recoverable, or note that it only removes the schedule, not the service itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and to the point, front-loading the destructive nature. It is short but not overly terse. Could be slightly improved by adding a note about the 'confirm' parameter requirement, but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (all documented in schema) and no output schema, the description conveys the core operation. However, it lacks context about the relationship to sibling tools (e.g., scheduling/lifecycle) and does not mention that the 'confirm' boolean is likely required for execution. A mention of the task lifecycle (e.g., 'This cannot be undone') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all 3 parameters (uuid, confirm, task_uuid) with constraints (patterns, lengths), achieving 100% coverage. The description does not add any additional parameter-level guidance beyond what the schema offers. A baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly says 'Delete a scheduled task from a Coolify service', which specifies the verb 'delete', the resource 'scheduled task', and the scope 'from a Coolify service'. It is clearly distinguished from sibling tools like 'coolify_delete_application_scheduled_task' and 'coolify_list_service_scheduled_tasks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., service vs. application scheduled tasks). It does not mention prerequisites (e.g., needing UUIDs), or when not to use it. A destructive operation like this would benefit from explicit caution or alternative tools for listing tasks first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 accurately describes the core behavior (retrieving logs with optional filters) but does not disclose if the tool is read-only, if it has rate limits, or if log retrieval could impact performance. The description is factual but lacks depth about side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose ('Retrieve logs for a Coolify database') and then enumerates key filtering capabilities. It is efficient and avoids extraneous detail, though it could be slightly more structured (e.g., bullet points for filters) without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters (1 required), no output schema, and no annotations, the description is adequate but not comprehensive. It does not explain the return format (e.g., JSON array, timestamp structure), default behavior when no filters are applied, or edge cases (e.g., empty results). It covers the core functionality but leaves some practical questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds high-level context about filtering options but does not elaborate beyond what the schema already provides (e.g., the meaning of 'tail' behavior or how 'level' filtering works). It offers no additional semantic value for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve logs for a Coolify database' (specific verb+resource) and lists optional filtering capabilities (level, time range, text search). This differentiates it from sibling tools like coolify_get_logs (which likely retrieves general logs) and coolify_get_service_logs, as it targets database-specific logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives like coolify_get_logs or coolify_get_service_logs. There is no guidance on prerequisites (e.g., the database must exist), no exclusions, and no mention of typical use cases (e.g., debugging database issues).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states it lists resources, implying a read operation, but does not disclose any behavioral traits such as permissions required, rate limits, or whether the list is paginated. The description adds minimal value beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and to the point. There are no redundant words or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description is largely complete, but it could mention the response format or clarify that it returns a list of resources with their types. However, given the low complexity, it is adequately informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'uuid', which is already described as 'UUID of the server'. The tool description does not add any additional meaning or context for the parameter beyond what the schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'all resources (applications, databases, services) deployed on a server'. It uses a specific verb 'list' and a specific resource 'resources on a server', distinguishing it from type-specific siblings like coolify_list_applications or coolify_list_databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention when not to use it, nor does it reference siblings like coolify_list_services or coolify_list_resources as alternatives for different scopes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the listing action and includes sub-resource UUIDs, but omits critical behavioral traits such as read-only semantics, permission requirements, error handling (e.g., missing service), or pagination behavior. The description is insufficient for an agent to fully understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 13 words, front-loading the key action and resource. It is efficient and free of unnecessary words. While it could be more structured, it earns a 4 for being concise and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter, no output schema, and no annotations, the description is somewhat incomplete. It hints at the output (includes sub-resource UUIDs) but does not explain the return format, error conditions, or prerequisites. For a simple list tool, it just meets the minimum adequacy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage for the single parameter 'uuid' with a description ('UUID of the service'). The description adds no additional meaning for the parameter beyond mentioning 'sub-resource UUIDs', which relates to the output not the input. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'storages for a Coolify service', with the additional detail about including sub-resource UUIDs. This effectively distinguishes it from sibling tools like coolify_list_application_storages and coolify_list_database_storages, which target different entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use the tool (to list storages for a service), but it does not provide explicit guidance on when not to use it or compare it to alternative tools like coolify_list_application_storages for application-level storage listing. No when-to-use or when-not-to-use criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It labels the operation as '[WRITE]' and notes 'creates or updates', but fails to clarify whether the bulk update is additive (merges) or replaces all existing environment variables. It also does not mention idempotency, partial failure handling, or whether unchanged variables are preserved. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action type '[WRITE]' and includes the critical upsert clarification. Every word is necessary and no information is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 too brief. It does not explain the bulk semantics (replacement vs. merge), error conditions, limits, or behavior for missing keys. It also fails to differentiate from sibling tools beyond the resource mention, leaving the agent with uncertainty about consequences of invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – both parameters (uuid, envs) have descriptions. The description adds no parameter-level details beyond what the schema already provides (e.g., 'Array of environment variables to set' and 'UUID of the database'). 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('update'), the resource ('environment variables for a Coolify database'), and includes the upsert behavior ('creates or updates'). The name itself indicates 'bulk', and the description distinguishes it from single env creation (coolify_create_database_env) and the generic coolify_update_envs_bulk by specifying 'for a Coolify database'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives (e.g., coolify_create_database_env for a single variable, or coolify_update_envs_bulk for non-database resources). There are no prerequisites, exclusions, or context hints. Usage is only implied by the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral info. It correctly flags this as a write operation with '[WRITE]', and mentions it uses PATCH HTTP method implicitly. However, it does not specify if updates are destructive or partial, auth requirements, or what happens to omitted fields. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the write indication and states the purpose. It is efficient with no wasted words. Could arguably be more structured but score reflects good brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the parameter count (8) and no output schema, the description is somewhat complete for a simple update operation but lacks details on response format, partial vs full update semantics, and conditional parameter usage. The sibling list doesn't help differentiate usage. Score reflects adequacy with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 well. The description adds context that the body includes storage_uuid and type, reinforcing the key requirements. However, it doesn't clarify conditional relationships (e.g., content only for file type) beyond schema enum/descriptions. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a write operation to update storage for a Coolify service, and specifies it supports persistent or file storage. It distinguishes from sibling tools like coolify_create_service_storage and coolify_delete_service_storage, but could be more explicit about targeting an existing storage (versus creating or deleting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is for updating existing storage, but provides no when-to-use guidance vs alternatives like coolify_create_service_storage or coolify_update_application_storage. No explicit context for when not to use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It marks the operation as '[DESTRUCTIVE]', which adds transparency about irreversibility. However, it does not disclose any other behavioral traits such as required permissions, side effects on the application, whether it warns or requires a confirm parameter (though schema has 'confirm' boolean), or potential impact on running applications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with the destructive flag front-loaded. Every word serves a purpose with no redundancy. Ideal length for a delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description could be improved by explaining what happens after deletion (e.g., storage is removed immediately, application may need restart). For a destructive operation with 3 parameters, the description is minimally adequate but lacks completeness regarding effects and confirmation flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the three parameters ('uuid', 'storage_uuid', 'confirm') are already well-documented in the schema with types, patterns, and descriptions. The description adds no additional semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Remove'), the target resource ('persistent or file storage mount'), and the subject ('Coolify application'). It distinguishes clearly from sibling tools like 'coolify_delete_database_storage' by specifying 'application storage'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives (e.g., updating storage, or deleting database/service storage). However, the tool name and context provide implied guidance since it is the only delete for application storage among siblings. No when-not-to-use 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as '[DESTRUCTIVE]', which is appropriate for a delete operation. Since no annotations are provided, the description must disclose behavioral traits, and it does flag the destructive nature. However, it does not specify what exactly gets destroyed (e.g., backup schedule, archives, or both), nor does it mention whether the operation is reversible or requires authorization beyond the confirm parameter. The description is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that quickly communicates purpose and a key behavioral trait (destructive). It is front-loaded with the '[DESTRUCTIVE]' label. One minor improvement could be moving the label to the end or adding a brief second sentence for when to use, but it remains efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, 100% schema coverage, and no output schema, the description is somewhat complete but lacks guidance on what happens after deletion (e.g., no response structure) and does not explain the relationship between `uuid` and `storage_uuid`. The sibling tools offer many storage/backup operations, so the description could better clarify the exact scope of deletion, but it is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying that the operation is 'destructive' and that the `confirm` parameter is required to proceed, which is not fully conveyed by the parameter description alone ('Set to true to confirm this destructive operation'). This extra context raises the score to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action—'Delete the backup schedule and archives'—which establishes the verb (delete) and the resource (service storage backup). It distinguishes this tool from siblings like `coolify_delete_service_storage` (which deletes only the storage, not its backups). However, it does not explicitly mention that it is a sibling-related differentiation, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a general context for when to use the tool: to delete a backup schedule and its archives. It does not explicitly state when not to use it or contrast with alternatives like `coolify_set_service_storage_backup` or `coolify_run_service_storage_backup`. The tool is destructive, requiring a confirm parameter, but no guidance on prerequisites (e.g., storage must exist) is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the HTTP method (GET) and path, which implies a read-only operation, but does not mention idempotency, side effects, error handling, or authentication requirements. It adds minimal value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the purpose and the underlying endpoint without any extraneous words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description explains the input context (team bound to token) but does not describe the return value (e.g., team object structure). For a simple tool, this is adequate but could be improved by mentioning the output format or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema documentation coverage is 100% by default. The description adds meaningful context by specifying that the retrieved team is 'bound to the API token', which explains the implicit parameter (the token). This goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and specifies the resource as 'the team bound to the API token'. It also includes the REST endpoint (GET /team), which reinforces the action. This is distinct from sibling tools like coolify_list_teams (which lists all teams) or coolify_get_current_team_members (which gets members).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as coolify_list_teams or coolify_get_team_members. It does not explain that this tool is for retrieving the team associated with the current API token, nor does it mention any exclusions or prerequisites. The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a GET request (read-only) but does not disclose any other behavioral traits such as required permissions, rate limits, pagination, error responses, or side effects. The minimal statement is not misleading 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 15 words that immediately conveys the action, resource, and endpoint. No filler or redundancy. It is optimally concise for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description is adequate but not fully complete. It does not mention the return format (e.g., list of member objects) or any filtering/pagination behavior. Since no output schema exists, a brief note on the expected result would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with team_id described as 'ID of the team'. The description adds value by explaining how the parameter is used in the API call ('by ID (GET /teams/{id}/members)'), which clarifies the URL mapping. This goes beyond the schema's bare description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List members), the resource (members of a specific team), and the required identifier (by ID). It also includes the HTTP endpoint for further clarity. This distinguishes it from sibling tools like coolify_get_current_team_members and coolify_list_teams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It simply describes the action without mentioning when to choose this over coolify_get_current_team_members or coolify_list_teams. Implicit differentiation from tool names is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool performs a health check but does not disclose what 'healthy' means, expected responses, or side effects. For a read-only check, this is minimally adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is direct and immediately understandable. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless health check with no output schema, the description is mostly complete. It tells the agent what the tool does. Could be improved by hinting at the response format, but it is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. The baseline is 4. The description adds no parameter information, which is appropriate since no parameters exist. It does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks Coolify instance health and reachability. The verb 'check' and resource 'Coolify instance' are specific, and the tool is distinct from sibling CRUD tools. However, it somewhat redundantly restates the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or any prerequisites. Although the health check is self-explanatory in the context of many sibling tools, the description does not explicitly address usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 indicates the tool returns a summary (not full details) and lists the fields in the result, which is helpful. However, it does not disclose whether the operation is read-only (likely safe), whether authentication is required, or any rate limits. Given the simplicity (zero parameters, listing), the baseline disclosure is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficient and front-loaded with the core purpose. It wastes no words. However, it could be slightly more structured (e.g., separating purpose from return info) but remains very clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema, and a clear listing purpose), the description is fairly complete for an agent to understand what it does and what it returns. It does not need to explain return values in depth because the summary fields are explicitly listed. The sibling context shows many database-specific tools, but this tool is broad; the description appropriately sets expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (no parameters exist), so no parameter documentation is needed. The description does not add any parameter semantics because there are none to discuss. Per the guidelines, with zero parameters, the baseline score is 4, but since the description adds no extra value beyond the schema (which already covers everything), a 3 is appropriate as the description is merely adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all databases managed by Coolify and specifies the return summary fields (uuid, name, database_type, status). It is a specific verb+resource pair that distinguishes it from siblings like coolify_list_applications or coolify_list_projects, but it does not explicitly contrast with other database listing tools (e.g., coolify_list_database_backups).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is a straightforward listing operation with no parameters, suitable when you need an overview of all databases. However, it provides no explicit guidance on when to use this versus alternative tools like coolify_get_database (for details of a specific database) or coolify_list_database_backups (for backups). There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. While 'List' implies a read-only operation, the description does not explicitly state the absence of side effects, permissions required, rate limits, or pagination behavior. It is adequate for a simple list but adds no value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded, concise, and contains no unnecessary words. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description does not explain the return format (e.g., array of key-value pairs, JSON object). It also does not mention whether the list is flat or nested, or how errors are handled. For a simple list tool, this is minimally adequate but leaves gaps for an agent to understand the full response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the only parameter 'uuid' has a description: 'UUID of the application'). The description reinforces that the uuid refers to an application but does not add new meaning such as how to obtain the UUID or format constraints beyond what the schema's pattern and length constraints already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all environment variables for a Coolify application' uses a specific verb ('List') and clearly identifies the resource ('environment variables') and the context ('for a Coolify application'). This distinguishes it from sibling tools like coolify_list_database_envs (database envs) and coolify_list_environments (environments, not env vars).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as coolify_create_env, coolify_update_envs_bulk, or coolify_list_database_envs. It does not mention prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden of behavioral disclosure. The '[WRITE]' prefix and 'Run' verb indicate a mutating operation, but the description does not state whether this triggers an immediate execution, whether it requires the system to be in a certain state, or what side effects occur (e.g., backups overwrite or append). It is adequate but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action and intent. It uses a single sentence that conveys the core purpose without unnecessary words. The '[WRITE]' prefix is a useful signal for the agent. It could be slightly more precise but is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 well-documented parameters and no output schema, the description is adequate for basic usage. However, it does not explain what happens after triggering the backup (e.g., whether it returns success/failure, or requires polling), or how it relates to backup schedules. It falls short of being fully self-contained for a complex operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage with two parameters ('uuid' and 'storage_uuid'), each well-documented with patterns and lengths. The description states 'for a service storage' which clarifies that 'storage_uuid' refers to a specific storage entity. While the description does not add much beyond the schema, the schema itself is clear, earning a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') and resource ('on-demand backup for a service storage'), clearly stating what the tool does. It is distinguished from siblings like coolify_set_service_storage_backup and coolify_delete_service_storage_backup by the 'run' action, but could be more explicit about the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The '[WRITE]' prefix hints that this is a mutation tool, but there is no explicit guidance on when to use it versus alternatives (e.g., coolify_list_backup_executions for monitoring, coolify_set_service_storage_backup for configuration). No prerequisites or exclusions are mentioned. The context of on-demand backups 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description accurately indicates the tool is for reading logs and mentions filtering capabilities. However, it does not disclose whether the tool is read-only or potentially destructive, nor does it mention any authorization requirements, rate limits, or default pagination behavior (e.g., returns up to 100 logs by default, which is already in schema). The description adds some context beyond the schema but lacks deeper behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the core purpose and filtering options. It is front-loaded with the key action ('Retrieve logs') and resource type ('Coolify service'). While concise, it could be slightly more structured or include brief usage guidance, but it earns its place without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description provides a high-level overview but is not fully complete. It omits details like typical use cases, the response format, or whether logs are streamed or fetched in bulk. The sibling context shows many similar log tools; the description does not differentiate well enough to guide an agent completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal semantic value beyond the schema—it summarizes the filtering options (level, time range, text search) but does not explain how parameters interact (e.g., combining since and until for a range) or format examples. The description adds little new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves logs for a Coolify service, specifying it's for a service (distinguishing from sibling tools like coolify_get_database_logs or coolify_get_application_logs that retrieve logs for other resource types). It also mentions optional filtering by level, time range, or text search, giving a complete picture of the tool's capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving and filtering service logs, but it does not provide explicit guidance on when to use it versus alternatives. For instance, it does not mention that for application or database logs, one should use coolify_get_application_logs or coolify_get_database_logs instead. No exclusion criteria or prerequisites are listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It correctly indicates a read operation (listing) and supports pagination, but does not disclose safety traits (e.g., non-destructive, no side effects) or potential constraints like authorization needs or rate limits. It adds value by enumerating statuses 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence conveys the core purpose and constrained scope, the second adds pagination detail. Every word earns its place; the description is optimally concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Parameters are fully covered, but the absence of an output schema means the description should clarify what fields are returned (e.g., deployment ID, timestamps). It only says 'deployment history' without structure, which is insufficient for complete tool understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by explaining the result includes all statuses and mentioning pagination, which directly relates to the skip/take parameters. This goes beyond mere schema repetition, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List deployment history for a specific application' with explicit mention of included statuses, distinguishing it from the generic coolify_list_deployments sibling. However, it does not explicitly differentiate using the sibling's name, leaving some reliance on the tool name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when targeting a specific application via UUID, but provides no explicit guidance on when not to use it or mention of alternatives like coolify_list_deployments for broader queries. The context is clear but not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It states the tool returns a 'summary' with four fields, which implies a lightweight read operation. It does not mention side effects, performance characteristics, or whether authentication is required. The lack of annotation support means the description carries the burden, and while it is adequate for a simple list, it omits details like whether it returns all applications or requires a team context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence containing all essential information: what the tool does and what it returns. Every word serves a purpose, and it is front-loaded with the action. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it is a simple, parameterless list tool, the description is mostly complete. It identifies the resource type and the fields returned. However, it does not specify the scope (e.g., all applications across all projects or teams), mention pagination, or indicate if the list is sorted. Without an output schema, slightly more detail on returned data would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% schema description coverage, so the description's role is minimal. It adds value by explaining the output fields (uuid, name, status, fqdn), which is helpful for the agent to understand what data will be returned. This exceeds the baseline of 3 by providing explicit context about the return values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all applications managed by Coolify and specifies the returned summary fields (uuid, name, status, fqdn). It is distinct from sibling tools like coolify_list_databases, coolify_list_services, etc., which list other resource types. The verb 'list' matches the function well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this is for obtaining a summary list of applications, which is appropriate when an overview is needed. However, it does not explicitly advise when to use it versus a more detailed tool like coolify_get_application, nor does it mention any prerequisites or limitations (e.g., pagination or filtering). Sibling tools provide other list options, but no contrast is drawn.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read operation ('List') and mentions the return fields, but does not explicitly state traits like idempotency, authentication requirements, or any limitations. For a simple list tool, this is minimally 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key action and return information. Every word earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately covers the tool's purpose and return shape. It could optionally mention that it returns all teams accessible by the user, but it remains sufficiently complete for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. The description adds no parameter information because none is needed, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all teams' with a specific verb and resource, and specifies the returned fields (id, name, description). This distinguishes it from sibling tools like coolify_list_applications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description simply states the action without any contextual usage advice or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. The '[WRITE]' prefix explicitly signals a write/mutative operation, which is appropriate for starting a database. It does not disclose error conditions (e.g., starting a running database) or state transitions, but for a simple start action this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single very short sentence with a useful '[WRITE]' prefix, which is concise and front-loaded. It earns its place but could slightly expand on what 'start' entails (e.g., initiates the database service).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple start action with one parameter and no output schema, the description is minimally complete. However, for a write operation, it could mention idempotency or error behavior (e.g., 'no effect if already running').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 required 'uuid' parameter as 'UUID of the resource'. The description adds no further parameter meaning, which is acceptable baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'Start a stopped Coolify database', which clearly identifies the verb (start) and resource (Coolify database), distinguishing it from siblings like 'stop_database' and 'restart_database'. However, it does not differentiate from 'start_service' or 'start_application' explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool is for starting a stopped database, implying when to use it, but provides no guidance on when not to use it (e.g., if already running) or alternatives like restart_database.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tool has no annotations, so the description must carry the full burden of behavioral disclosure. It discloses that the tool writes (creates/updates) data, which is critical for the agent's decision-making. However, it does not disclose potentially important behaviors like whether the operation replaces all envs or patches them, whether it triggers a redeploy, what happens with existing envs not in the array, or if there are idempotency or rate-limit considerations. The description provides basic transparency but lacks sufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that includes the WRITE tag, the action, the resource, and the behavioral nuance of creating or updating. Every part of the sentence adds value: it identifies the operation type, the resource, and the method of operation (upsert). There is no wasted text, and the information is front-loaded with the most critical detail. It is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters with 100% schema coverage, no output schema, and no annotations, the description covers the basic purpose and states that it creates or updates. However, it is incomplete for a bulk-write operation—it does not explain what the return value looks like, whether the operation is synchronous or asynchronous, or how the system handles the batch (e.g., all-or-nothing vs. partial success). The description is minimally viable but leaves gaps that could cause incorrect agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning the schema itself documents both parameters (uuid and envs). The description adds value by explaining the operation in terms of the environment variables array—that it 'bulk update[s]... environment variables' and 'creates or updates' them. This provides semantic context about the purpose of the 'envs' parameter beyond the schema's bare 'Array of environment variables to set'. The description correctly sets expectations for the bulk operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Bulk update', the specific resource 'environment variables for a Coolify service', and lists an important behavioral detail 'creates or updates'. However, it does not distinguish itself from closely related sibling tools like 'coolify_update_service_envs_bulk' (itself) or 'coolify_update_database_envs_bulk', which have nearly identical functionality for different resource types. The leading '[WRITE]' tag is helpful for identifying the action type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent wants to set multiple environment variables at once on a service, with the note that it both creates and updates. However, it does not explicitly state when this tool should be used versus alternatives like 'coolify_create_service_env' (single env) or 'coolify_delete_service_env', nor does it mention any prerequisites (e.g., service must exist). The sibling tool list is extensive, but the description offers no comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 explicitly labels the tool as '[DESTRUCTIVE]' and states it will 'permanently delete a server' and 'stop all its resources'. This is exceptional clarity about the irreversible, destructive nature of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the destructive action. The '[DESTRUCTIVE]' prefix immediately signals the tool's nature. However, it could be slightly more structured by separating the warning from the action description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (three parameters, no output schema, no nested objects), the description is largely complete. It covers the core purpose, destructive nature, and resource impact. It could be enhanced by briefly mentioning the need for the 'confirm' parameter to prevent accidental deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 (uuid, force, confirm). The description adds no further meaning to these parameters beyond what is in the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'server', and adds the important nuance that it 'stop[s] all its resources'. This differentiates it from sibling tools like 'coolify_delete_application' or 'coolify_delete_database' which delete specific resources, not the server itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. For example, it doesn't mention that to simply stop a server without deleting, one should use 'coolify_stop_server' (which doesn't exist in siblings, but the intent is missing). There is no clarification on prerequisites (e.g., need to stop resources first) or when to use the 'force' parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It accurately describes a read-only operation and mentions the output contains resource mappings, but does not clarify whether the operation is idempotent, requires special permissions, or has any rate limits. The tool is simple, so the lack of details is not critical, but still leaves room for doubt.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words that conveys the core purpose and key output detail. It is front-loaded, contains no filler, and every word earns its place. This is an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should explain what the returned data looks like. It mentions 'resource mappings' but does not elaborate on the structure (e.g., list of domain objects with resource identifiers). No pagination, sorting, or error behavior is mentioned. For a straightforward list operation, the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'uuid' with a description ('UUID of the server') and validation constraints. The tool description does not add any extra meaning beyond what the schema already provides. Since schema description coverage is 100%, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('list'), the resource ('domains'), and the scope ('configured on a server') along with an additional detail about output ('with their resource mappings'). It immediately distinguishes itself from sibling tools like coolify_get_server_resources or coolify_list_servers by specifying the domain focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving domain mappings for a given server, but does not explicitly state when to prefer this tool over alternatives (e.g., coolify_get_server_resources) or note any preconditions (e.g., server must exist). No exclusion criteria or sibling references are provided, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral context. It describes the action (list) and the return data (summary fields), which hints at a read-only, safe operation. However, it does not disclose if there are any side effects, authorization requirements, or performance considerations (e.g., rate limiting, pagination). It does not contradict annotations 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the purpose and output. It is front-loaded and contains no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description is fairly complete for a simple listing tool. It states what it returns, which is sufficient. The only minor gap is missing any context about pagination or result limits, but overall it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is no additional meaning needed beyond what the schema already provides. The description confirms that no input is required. The mention of return fields adds value for the user without parameter ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists servers managed by Coolify and specifies the returned fields (uuid, name, ip). It uses a specific verb ('list') and a clear resource ('servers'). It does not explicitly differentiate it from sibling tools like coolify_get_server, but the action of listing vs getting is fairly self-evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests this is for getting a summary of servers, but it provides no explicit guidance on when to use this tool versus alternatives (e.g., coolify_get_server for details, coolify_validate_server for validation, or coolify_get_server_resources for resource info). No exclusions or context for when not to use it are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It tags the operation as [DESTRUCTIVE] and notes brief downtime, but does not disclose other behaviors such as idempotency, error conditions, or prerequisites (e.g., database must be running).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single sentence plus a [DESTRUCTIVE] tag, front-loaded with the warning. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers purpose and consequence but lacks guidance on edge cases (e.g., what happens if database is already stopped or missing) and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides (uuid, confirm).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Restart' and the resource 'Coolify database', and adds a consequence 'Causes brief downtime', distinguishing it from siblings like start, stop, delete, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to restart a database) but does not provide explicit guidance on when to use it vs alternatives like start or stop, or mention prerequisites like database running state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The '[WRITE]' tag and 'Create or replace' clearly indicate mutation, but the description does not disclose what happens to existing settings on replacement, whether the operation is reversible, or any confirmation/rollback behavior. For a write tool with 15 parameters, more behavioral context would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the action and scope. No extraneous words or redundant information. It earns its place by quickly communicating the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, no output schema, no annotations), the description is minimally adequate. It identifies the core purpose, but lacks details on return values, default behavior for optional parameters, or side effects of replacement. Sibling tools like coolify_run_application_storage_backup exist, so a clearer contrast would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, meaning many parameters already have meaningful descriptions in the schema. The description provides a high-level purpose ('backup schedule...') but does not add detail beyond the schema for the remaining 40% of parameters. It adds no new param-level semantics, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create or replace') and resource ('backup schedule for an application persistent volume/directory'). It also includes a '[WRITE]' tag, which clearly signals that this tool modifies state, distinguishing it from read-only sibling tools like coolify_list_application_storages or coolify_run_application_storage_backup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Create or replace' which implies idempotent behavior, but it does not explicitly state when to use this tool versus alternatives (e.g., coolify_run_application_storage_backup for immediate execution or coolify_delete_application_storage_backup for removal). There is no guidance on 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds '[DESTRUCTIVE]' and 'Causes downtime', which are useful behavioral traits. However, it does not disclose the requirement for the 'confirm' parameter, the role of 'docker_cleanup', or any authorization or side effects beyond downtime.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, front-loading the destructive warning. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 parameters and no output schema, the description is adequate but could be improved by explicitly noting that the 'confirm' parameter must be set to true for the operation to proceed. It covers the core purpose and a key effect (downtime) but lacks a few details that would make it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no information about the uuid, confirm, or docker_cleanup parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Stop a running Coolify database', which is a specific verb+resource combination. It clearly distinguishes from sibling tools like coolify_start_database, coolify_restart_database, and coolify_delete_database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (stop a database) but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. The '[DESTRUCTIVE]' label hints at caution but is not a full guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explicitly calls out that the operation is destructive, permanent, and deletes all environments. The description also aligns with the confirm parameter, which is a common safety pattern. This is strong behavioral transparency for a deletion tool, though it could mention that other resources within the project are also removed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with a valuable [DESTRUCTIVE] prefix. It is concise and front-loaded, though the tag could potentially be formatted more clearly (e.g., bold or italic) for readability. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description doesn't mention return values or error cases. However, for a deletion tool, the side effect (deletion) is the primary behavior, and the description covers that well. A brief note about what happens on success (e.g., 'Returns success message') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have descriptions: uuid as 'UUID of the resource' and confirm as 'Set to true to confirm this destructive operation'. The description does not add extra meaning beyond what the schema already provides. A baseline 3 is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete', the resource 'Coolify project', and the scope 'all its environments'. It also uses the [DESTRUCTIVE] tag to signal severity. This effectively distinguishes it from sibling tools like coolify_create_project or coolify_get_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a '[DESTRUCTIVE]' prefix that implies caution, and the tool has a confirm parameter for safety. However, there is no explicit guidance on when to use this versus other delete tools (e.g., coolify_delete_environment) or any prerequisites like needing the project's UUID. Usage context is implied but not fully detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'List all GitHub App integrations'. It does not disclose behavioral traits such as whether the tool is read-only, whether it returns paginated results, authentication needs, or response format. This leaves the agent to infer behavior from naming alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the tool's purpose without extra detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is mostly complete. It tells the agent exactly what this tool does. However, it could be improved by noting the return type (e.g., array of GitHub App objects) or read-only nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema is fully covered. The description does not need to add parameter meaning. Baseline for 0 parameters is 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is clear and specific: verb 'List', resource 'GitHub App integrations', scope 'configured in Coolify'. It distinguishes itself from sibling tools like coolify_create_github_app, coolify_update_github_app, and other list tools for different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic purpose but no explicit guidance on when to use this tool vs alternatives (e.g., coolify_list_github_app_repositories). For a simple list tool, the absence of when-not or alternative references is acceptable but not excellent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It only states it returns a summary, leaving out whether this is a read-only operation, any prerequisites, or potential side effects. Minimal behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that efficiently communicates the tool's purpose and output. No redundant or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list tool, the description covers the core purpose and return fields adequately. However, it could add context like whether the list is globally scoped or if any default ordering applies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline 4 applies. The description adds value by clarifying the return format, which the empty schema cannot convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all SSH private keys and specifies the exact fields returned (uuid, name, description, fingerprint). It distinguishes from sibling tools like coolify_list_applications and coolify_list_databases by focusing on a specific resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 over alternatives is provided. Although the name and description make the purpose obvious, there are many other list tools, and an agent would benefit from knowing this is the sole tool for listing SSH private keys.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly labels the operation as '[DESTRUCTIVE]' and notes it causes brief downtime, which is critical behavioral context. It does not mention any authentication or authorization needs, but the destructive label and downtime warning cover key expectations for a restart operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only two short sentences that are front-loaded with the most critical info ([DESTRUCTIVE], restart action). Every word adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple restart tool with no output schema and only two parameters (both fully documented in schema), the description adequately covers purpose, behavioral impact, and a key constraint (downtime). It does not explain what happens on success/failure or how to confirm the operation, but these are covered by the confirm parameter. Overall, it is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed schema descriptions for uuid (pattern, length) and confirm (boolean flag). The description does not add any extra semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool restarts a Coolify application, using a specific verb and resource. It distinguishes from siblings like coolify_start_application and coolify_stop_application by implying a restart (stop then start). However, it does not explicitly differentiate from the sibling coolify_restart_database, which is for a different resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'causes brief downtime', which warns about usage context but does not explicitly state when to use this vs alternatives like coolify_start_application (for initial starting) or coolify_stop_application (for stopping). No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly marks the operation as destructive (via [DESTRUCTIVE] tag) and discloses the brief downtime consequence. Since no annotations are provided, the description fully carries the burden of behavioral disclosure, and it does so clearly and accurately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two short sentences that immediately state the action, its destructive nature, and the impact (brief downtime). Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple restart tool with 2 parameters, 100% schema coverage, and no output schema, the description sufficiently covers the core behavior and risk. It does not provide post-restart state or error scenarios, but that is reasonable given the tool's simplicity and the existence of sibling tools that return status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the uuid parameter and confirm parameter already have descriptions in the schema. The description does not add any new information about the parameters, so it earns the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Restart a Coolify service' with a specific verb and resource. Among sibling tools, there are also start_service, stop_service, and restart_application, so the description correctly targets services, but it does not explicitly distinguish itself from restart_application, which is handled by the tool name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a warning that it is destructive and causes brief downtime, which implies when to be cautious. However, it does not explicitly state when to use this tool versus the sibling tools like coolify_restart_application, nor does it mention prerequisites or that the confirm parameter must be set to true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden for behavioral disclosure. It clearly marks the operation as destructive and warns about downtime, which is critical for an agent deciding to use this tool. The flag '[DESTRUCTIVE]' at the start is effective. It does not detail what happens to Docker resources or the state of the application beyond 'stop', but the confirm parameter and docker_cleanup hints are indirectly supported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loaded with the critical '[DESTRUCTIVE]' flag. Every sentence adds value. One might argue that 'Causes downtime' is slightly redundant after '[DESTRUCTIVE]', but it clarifies the specific impact for an application, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is minimal but covers the essential: it stops an application with destructive consequences. It does not explain return values, state transitions, or error scenarios, but for a straightforward stop operation, this may be sufficient. The sibling tools (like coolify_start_application) provide complementary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add any additional parameter-level details beyond the schema definitions. However, the description's 'destructive' context reinforces the need for the 'confirm' parameter, which is a minor benefit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Stop'), resource ('Coolify application'), and states a key consequence ('Causes downtime'). This clearly distinguishes it from siblings like coolify_start_application or coolify_restart_application.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the tool is destructive and causes downtime, implying caution. However, it does not explicitly state when to use this tool versus alternatives like coolify_restart_application, or when not to use it (e.g., if only a temporary pause is needed). No prerequisites or context are given beyond the destructive nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. The description indicates the tool is a read-only listing operation (GET and list), which implies no side effects. However, it does not mention authentication requirements beyond the implicit API token binding, rate limits, or any pagination behavior. Given the simplicity of a no-parameter list call, the behavioral disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that clearly states the action and scope. It includes the endpoint in parentheses for reference without redundancy. Every part of the sentence is informative and there is no wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-parameter, read-only listing tool, the description is nearly complete. It identifies the endpoint and the scope. The only minor omission is a note on what the response contains (e.g., a list of member objects). However, since there is no output schema, a brief note on return structure would be helpful. Still, the description effectively explains the tool's function without being overly verbose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema description coverage is 100% (since there are no parameters to miss). The description adds no parameter semantics because none are needed. The baseline for 0 parameters is 4, and the description appropriately handles this by not adding extraneous information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 listing members of the team associated with the API token. It includes the specific API endpoint (GET /team/members), which disambiguates it from siblings like coolify_get_team_members (which might list members for any team) and coolify_list_teams (which lists teams, not members). The verb 'list' is appropriate and the resource 'members of the team bound to the API token' is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'bound to the API token' explicitly clarifies that this operation is scoped to the current authentication context. This tells the agent when to use this tool (when needing members of the current team) versus alternatives like coolify_get_team_members (if there is one that allows specifying a team ID). While it doesn't explicitly list alternatives, the sibling tools context provides a clear differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. The description explicitly labels this as a '[WRITE]' operation and notes the SSH private key requirement, which signals the type of credentials needed and that this is a mutation. It could mention that the operation likely creates a persistent record, but the bracket tag and key requirement provide reasonable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with an essential parenthetical note. Every word adds value, and there is no redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 and no output schema, the description is nearly complete. It explains the action and the critical prerequisite (SSH private key). The only minor gap is that it doesn't hint at the response (e.g., returns the created server object), but since there is no output schema, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. The description adds no additional semantic value beyond the existing parameter descriptions, which is sufficient for a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('Coolify server'), and the parenthetical note about requiring an SSH private key adds important context. It distinctly differentiates this tool from siblings like coolify_list_servers, coolify_get_server, and coolify_delete_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to create a server) but offers no guidance on when not to use it or alternatives. With many sibling tools for other resources, it doesn't help the agent decide between creating a server vs. other resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly states the action is permanent and destructive with '[DESTRUCTIVE]' and 'Permanently', which is good. However, it does not disclose side effects like whether the deletion is irreversible, what happens to associated resources (e.g., if delete_volumes and docker_cleanup are false), or whether it requires confirmation via the 'confirm' parameter. The description partially compensates for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. The '[DESTRUCTIVE]' tag immediately conveys critical behavioral context, and 'Permanently delete a Coolify application' is precise and complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and no output schema, the description does not explain what the return value is (e.g., success message or ID). However, the schema covers all parameters well, and the description clearly sets expectations for the operation's finality. A note about the confirmation parameter or return behavior would increase completeness, but it is adequate for a deletion tool with well-documented params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 four parameters with descriptions. The tool's description adds no additional parameter meaning beyond the schema's structured definitions. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear, specific verb ('delete') and resource ('Coolify application'), immediately stating the action's permanent nature with the '[DESTRUCTIVE]' prefix. This clearly distinguishes it from siblings like 'coolify_stop_application' (temporary halt) and 'coolify_delete_application_storage' (storage deletion only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly signals the destructive nature and permanence of the operation via '[DESTRUCTIVE]' and 'Permanently delete'. This implies careful consideration before use, though it does not explicitly state when not to use it (e.g., use 'coolify_stop_application' instead) or list any prerequisites (e.g., application must exist). The sibling list contains safer alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It states a read-only list operation, which is transparent enough for a simple tool. However, it does not disclose whether hidden variables are included, if any filtering applies, or the response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundant information. It front-loads the action and resource effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read operation, the description adequately conveys what it does and for what type of resource. It lacks details about return values or potential errors, but no output schema exists and the operation is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single 'uuid' parameter with 'UUID of the service' (100% coverage). The tool description adds no additional parameter meaning, so it relies on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all environment variables for a Coolify service' uses a specific verb (List) and clearly identifies the resource (environment variables) and the scope (Coolify service). This distinguishes it from sibling tools like coolify_list_database_envs or coolify_list_envs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a Coolify service' provides clear context about when this tool is appropriate, implying it is for service-specific env vars rather than database or application envs. However, it does not explicitly name alternative tools or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns a summary of services with specific fields, which is useful. However, it does not explicitly state that the operation is read-only or has no side effects. Since no annotations are provided, the description carries the full burden; it is adequate but could be more transparent about the behavioral safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose, includes the return summary in parentheses, and contains no unnecessary words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is complete. It states what is listed, the scope (all services), and the fields returned. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description's job is to explain the tool's behavior. It does so by indicating the tool returns 'all services' and lists the summary fields. This adds value beyond the empty schema. With 0 parameters, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'List all services managed by Coolify' with a specific verb 'List' and resource 'services'. It distinguishes from sibling tools like 'coolify_list_applications' and 'coolify_list_databases' by naming the resource category. It also specifies the return fields (uuid, name, status, service_type), adding precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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. The tool name and resource category implicitly differentiate it from sibling list tools, but the description does not direct the agent to use this for services and not for applications/databases, nor does it mention any conditions or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds the '[DESTRUCTIVE]' prefix to signal that this is a destructive operation, which is helpful. The description does not clarify whether removing storage deletes data permanently or what permissions are needed, but given the tool name and the common semantics of deleting storage mounts, a 3 is fair.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with a critical warning prefix. It contains no filler, is front-loaded with the destructive indicator, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with 3 simple parameters, no output schema, and no nested objects, the description is adequate. It communicates the core action, the resource type, and the destructive nature. It could optionally clarify that removal is permanent (but that is implied by 'delete'). Given the complexity level, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with well-defined parameters (uuid, confirm, storage_uuid). The description's mention of 'storage mount' and 'Coolify service' adds context by implying that 'uuid' refers to a service UUID and 'storage_uuid' to a storage mount, which is already in the schema but reinforced. The description adds value by linking the action to the parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Remove), the resource (persistent or file storage mount), and the target (Coolify service). The sibling tools include coolify_delete_application_storage and coolify_delete_database_storage, so this tool's scope is precisely differentiated by the 'service' context in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly marks this as [DESTRUCTIVE] in the text, which provides a strong usage signal. The sibling tools include create and update variants for service storage, offering implied alternatives. However, there is no explicit statement about when to use this tool vs coolify_delete_application_storage (e.g., for a service vs application context), missing a minor clarity opportunity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the scope of results (currently running/queued) and notes that it returns a summary. However, it does not clarify if the tool is read-only, whether results are sorted, or what data is included in the summary beyond what 'limit' controls. A 3 is appropriate given decent but incomplete 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero wasted words. The first sentence clearly states scope and output type, the second provides an explicit alternative. Ideal front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and no output schema, the description is nearly complete. The only gap is that it doesn't mention whether the results are paginated or what 'summary' means structurally, but this is minor given the simplicity. A score of 4 reflects strong completeness for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single well-documented 'limit' parameter (type, default, min, max). The description adds no additional parameter information because none is needed. Baseline 3 is correct as the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'list currently running/queued deployments only', specifying both the verb (list) and the resource (deployments) with a precise scope (currently running/queued). It distinguishes from the sibling tool 'coolify_list_application_deployments' which handles deployment history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (for currently running/queued deployments) and when to use the sibling tool instead ('For deployment history, use coolify_list_application_deployments instead'). This is perfect usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It accurately describes the tool as a read-only listing operation returning a summary. No behavioral quirks (e.g., pagination, filtering) are mentioned, but for a simple list with no parameters, this is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the tool's purpose and return value. No wasted words; every part of the description earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters and no output schema, the description is complete. It states what is returned (summary fields). Could optionally mention that the output is a list of objects, but this is implied by 'List all projects'. The description provides enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100% and the description adds no parameter detail. With 0 parameters, the baseline is 4, and the description does not need to add anything further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists all projects in Coolify and specifies the summary fields returned (uuid, name, description). The verb 'list' and resource 'projects' are specific and distinct from sibling list tools that target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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. While the usage is straightforward, a sentence like 'Use this for a quick overview of all projects; for detailed info on a specific project, use coolify_get_project' would improve clarity. The current description implies usage but does not provide exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates this is a read-only operation ('List'), which is transparent. However, it does not disclose any additional side effects, output format, or pagination behavior. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and includes a parenthetical listing of resource types. Every word serves a purpose with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters, no output schema, no annotations, and the tool is a straightforward list operation, the description covers the essential semantics. It could mention whether the output is paginated or ordered, but for such a simple tool, the current level is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with zero parameters, so there are no parameters for the description to explain. The description correctly sets no expectations about parameters. The baseline of 4 is appropriate given there is nothing to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'all resources', and specifies what those resources include (applications, databases, services), and the scope 'across all projects'. This distinguishes it well from sibling tools like coolify_list_applications, coolify_list_databases, and coolify_list_projects, which are more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a broad, unfiltered listing purpose—getting a comprehensive overview. It doesn't explicitly state when not to use it or name alternatives, but the sibling tool list makes it self-evident that more specific list tools exist for filtered views. It lacks explicit exclusions but offers clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![coolify-mcp MCP server](https://glama.ai/mcp/servers/0xtlt/coolify-mcp/badges/card.svg)](https://glama.ai/mcp/servers/0xtlt/coolify-mcp)

Score Badge

Copy to your README.md:

[![coolify-mcp MCP server](https://glama.ai/mcp/servers/0xtlt/coolify-mcp/badges/score.svg)](https://glama.ai/mcp/servers/0xtlt/coolify-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/0xtlt/coolify-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server