coolify-mcp

Server Quality Checklist

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

Latest release: v0.1.5
Disambiguation2/5
Several tools have overlapping functionality, such as createDatabase and createService (services can create databases), and listResources vs getServerResources vs getInfrastructureOverview all provide resource listings. Names like listDeployments and listAppDeployments are also easily confused. These overlaps will cause agents to select the wrong tool.
Naming Consistency3/5
Most tools follow a clean verb_noun structure (create, get, list, delete, start, stop), but a significant subset use noun-only names (applicationEnvs, storages, scheduledTasks, teams) and one tool is just 'deploy'. This inconsistency breaks the predictability of the set.
Tool Count1/5
With 65 tools, this is far beyond the 25+ threshold and qualifies as extreme. The server bundles many operations into action-group tools (e.g., applicationEnvs) yet still exposes an overwhelming number of entry points.
Completeness4/5
The surface is remarkably complete for the Coolify domain, covering projects, servers, applications, databases, services, deployments, envs, storages, tasks, backups, and diagnostics. Minor gaps exist, such as no environment update/delete and no project details getter, but these are not critical.
Average 3.7/5 across 65 of 65 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 3 community issues answered or closed in the last 6 months
- 36 commits in the last 12 weeks
- Last stable release on August 6, 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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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?
The description adds no behavioral context beyond the annotations. It does not mention pagination, log format, or limits, aside from what the schema already implies. The read-only nature is already captured by readOnlyHint.
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 filler, making it highly concise. However, its brevity contributes to the lack of detail in other dimensions.
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 simple tool, the description is not completely inadequate, but it lacks essential parameter semantics and usage context. The required uuid parameter is unexplained, and there is no output schema to clarify return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain the meaning of uuid or lines. An agent must guess that uuid identifies the application, and lines controls the number of log lines.
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 fetches runtime logs for an application, using a specific verb and resource. This distinguishes it from sibling tools like getApplication or getDeployment.
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 preconditions. The description simply states what it does, leaving the agent to infer 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe read-only nature is established. The description adds only 'all' as a scope qualifier, but does not disclose pagination behavior, return format, or the meaning of the summary parameter, which are relevant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the tool's core purpose without wasted words. It is concise, though it could be expanded with parameter hints without losing 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?
For a tool with optional parameters, no output schema, and many similar siblings, this description is incomplete. It fails to mention pagination, return structure, or how it differs from tools like listResources, leaving the agent without enough context to invoke it confidently.
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 0%, and the description does not mention the limit, offset, or summary parameters. While the parameter names are somewhat self-explanatory, 'summary' is ambiguous, and the lack of any explanation for how these parameters affect the result is a significant gap.
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 identifies the action ('List') and the resource ('Coolify applications'), and the word 'all' adds scope. However, it doesn't distinguish from sibling tools like listResources or listAppDeployments, which may also return application-related data.
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. With many sibling list tools (listResources, listProjects, listServers, etc.), the absence of context or exclusions leaves the agent to guess which tool is appropriate for a given task.
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 annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds context about pagination and filters, but does not disclose important behaviors such as whether secrets are hidden by default, what 'summary' means, or how filters affect results. This adds a little beyond annotations but not rich 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 concise sentence with no wasted words, and it is front-loaded with the core action. However, it is arguably too sparse given the tool's parameter complexity, so it sacrifices substance for 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?
The tool has no output schema, five parameters with no descriptions, and nine sibling tools. The description does not explain the return value, the meaning of 'filters', the behavior of 'showSecrets', or how this list differs from other list tools. This is insufficient for an agent to fully understand and correctly invoke the tool in all intended scenarios.
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?
With schema description coverage at 0%, the description must compensate for the five undocumented parameters. It only provides the generic phrase 'optional pagination and filters', which vaguely maps to limit/offset and type, but leaves 'summary' and 'showSecrets' entirely unexplained. The description adds minimal semantic value beyond the schema's parameter names and types.
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 resource ('databases'), which is specific and unambiguous. However, it does not explicitly distinguish itself from sibling tools like 'getDatabase' or other list tools, though the plural form and mention of pagination/filters hint at a collection-level 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?
No guidance is provided on when to use this tool versus alternatives such as 'getDatabase' or 'databaseBackups'. The description only mentions optional pagination and filters, implying a standard listing use case, but it lacks explicit context, prerequisites, or alternative recommendations.
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?
The description claims 'List all Coolify servers', but the annotation openWorldHint=true indicates that the result may not be exhaustive. This is a direct contradiction. Beyond that, the description does not disclose pagination behavior or that the summary parameter may alter the response shape.
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 two concise sentences with no filler. It front-loads the verb and resource, then lists the return fields. Every sentence serves a purpose.
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 is simple, but the description is incomplete given the openWorldHint annotation and the undocumented parameters. The 'all' claim conflicts with the annotation, and the lack of parameter semantics means the agent cannot fully understand pagination or summary behavior. The return-field list is helpful but does not compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines three parameters (limit, offset, summary) with 0% description coverage. The tool description does not explain any of these parameters, leaving the agent without guidance on pagination or summary response formatting. Since coverage is low, the description must compensate but does not.
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 action ('List') and a specific resource ('all Coolify servers'), and identifies the return fields (UUID, name, IP, user, port, proxy type). This clearly distinguishes it from siblings like getServer (single server) and listResources (broader resource list).
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 clearly implies the tool is for listing servers, but it does not explicitly state when to use this tool versus alternatives like getServer or listResources, nor does it mention how pagination (limit/offset) or the summary flag should be used. No exclusions or alternative guidance is provided.
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?
Annotations already mark the tool as readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds context about what constitutes a 'service' but does not disclose additional behavioral details such as pagination behavior or response structure. It does not contradict 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, concise sentence that gets straight to the point. It is front-loaded with the verb and resource, and there is no unnecessary wording or repetition.
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 and three undocumented parameters, yet the description only provides a one-line purpose. It does not explain what the response contains, how pagination works, or what the 'summary' flag does, leaving significant gaps for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining limit, offset, and summary. The description contains no mention of these parameters or what they control, leaving the agent without any semantic guidance beyond the raw schema types and 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 clearly identifies the operation ('List') and the resource ('Coolify services') with examples ('one-click apps like databases, caches, etc.'). It is specific enough to distinguish from many sibling tools, though the examples could create ambiguity with listDatabases and listApplications since it doesn't explicitly state how services relate to those.
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 like listApplications or listDatabases. It simply states 'List all Coolify services,' which implies usage only by the resource name but does not clarify scenarios or exclusions.
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?
Annotations already declare readOnlyHint and openWorldHint, so the description doesn't need to restate safety. However, it adds no behavioral details beyond what the schema implies, such as default pagination, response shape, or whether all resource types are included.
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 with no fluff, accurately conveying the core function and mentioning optional features. It is well-structured and easy to parse.
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 5 undocumented parameters, the description is too skeletal. It doesn't explain what data is returned, how filters work, or how this tool relates to the many resource-specific list tools.
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 0%, so the description should compensate. It only groups parameters into vague categories ('pagination', 'filters', 'summary') without mapping them to actual parameter names or explaining allowed values, which is insufficient for 5 undocumented parameters.
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 clear verb ('List') and identifies the resource ('Coolify resources'), but it doesn't differentiate from sibling tools that list specific resource types such as listApplications or listDatabases. The meaning of 'resources' is somewhat ambiguous.
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 for when to use this tool versus the many sibling list tools. It doesn't mention that this is a general resource list or that specific tools exist for particular resource types.
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?
Annotations already declare the tool is non-read-only (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the behavioral detail that it returns the project UUID, which is useful but does not cover other aspects like auth requirements or side effects. This is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no redundant text. It is front-loaded with the action and includes only the essential additional return-value information, making it highly 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?
Despite being a relatively simple create tool, the description omits any parameter details or usage caveats. It does mention the return value, but the lack of parameter semantics and absence of guidance on required versus optional fields leaves the description incomplete for an agent to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'name' or 'description' parameters at all. The parameter names are self-explanatory, but the description fails to compensate for the lack of schema documentation, leaving parameter semantics entirely to inference.
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 'Create' with the resource 'Coolify project', clearly distinguishing it from sibling create tools like createApplication and createDatabase. Mentioning the return value of a project UUID adds precision about the tool's 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?
There is no guidance on when to use this tool versus alternatives such as createEnvironment or updateProject, nor are any exclusions or prerequisites provided. The context is clear only from the title and name, not from explicit 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?
Annotations already declare readOnlyHint=true, but the description adds no additional behavioral context beyond that. It does not disclose the effect of showSecrets (e.g., exposing sensitive values), any auth requirements, or limitations (e.g., not returning full configuration without the flag). This leaves important behavioral nuance unexplained.
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, front-loaded sentence with no filler. It wastes no words and is easy to parse, achieving maximum conciseness even if it is somewhat sparse.
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 minimal description, the agent cannot infer what 'details' are actually returned, how showSecrets changes the result, or how to find the correct UUID. For a tool with an optional flag that could expose sensitive data, this lack of context makes the description incomplete.
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 0%, so the description must compensate. It clarifies the purpose of the uuid parameter ('by UUID') but says nothing about showSecrets, leaving the boolean's meaning and effect ambiguous. The parameter names alone are insufficient for a confident invocation.
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 specific verb 'Get' plus resource 'database details' and identifier 'UUID'. This makes the tool's purpose unambiguous and distinct from siblings like listDatabases (which lists all databases) and createDatabase (which creates one).
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, it does not mention that listDatabases should be used to discover UUIDs first, or that databaseEnvs/databaseBackups provide related but different data. There is no mention of exclusions or prerequisite steps.
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 annotations already cover the read-only safety profile via readOnlyHint and openWorldHint. The description adds the 'currently running' state filter, which is useful behavioral context, but it does not disclose pagination behavior, result ordering, or the implications of the openWorldHint flag.
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 with no unnecessary words. It is concise and readable, though it sacrifices important detail; however, for its length it is 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's simplicity, the description is minimally viable, but it omits crucial details such as pagination, how results are scoped (e.g., across projects or apps), and how this differs from similar list tools. The annotations help with safety but not with invocation details.
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?
The schema contains two parameters, limit and offset, with no descriptions and 0% schema coverage. The description does not mention these parameters at all, so it fails to compensate for the lack of schema descriptions and provides no additional 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 action (list) and resource (deployments) with a specific state qualifier ('currently running'). However, it does not differentiate this from the sibling tool listAppDeployments, which could also list deployments, so it doesn't fully distinguish among alternatives.
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 phrase 'currently running' gives some context for when to use this tool, but there is no explicit guidance on when to choose this over alternatives like listAppDeployments or getDeployment, and no mention of exclusions or prerequisites.
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?
The annotation destructiveHint=false conflicts with the description listing 'delete' as an action, which implies a destructive operation. The description does not explain any other behavioral traits (e.g., side effects, permission requirements) and relies on the contradictory annotation. This is an annotation contradiction.
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 two sentences, front-loaded with the main purpose and then the action list. There is no filler or redundant information, making it concise and easy to scan.
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 10-parameter tool with five actions and no output schema, the description is too thin. It does not explain what each action returns, how resource/uuid are used, or the meaning of enabled/timeout/container. The contradiction with annotations further undermines the completeness of the behavioral 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 only 20%, so the description must compensate. It explains that create takes name, command, and frequency, and that all but list/create require task_uuid, adding meaning to key parameters. However, parameters like enabled, timeout, container, and resource remain undocumented in both the schema and the description, limiting compensation.
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 identifies the resource as 'scheduled tasks (cron jobs)' for application/service and enumerates the specific actions (list, create, update, delete, list_executions), giving clear operational scope. It distinguishes itself from sibling resource-management tools by focusing on scheduled tasks. The verb 'manage' is a bit broad, but the action list adds enough specificity.
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 states the targeted resource types (application/service) and lists the available actions, providing clear context for when this tool applies. It also notes that all actions except list/create require task_uuid, which is a useful usage rule. However, it does not explicitly mention alternative tools 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation contradiction: the description includes a 'delete' action (destructive operation), but annotations declare destructiveHint=false. This directly contradicts the structured safety metadata. No additional behavioral context (e.g., irreversibility, permissions) is provided.
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 compact: one sentence for the overall purpose, then a concise list of actions and their key prerequisites. It is front-loaded, with every clause contributing meaningful information and 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 11 parameters, low schema coverage, no output schema, and a contradictory annotation, the description leaves substantial gaps. It does not explain update semantics, file vs. persistent differences, optional parameters, or response behavior. The provided action-specific hints are helpful but insufficient for a tool of this complexity.
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 description adds conditional requirements not present in the schema: create needs 'type' and 'mount_path', while update/delete need 'storage_uuid'. This is valuable, but it ignores many other parameters (name, host_path, is_directory, content, resource_uuid), and with only 36% schema coverage it only partially compensates for the missing parameter documentation.
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 manages persistent volumes and file mounts for applications, databases, or services, and explicitly lists the actions (list/create/update/delete). This differentiates it from sibling tools by naming the storage resource type, though the verb 'manage' is somewhat generic.
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?
It provides clear context by specifying the target resource types (application/database/service) and the available actions, making it obvious when to use this tool. However, it does not explicitly mention when to avoid it or name alternatives, so it falls short of a 5.
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?
The annotations declare destructiveHint=false, but the description lists destructive actions like 'delete' and 'delete_execution', which directly contradicts the annotation. This is a serious inconsistency (annotation contradiction). The description also adds useful context about available actions and parameters, but the contradiction forces a score of 1 per the rubric.
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 two sentences, front-loaded with the primary purpose, followed by a concise enumeration of actions and key parameters. Every word earns its place, with no redundant filler. The structure makes it easy to scan quickly.
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 11 parameters, 6 actions, and no output schema, making it fairly complex. The description provides an overview of actions and key fields but does not specify which parameters are required per action, what each action returns, or error behavior. It is not fully complete, but it gives a sufficient starting point for an agent to explore further.
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?
With only 45% schema description coverage, the description partially compensates by explaining that frequency accepts a cron expression and listing optional fields (enabled, save_s3, s3_storage_uuid, databases_to_backup, dump_all, retention via extra). It does not elaborate on the meaning of each field, but it provides a useful summary that goes beyond the bare 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 tool's function: 'Manage scheduled backups for a database.' It then enumerates the specific actions (list, create, update, delete, list_executions, delete_execution), which fully distinguishes it from sibling tools like scheduledTasks. The verb 'Manage' plus the resource 'scheduled backups' makes the purpose 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 indicates the tool is for handling database backup schedules, which implies when to use it. However, it does not explicitly compare with alternatives (e.g., 'use scheduledTasks for non-backup tasks') or state when not to use it. The guidance is contextually clear but lacks explicit 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the annotations by listing a delete action while the annotations set destructiveHint=false. This is a serious inconsistency. The description does add useful behavioral details (secrets masking, parameter requirements for actions), but the contradiction overrides any positive contribution.
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 concise sentence that front-loads the purpose and then lists all actions with relevant notes. No wasted words; each clause provides essential 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?
For a tool with 5 actions and 9 parameters, the description covers the actions and key parameter requirements but omits details such as the semantics of is_literal and is_preview. There is no output schema, but the description partially addresses return behavior (secrets masking). Overall, 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 description adds action-specific parameter mapping (envs for bulk_update, env_uuid for delete, showSecrets for list), which is helpful beyond the sparse schema. However, schema coverage is only 33%, and the description does not explain key, value, is_literal, or is_preview for create/update, leaving gaps.
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 manages environment variables for a database and enumerates the supported actions (list, create, update, bulk_update, delete). This verb+resource pairing (Manage + database env vars) distinguishes it from sibling tools like applicationEnvs or serviceEnvs.
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?
Usage is implied: this tool is for database environment variables, but there is no explicit guidance on when to use this tool versus alternatives such as applicationEnvs or serviceEnvs. No exclusions or when-not-to-use conditions are stated.
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 annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds minimal context, such as 'all domains' implying no filtering and 'on a server' indicating scope, but does not disclose return format, pagination, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core purpose, matching the tool's simple 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 no output schema, the description does not explain return values, and the parameter semantics are absent. While the tool is simple, the lack of information about what the tool returns and how to provide the uuid leaves clear gaps for an agent trying to invoke it correctly.
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 0% with one required parameter 'uuid'. The description only implies that the uuid references a server via 'on a server', but does not explicitly explain the parameter's meaning, format, or constraints, failing to compensate for the schema's lack of detail.
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's function with a specific verb 'List' and a distinct resource 'domains' scoped to 'a server'. This distinguishes it from server-related siblings like getServer or listServers, making the purpose 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 vs alternatives. There are no prerequisites, exclusions, or references to related tools, leaving the agent to infer usage solely from the tool name and description.
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 annotations already declare destructiveHint=true, covering the destructive nature. The description adds 'running' as a qualifier, but does not disclose additional behavioral traits such as idempotency, side effects on other resources, or whether the cancellation is reversible. With annotations present, the bar is lower, and the description contributes limited extra value.
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, front-loaded with the verb and resource. It contains no unnecessary words or filler, achieving maximum efficiency.
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 one parameter and no output schema, the description is minimally adequate but lacks detail on expected outcomes, error conditions, and any post-cancellation state. The presence of annotations covers the destructive hint, yet the description does not explain what success looks like or when the deployment is considered 'running'.
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 0%, so the description must compensate for explaining the 'uuid' parameter. It only repeats that the operation is 'by UUID', adding minimal meaning beyond the parameter name. No guidance on format, lookup methods, or constraints is provided.
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 'Cancel a running deployment by UUID' uses a specific verb ('cancel'), identifies the target resource ('deployment'), and scopes it ('running', 'by UUID'). This clearly distinguishes it from siblings like 'deploy' or 'getDeployment'.
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 versus alternatives (e.g., stopApplication, redeployProject). It does not mention exclusions, prerequisites, or alternative scenarios. The simple context implies usage for cancelling an ongoing deployment, but no comparative guidance is 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. It adds the specific resource types included (applications, databases, services), which is useful, but it does not disclose potential response size, pagination, or filtering behavior. The description is consistent with annotations; no contradiction.
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 phrasing. It efficiently conveys the tool's purpose and resource scope.
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 list tool with one parameter and no output schema, the description covers the core purpose but misses parameter semantics and usage guidance. The ambiguity with the sibling tool listResources further reduces completeness, making this a minimally viable description rather than a fully self-contained one.
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?
The input schema has one required parameter (uuid) with 0% description coverage. The description does not explain that uuid refers to the server identifier, leaving the agent to infer it from the tool name and resource context. This is a clear gap that the description should have compensated for.
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 resources (applications, databases, services) running on a server' uses a specific verb and resource, clearly defining a consolidated resource listing scoped to a server. It distinguishes from getServer (server info) and from listApplications/listDatabases/listServices (singular resource types), though it may overlap with listResources.
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. The description implies a server-scoped resource listing but does not mention when to prefer it over calling individual list tools or how it relates to listResources. No exclusions or alternative names 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 adds no behavioral context beyond what annotations already provide (readOnlyHint=false, destructiveHint=false, idempotentHint=true). It does not mention side effects, error handling, permissions, or any operational nuances, so the annotations carry the full transparency burden.
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, front-loaded with the key action and resource. Every word contributes: it states the verb, object, and the specific attributes. No superfluous content.
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 CRUD update, the description is adequate but minimal. It lacks context such as whether the project must exist, what happens on invalid input, or that uuid identifies the target. The annotations and schema cover some aspects, but the description leaves gaps for an agent relying on it alone.
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 0%, so the description must compensate. It mentions 'name or description' as updatable fields but does not explain the required 'uuid' parameter's role as the identifier. This leaves part of the parameter semantics unexplained.
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 ('Update') with a clear resource ('project') and explicitly lists the mutable fields ('name or description'). This clearly distinguishes it from sibling tools like createProject, deleteProject, or updateApplication.
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 changing a project's name or description, but it provides no explicit guidance on when to choose this tool over createProject, deleteProject, or updateApplication. There is no mention of 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?
Annotations already declare readOnlyHint=false and destructiveHint=true, establishing that this is a mutating and potentially destructive operation. The description adds no extra context about side effects, such as downtime, the order of stop/restart, or whether changes are reversible, which would be valuable for a destructive 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, front-loaded sentence with no filler. Every word contributes to conveying the tool's 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?
The tool is simple with two required parameters and clear annotations, but the description omits details about the outcome (e.g., whether it returns an updated service object, if it's synchronous) and potential side effects. Given the destructive hint, a bit more context would round it out, but it is otherwise adequate for a control 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?
With 0% schema description coverage, the description must compensate. It does clarify that 'uuid' identifies a service and 'action' takes values start/stop/restart, adding semantic meaning beyond raw schema types. However, it does not elaborate on any constraints or the meaning of each action beyond the enum.
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 'Start, stop, or restart a service by UUID' clearly states the specific verbs and the resource type, distinguishing it from sibling tools that operate on applications or databases. It is unlikely to be confused with other lifecycle operations.
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?
Usage is implied: use this tool when you need to control a service. However, there is no explicit guidance on when to prefer this over sibling tools like startApplication/stopApplication or controlDatabase, nor any mention of prerequisites.
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?
Annotations already indicate this is a write operation (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds the requirement of a project UUID, which is a constraint rather than a behavioral disclosure. It does not contradict the annotations, but also does not add significant behavioral context beyond what annotations provide.
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 two short sentences, directly to the point, with no filler or redundancy. It front-loads the core purpose and includes the most critical prerequisite.
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 only sparse annotations, the description provides minimal context. It does not explain what happens upon creation, what the response looks like, or what the optional 'name' parameter does. The description is adequate for a trivial create operation but leaves important aspects undocumented.
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?
The schema has no descriptions for the parameters, and the description only clarifies that 'uuid' refers to the project UUID. The 'name' parameter is left entirely unexplained. Since schema coverage is 0%, the description does not sufficiently compensate for the missing parameter semantics.
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 the resource ('a new environment in a project'), which distinguishes it from sibling tools like createProject or createServer. It also specifies a key prerequisite (the project UUID), making the purpose immediately clear.
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 tells the agent that this tool is for creating an environment in a project and requires the project UUID. It does not explicitly mention alternatives or when not to use it, but the context is clear enough that an agent can infer the appropriate use case. However, there is no guidance on edge cases like existing environments or validation.
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?
Annotations already indicate readOnlyHint=false (write) and destructiveHint=false. The description adds the SSH private key prerequisite, which is useful, but it does not disclose other behavioral aspects such as provisioning time, required permissions, or return format. The additional context beyond annotations is limited.
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 just two sentences, efficiently stating the primary purpose and a key requirement. It is concise, front-loaded, and every sentence earns its place.
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 9 parameters, no output schema, and zero parameter descriptions, this description is too brief. It explains only one prerequisite and omits return value expectations, likely because it is a create operation, and ignores most parameters and potential edge cases. It is minimally viable but has significant gaps.
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?
The schema has 9 parameters with 0% description coverage. The description only mentions 'private key UUID', giving minimal meaning for that parameter, but leaves the other eight parameters (ip, name, port, user, proxy_type, description, is_build_server, instant_validate) unexplained. It fails to compensate for the missing schema descriptions, especially for ambiguous fields like is_build_server and instant_validate.
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 'Create a new server', specifying the verb and resource. This distinguishes it from sibling tools focused on other resources (createProject, createService, createDatabase) and related server tools like validateServer or updateServer.
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 (to create a server) and provides a prerequisite ('Requires a private key UUID for SSH access'), giving some contextual guidance. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or comparisons to sibling tools like createService or createPrivateKey.
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 declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds no additional behavioral context—no mention of return format, error handling, or what happens if the UUID is not found. It effectively restates the tool's purpose without enriching 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.
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 directly states the action and parameter, achieving maximum 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, but there is no output schema or description of what 'details' are returned. Given the many sibling tools, the description could clarify that this returns general server info (not resources or domains) or that it returns the full server object. It is minimally adequate but leaves some ambiguity about the return value.
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?
With schema description coverage at 0%, the description must compensate. The phrase 'by UUID' clarifies the parameter's role as the server identifier, giving meaning beyond the bare schema definition. For a single string parameter, this is adequate, though it could be more explicit about the UUID format or source.
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 'Get server details by UUID' clearly identifies the action (get), the resource (server), and the scope (by UUID). It distinguishes this from listServers (which lists all servers) and more specific getters like getServerResources or getServerDomains.
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 that this is for a single server's full details, nor does it recommend using listServers for enumeration or getServerResources for resource usage.
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?
Annotations already disclose that this is a mutating (readOnlyHint=false) and destructive (destructiveHint=true) operation. The description adds no extra behavioral context, such as expected downtime or order of operations, but it does not contradict the annotations either.
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: 'Restart an application by UUID.' It is front-loaded, contains no redundant words, and is suitably sized for the tool's simplicity.
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 operation with one parameter, the description is adequate but lacks important context such as prerequisites, side effects, or return behavior. Since no output schema exists and annotations are present, the description could have mentioned that restarting causes downtime or requires a running app, but 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?
The input schema only defines 'uuid' as a required string with no description. The description's 'by UUID' clarifies that the parameter identifies the application, but adds minimal meaning beyond the tool name and schema. Since there is only one parameter and 0% schema coverage, the description partially compensates but does not specify format or constraints.
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 restarts an application, using the specific verb 'restart' and specifying the resource ('application') and identifier ('by UUID'). It distinguishes from siblings like startApplication and stopApplication by naming the exact action, and from restartProjectApps by referring to a single 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 is provided on when to use this tool versus alternatives such as restartProjectApps, or how it relates to startApplication/stopApplication. The description does not mention prerequisites (e.g., app must exist or be running) or contexts where it should be 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?
Annotations already indicate the safety profile (readOnlyHint false, idempotentHint true, destructiveHint false). The description adds the 'force rebuild' behavior, which is useful, but it does not explain what force rebuild entails or any side effects. Some value is added beyond 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 exceptionally concise: two short sentences, front-loaded with purpose. Every word earns its place, with no unnecessary elaboration.
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 three parameters and no output schema, yet the description only covers the core start action and force rebuild. It omits important context about what happens when starting, behavior if already running, and the role of instant_deploy. Given the complexity of the surrounding toolset, this 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?
The input schema provides no descriptions, and the description explains 'uuid' and 'force' only implicitly. The 'instant_deploy' parameter is completely unexplained. With 0% schema description coverage, the description fails to sufficiently compensate for the undocumented 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 the tool's function with a specific verb and resource: 'Start an application by UUID.' It is distinct from sibling tools like stopApplication, restartApplication, and deploy. The optional force rebuild adds useful specificity.
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 implied usage is to start an application, but there is no explicit guidance on when to use this versus alternatives like restartApplication or deploy. No exclusions or conditions 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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write operation. The description adds no further behavioral context (e.g., reversibility, side effects) beyond the bare action.
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, clear sentence. Front-loaded with the verb and resource, with zero redundant 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 one-parameter action, the description is minimally sufficient. However, it omits any detail about side effects, prerequisites, or what happens after stopping, and does not leverage the openWorldHint annotation.
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 0% coverage and only a 'uuid' parameter. The phrase 'by UUID' adds the semantic that the parameter is the application identifier, but it does not explain what a UUID is or how to obtain it. It barely compensates for the lack of schema 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 ('Stop') and the resource ('an application'), with a specific identifier ('by UUID'). This distinguishes it from siblings like 'startApplication' and 'stopAllApplications'.
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. It does not mention prerequisites, exclusions, or relationships to similar tools like 'restartApplication' or 'deleteApplication'.
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?
Annotations declare readOnlyHint=true, so the read-only nature is already known. The description adds that validation covers connection and configuration, providing some context beyond annotations, but does not explain what the validation result looks like or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of ten words, front-loaded and without redundancy. Every word contributes to the core meaning.
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 tool with readOnlyHint and openWorldHint annotations, the description sufficiently covers purpose and parameter. The lack of an output schema is acceptable for a validation tool, and the behavior is adequately implied.
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 description explicitly mentions 'by UUID', clarifying that the uuid parameter is the server identifier. This adds meaning beyond the schema, which only specifies type string, and is especially valuable given 0% schema description 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 tool validates server connection and configuration by UUID, with a specific verb and resource. It does not explicitly differentiate from sibling tools like diagnoseServer, but the scope is clear 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?
No guidance is provided on when to use this tool versus alternatives like getServer or diagnoseServer. The description only states what it does, not the context or exclusions.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, indicating this is a mutating operation with potential side effects. The description does not add further behavioral details like downtime impact or async behavior, but it is consistent with the 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 sentence that is direct and free of filler. It earns its place by conveying the core functionality without unnecessary detail.
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 with only two parameters, and annotations provide safety hints. However, the description does not mention important context like whether operations are asynchronous, if there are prerequisites (e.g., database must exist), or what response to expect, leaving gaps for an agent.
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?
With 0% schema description coverage, the description should compensate for parameter meaning, but it only mentions 'by UUID' and relies on the schema's enum for action. It does not explain UUID format or the semantics of each action beyond their names.
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's function: start, stop, or restart a database by UUID. It uses specific verbs and names the resource, distinguishing itself from sibling tools that target applications or services.
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 context for when to use the tool (to control a database lifecycle) and identifies the required identifier (UUID). However, it does not explicitly mention alternatives or exclusions, such as why you might use controlService or startApplication instead.
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?
Annotations already declare readOnlyHint=true, covering that this is a read operation. The description adds context about key usage but does not disclose pagination behavior (despite limit/offset params) or whether the response exposes sensitive key material. It provides some value but lacks richer behavioral detail beyond 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 two sentences long, front-loaded with the action, and includes only relevant context. Every word earns its place with no unnecessary 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?
For a simple list tool, the description gives a clear purpose but omits important details: it claims to list 'all' keys yet has limit/offset parameters, suggesting pagination that is not mentioned. Without an output schema, it also fails to describe the return format. Gaps exist, but the tool's simplicity and annotations keep it adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (limit, offset) with no descriptions, and schema coverage is 0%. The description does not mention pagination or how these parameters affect results, so it fails to compensate for the missing schema details, leaving parameters entirely unexplained.
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 SSH private keys' with a specific verb and resource. It also adds context that keys are used for server authentication and deploy keys, which distinguishes this list operation from sibling tools like createPrivateKey, getPrivateKey, updatePrivateKey, and deletePrivateKey.
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 makes clear it should be used to list all SSH private keys, providing explicit context. However, it does not mention alternatives like getPrivateKey for individual keys or specify when not to use this tool, so it stops short of full 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?
Annotations already declare readOnly=false, destructive=false, idempotent=true, and openWorld=true. The description adds context about the 'extra' catch-all parameter, which aligns with the openWorld hint, but does not disclose other behavioral traits like side effects or prerequisites. No contradiction with 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 two tightly written sentences with no fluff. It front-loads the core purpose and then clarifies the extensibility mechanism.
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 moderate complexity (7 parameters, no output schema). The description is clear enough to use, but it does not explain whether updates are partial or full, what happens on update, or any prerequisites. Annotations cover safety and idempotency, so the description is minimally complete for basic usage.
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 only 14% (only 'extra' has a description). The description says 'Common fields are exposed' but does not enumerate or explain those fields (name, image, is_public, etc.). It introduces 'extra' as a catch-all, but this only minimally compensates for the lack of parameter details.
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 'Update a database's configuration by UUID', using a specific verb and resource. It distinguishes from sibling tools like updateApplication or updateService by targeting databases specifically.
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 that 'Common fields are exposed; any other Coolify database field can go in extra', giving some usage guidance but not explicit when-to-use vs alternatives. It does not mention when to avoid this tool or use controlDatabase or deleteDatabase instead.
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?
Annotations already indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the behavioral constraint that the private_key must be the full PEM-encoded key, which is useful beyond annotations, but does not disclose other side effects or prerequisites.
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 concise sentences front-load the purpose and provide a critical parameter detail 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?
Given the simple 3-parameter create operation and annotation coverage, the description is adequate but does not mention the return value or any caveats about the key creation process. With no output schema, a brief note about the response could 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 0%, so the description must compensate. It explicitly explains the required private_key parameter, noting the PEM-encoded format, which adds meaning beyond the schema. However, name and description parameters are not described, though they are self-evident from their names.
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 'Create a new SSH private key' with a specific verb and resource, clearly distinguishing it from sibling tools like listPrivateKeys, getPrivateKey, updatePrivateKey, and deletePrivateKey.
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 verb 'Create' implies this is for new keys, and the note about the private_key field provides input guidance. However, there is no explicit discussion of when to use this versus the update or delete alternatives, so it's only implied usage.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description need not restate that. It adds value by naming the resources that can be deleted, but it says 'optionally' while schema defaults are true, meaning they are deleted by default. This mismatch reduces transparency about the actual default behavior.
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?
One concise sentence that front-loads the core action and then enumerates optional deletions. No redundancy or filler, every word contributes to understanding.
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?
With 5 parameters and no output schema, the description is sparse. It covers the main action and some optional resources but omits docker_cleanup and does not describe response behavior or reversibility. Given the destructive nature and multiple flags, more context 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 description coverage is 0%, so the description must compensate. It covers uuid, delete_volumes, delete_configurations, and delete_connected_networks implicitly, but docker_cleanup is not mentioned. It also does not clarify that the boolean parameters default to true, leaving ambiguity about parameter semantics.
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 specific: 'Delete an application by UUID.' It clearly states the verb and resource, and distinguishes from sibling tools like updateApplication or stopApplication. Mentioning optional deletion of volumes, configurations, and networks further clarifies 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?
Usage is implied by the tool's name and the context of application management, but there is no explicit guidance on when to use it versus alternatives, prerequisites, or when not to use it. No exclusions are given, but it is obvious for a delete operation.
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?
Annotations already declare readOnlyHint=true, and the description adds the behavior of optional field selection. However, it does not disclose behaviors around showSecrets or default response contents. With annotations covering the safety profile, this 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?
A single sentence with no filler. Front-loads the verb and resource, 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?
With annotations covering read-only behavior and a relatively simple tool, the description is nearly complete. It could explain showSecrets or return details, but the core purpose is clear and the schema provides parameter types.
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 0%, so the description must compensate. It clarifies uuid as an identifier and mentions 'optional field selection' for the fields parameter, but showSecrets is entirely undocumented. Partial compensation is insufficient for three 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 uses a specific verb ('Get') and resource ('application details') with a clear identifier ('by UUID'), distinguishing it from sibling tools like listApplications. The optional field selection is mentioned, adding further specificity.
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 the tool (when you have a UUID), but does not explicitly mention alternatives or exclusions. It gives some context but lacks direct guidance versus listing tools like listApplications.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the return fields, which is useful, but it does not disclose pagination behavior or how the limit/offset parameters affect the result set, which is a notable gap.
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 two concise sentences that front-load the main purpose and immediately state the return fields. Every word is purposeful, 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 list tool with readOnly and openWorld annotations, the description covers the essential return fields and scope. However, it omits any mention of pagination semantics related to limit/offset, and 'all' may be misleading given these parameters imply a paged result.
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 0%, and the description makes no mention of the limit and offset parameters. The schema only provides names and types, leaving the semantics (e.g., pagination) undocumented. The description should compensate but does not.
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 Coolify projects' with a specific verb and resource, and lists the returned fields (UUID, name, description, environments). This distinguishes it from sibling tools like listApplications or listDatabases by targeting projects specifically.
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 usage is implied: use this to list projects. However, it offers no explicit guidance on when to choose this over alternatives like listResources or listEnvironments, nor any exclusions or prerequisite 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?
The description adds a useful behavioral note that list masks secrets unless showSecrets is set, which is beyond what annotations provide. However, it does not elaborate on permissions, reversibility, or side effects, and the annotations (readOnlyHint=false, destructiveHint=false) already indicate mutability, so the added value is modest.
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, tightly packed sentence that lists actions and key usage notes without superfluous words. It is well-structured and front-loads the core purpose, earning every word.
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 covers the action list but omits critical context such as output format, parameter details, authentication, error handling, and relationships to other resources. Given 9 parameters and no output schema, it lacks the richness needed for an AI agent to invoke it correctly in all scenarios.
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?
With only 33% schema description coverage, the description needed to compensate by explaining key parameters. It clarifies the purpose of envs (for bulk_update) and env_uuid (for delete), but leaves key, value, is_literal, is_preview, and showSecrets semantics unexplained, which is insufficient given the low 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 uses the specific verb 'Manage' with the resource 'environment variables for a service', clearly distinguishing it from sibling tools like applicationEnvs and databaseEnvs. It also enumerates all actions (list, create, update, bulk_update, delete), making the tool's scope unambiguous.
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 service' provides clear context for when to use this tool, differentiating it from application or database env var tools. It also gives action-specific hints (e.g., 'bulk_update (pass envs array)', 'delete (needs env_uuid)') that guide usage, though it lacks explicit exclusions or alternative mentions.
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?
Annotations already indicate this is a write operation (readOnlyHint=false), non-destructive (destructiveHint=false), and idempotent. The description adds little behavioral context beyond that, such as side effects, partial update behavior, or authentication requirements. It does not contradict the 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?
Two brief sentences with no wasted words. The key operation is stated first, followed by the note about extra fields. This is appropriately concise for an MCP tool description.
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?
With 8 parameters, one required, and no output schema, the description is adequate but not rich. It covers the main purpose and the extra mechanism, but does not mention return values, partial update semantics, or any prerequisites. The annotations provide some context, but the lack of detail on field specifics and response format leaves gaps for an agent.
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 low (13%), but the description adds meaning by noting that common fields are exposed and other Coolify server fields go in 'extra'. This clarifies how to use the extra parameter, but individual property semantics for ip, name, port, user, etc., are not elaborated, leaving the agent to infer from property names.
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 'server', with the specific identifier 'UUID'. It distinguishes itself from sibling tools like createServer, deleteServer, and getServer by focusing on updating an existing 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 context of updating a server by UUID is clear, but there is no explicit guidance on when to use this tool versus alternatives like createServer or deleteServer. It does not state exclusions or specific scenarios, leaving usage implied rather than explicit.
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?
Annotations already declare this as a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false), so the safety profile is covered. The description adds value by explaining the Docker Compose mode and version-specific behavior, but it does not disclose side effects, asynchronous deployment behavior, or return format, which would be useful given no output 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 two concise, front-loaded sentences. The first states the action and modes, the second adds requirements and a version note. No filler or redundant information; every sentence 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?
For a tool with 13 parameters and no output schema, the description is adequate but incomplete. It covers core purpose and required params, but lacks detail on many optional parameters and what the tool returns. The annotations help with safety, but return value and post-creation behavior are absent, making full autonomous invocation challenging.
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 0%, so the description must compensate. It explains docker_compose_raw and clarifies the requirement/alternative for environment_name vs environment_uuid, but only touches 5 of 13 parameters. Many important parameters like type, instant_deploy, destination_uuid, and urls remain unexplained, leaving agents to guess their semantics.
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's purpose with a specific verb and resource: 'Create a one-click service (database, cache, etc.) or a Docker Compose deployment'. It also distinguishes itself from sibling tools by noting that since Coolify v4.1, Docker Compose deployments are services, not applications, which prevents confusion with createApplication.
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?
It provides clear context for when to use: for one-click services or Docker Compose deployments, and implicitly indicates not to use for applications post-v4.1. However, it does not explicitly name alternative tools (e.g., createDatabase) or state exclusions, leaving some ambiguity for edge cases.
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 readOnlyHint annotation already indicates a safe read operation. The description adds the scope that repositories are 'accessible to a GitHub App', which clarifies the subset returned. However, it does not disclose additional behavioral traits such as pagination, authentication needs, or what 'accessible' means in practice.
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 redundant words. The verb 'List' is present at the start and every word contributes meaning.
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 read-only list tool with one parameter and existing annotations, the description covers the essential purpose. It does not explain the return format, but given the absence of an output schema and the obvious nature of the result (a list of repositories), the description is adequate.
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 0%, but the single parameter (github_app_id) is self-explanatory and the description links it to the GitHub App. The description does not explicitly state where the ID comes from or its format beyond the schema's integer type, but the naming and context make the meaning reasonably clear.
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 'List' and identifies the resource as 'repositories accessible to a GitHub App', which clearly distinguishes it from sibling tools like getGithubAppBranches (branches) and listGithubApps (the apps themselves).
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 (when you need repositories for a GitHub App) but provides no explicit guidance on when not to use, nor does it reference alternatives. It does not mention exclusions or comparisons with 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?
The description adds a behavioral note about asking for confirmation on supporting clients, which goes beyond the annotations. However, it does not disclose other important traits such as potential downtime, restart of all apps, or asynchronous completion. Annotations already indicate a write operation (readOnlyHint=false), so no contradiction, but the additional disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no filler. Every sentence adds value: the first states what it does, the second notes the confirmation behavior.
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 high-impact operation that redeploys all applications, the description lacks critical context: side effects (downtime, restarts), whether it returns any identifiers, prerequisites, or how it interacts with existing deployments. There is no output schema to compensate, so the description should provide more detail.
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?
With only 33% schema coverage, the description compensates somewhat by explaining 'environment' as optional and scoping to a single environment, and 'project_uuid' is implied by 'a project'. However, it adds no details about the 'force' parameter beyond the schema's existing description, and the low coverage means more semantic explanation would be beneficial.
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's action: 'Trigger a deployment for every application in a project' with an optional environment scoping. This specific verb+resource combination distinguishes it from sibling tools like 'deploy' (which likely handles a single application).
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 scope is clearly implied: use this tool when you need to redeploy all applications in a project or all apps in a single environment. It does not explicitly mention alternatives or exclusions (e.g., 'use deploy for a single app'), but the wording makes the intended use obvious.
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 discloses key behavioral traits: list masks secrets unless showSecrets is set, upsert is idempotent (create or update by key), and delete requires env_uuid. These go beyond the annotations (readOnlyHint false, destructiveHint false) by offering operational details. However, it doesn't describe the full behavior of create/update or 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, information-dense sentence that leads with the core purpose and then enumerates actions. No redundant or filler 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?
With 10 parameters, 6 actions, and no output schema, the description covers actions but omits parameter requirements per action (e.g., that create/update likely need key and value). It also doesn't describe return values. More detail is needed for an agent to invoke this correctly.
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 coverage is only 30%, and the description only clarifies a few parameters: showSecrets, envs, and env_uuid. It fails to explain key, value, is_literal, is_preview, is_multiline, which are undocumented in the schema. For a 10-parameter tool, this is insufficient compensation.
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 manages environment variables for an application, using the verb 'Manage' and resource 'application env vars'. It distinguishes from sibling tools like databaseEnvs and serviceEnvs 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that this is for application environment variables, differentiating it from databaseEnvs/serviceEnvs. It also gives action-specific usage notes like 'list (secrets masked unless showSecrets)' and 'delete (needs env_uuid)', but does not explicitly say 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds the contextual constraint 'accessible to a GitHub App', which is useful, but it doesn't disclose any additional behaviors such as authentication requirements, rate limits, or output structure. It does not contradict 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 that conveys the essential purpose without any fluff. 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 simple list tool with annotations and no output schema, the description is sufficient to understand the tool's basic function and the GitHub App access scope. It does not describe return format, but 'List branches' implies a list of branch names, which is adequate for this simplicity level.
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 0% and the description does not explain any of the three parameters. 'github_app_id' is hinted at by the tool name and description, but there is no explicit guidance on how repo, owner, and github_app_id relate or are used.
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 ('List') and resource ('branches'), and adds scope ('accessible to a GitHub App'), which clearly distinguishes it from sibling tools like getGithubAppRepositories that list repositories.
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 provides clear context that this tool lists branches within the context of a GitHub App's access. It doesn't explicitly state when not to use it or name alternatives, but no competing branch-listing sibling exists, so the intended usage is clear.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds behavioral context about pagination using skip/take, which goes beyond the annotations. However, it does not describe ordering, return format, or other edge behaviors, so it adds only moderate value.
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 action and resource, then adds the pagination detail. Every word earns its place; no filler or repetition.
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 straightforward read-only list operation with annotations and schema defaults, the description is functionally adequate. However, it does not differentiate from the sibling 'listDeployments' and omits mention of default values or ordering, leaving minor gaps.
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 0% description coverage, so the description must compensate. It clarifies that 'uuid' identifies the application and that 'skip/take' are pagination parameters. Although not deeply detailed, this is sufficient given the self-explanatory parameter names.
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), the resource (deployments for an application), and a key constraint (pagination). It is specific enough to be understood, but it does not explicitly differentiate itself from the sibling tool 'listDeployments', 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 phrase 'for an application' implies the tool is scoped to a specific application, but there is no explicit guidance on when to use this vs. alternatives like 'listDeployments'. No exclusions or alternative tool references are provided.
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?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds little beyond the purpose; it doesn't disclose pagination behavior or the fact that limit/offset control results. With annotations present, the lack of extra behavioral detail is acceptable but not exceptional.
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 two concise sentences, front-loaded with the main action. Every word adds value, with no redundant information.
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 readOnlyHint and no output schema, the description adequately conveys the main return value ('GitHub Apps'). It doesn't explain pagination effects or the exact scope, but the overall context is sufficient 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, and the description does not explain the 'limit' and 'offset' parameters. While these are common pagination parameters, the description does nothing to clarify their role, leaving the agent to infer semantics. This is a clear gap.
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') and the resource ('all configured GitHub Apps'), which is specific and distinguishes it from siblings that operate on branches or repositories. The additional purpose note ('Used for private repository access') adds useful context.
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 gives a clear context for use ('Used for private repository access'), implying when this tool is relevant. However, it does not explicitly name alternatives or exclusions, such as using getGithubAppBranches or getGithubAppRepositories for related but different needs.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds that deletion is targeted by pull_request_id but does not disclose side effects, permanence, or impact on related resources beyond the annotation. No contradiction found.
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 begins with the action verb, contains no unnecessary words, and effectively communicates the tool's purpose.
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 delete operation with two parameters and no output schema, the description adequately covers the essential purpose and key parameter. It does not discuss return values, but that is acceptable without an output schema.
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 covers uuid with a description but leaves pull_request_id undocumented. The description clarifies that the operation targets an application by pull request id, adding meaningful semantics to both parameters. It does not elaborate on relationships or constraints but compensates well for the schema gap.
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 ('Delete'), identifies the resource ('a preview deployment of an application'), and the selection method ('by pull request id'). This clearly distinguishes it from sibling tools like cancelDeployment or deleteApplication.
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 the tool (to remove a preview deployment for a given pull request) but does not explicitly mention alternatives or exclude scenarios. There is no guidance on 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a destructive operation, but the description adds a meaningful, specific consequence: 'Not recoverable from Coolify once gone.' This goes beyond the generic destructiveHint by stating permanence, which is highly relevant for an AI agent deciding to invoke the 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 consists of two short, efficient sentences. The action and resource are front-loaded, and the crucial irreversibility warning is appended without redundancy. No word is wasted.
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 delete operation with one parameter, annotations, and no output schema, the description covers the core purpose and the most critical behavioral consequence (permanent deletion). It does not discuss error handling or idempotency, but given the tool's simplicity, the description is sufficiently 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 provides no description for the uuid parameter, and schema description coverage is 0%. The description does clarify that the UUID identifies which key to delete, offering partial compensation. However, it does not specify the UUID format, origin, or validation rules, leaving gaps for a single parameter.
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 ('Delete'), the resource ('SSH private key'), and the identifier ('by UUID'). This unambiguously distinguishes it from sibling tools like listPrivateKeys, createPrivateKey, getPrivateKey, and updatePrivateKey.
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?
Usage is implied by the verb and resource, but there is no explicit guidance on when to use this tool versus alternatives (e.g., updatePrivateKey for modifying, listPrivateKeys for viewing). The 'Not recoverable' warning provides a cautionary note but does not offer clear when-to/when-not-to 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?
The annotation already marks destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds only the identifier method ('by UUID') and does not disclose additional behavioral traits such as permanence or cascading effects. While not contradictory, it contributes minimal context beyond the 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 that directly states the action and target. There is no redundant information or 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?
For a simple destructive operation with one required parameter and no output schema, the description provides the essential information. However, it could mention that the deletion is permanent or may affect associated resources, though the annotations already flag destructiveness.
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 a single required parameter 'uuid' with no description. The description's mention of 'by UUID' clarifies that the parameter is the server's UUID, adding semantic meaning beyond the schema's bare type string.
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 'Delete' and clarifies the resource as 'a server' with the method 'by UUID', clearly distinguishing it from createServer, updateServer, getServer, and listServers. This is a specific, actionable statement.
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, but the tool name and description make its use unmistakable for deleting a server. It is an implied usage rather than explicit when-to-use 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?
Annotations already mark it read-only, so no safety ambiguity. The description adds value by disclosing that it includes the most recent failed deployment's log tail and suggested next actions, which is non-obvious behavior. It doesn't mention any edge cases (e.g., if no failed deployment exists), but the core behavior is clear.
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, clear subject, no redundant phrasing. Lists contents in a structured way.
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 diagnostic aggregator, the description covers purpose, input, and output components. Without an output schema, it doesn't need to detail shape. The absence of any mention of error cases or response format is a minor gap, but the tool is well-specified for its scope.
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 descriptions cover both parameters fully (identifier format with UUID/name/domain, log_lines with min/max/default). The description repeats the identifier pattern but adds nothing beyond the schema. Baseline 3 applies due to 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 uses the specific verb 'Diagnose' and enumerates concrete data points: current status, latest deployments, failed-deployment log tail, runtime logs, and suggested next actions. This clearly distinguishes it from siblings like getLogs or getApplication, which are single-purpose.
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 is a one-call aggregate ('in one call'), but does not explicitly state when to prefer it over getLogs/getApplication or when not to use it. No alternatives are named. This is implied, not explicit.
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?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds meaningful context by specifying that it aggregates resource status, domains, and suggested next actions, which goes beyond a simple read operation. No contradiction with 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, well-structured sentence that front-loads the verb and resource, then uses a colon to list the tool's outputs. Every word contributes value, and it is neither verbose nor under-specified.
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?
With one parameter, read-only annotations, and no output schema, the description provides a reasonable overview of what the tool returns. However, it could be more complete by detailing the format of the status breakdown or the nature of the suggested next actions, and any practical constraints like server connectivity.
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 the single parameter as 'Server UUID, name, or IP' with 100% coverage. The description only restates this format without adding additional detail, 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 uses a specific verb ('diagnose') and resource ('server'), and clearly enumerates what it returns: running resources with status breakdown, configured domains, and suggested next actions. This distinguishes it from sibling tools like getServer, getServerResources, and getServerDomains.
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?
Usage context is implied through the diagnostic purpose and sibling tool names, but the description does not explicitly state when to use this tool versus alternatives such as getServer or getServerResources. No exclusions or alternative tool recommendations 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?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds that it returns 'status and logs,' which is useful behavioral context, but it does not disclose return format, error behavior, or potential pagination. With annotations covering safety, this is acceptable but not richly 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?
The description is a single concise sentence that front-loads the key information: action, resource, and identifier. No wasted 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?
For a simple one-parameter read tool, the description sufficiently covers purpose and key return content ('status and logs'). It lacks details on error cases or log pagination, but given the tool's simplicity and the absence of an output schema, this is a minor gap.
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 only defines uuid as a string with no description. The description compensates by explaining that uuid is the deployment identifier, making the parameter's purpose clear. This adds meaning beyond the schema despite the 0% schema description 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 the tool's action ('Get'), resource ('deployment'), and scope ('status and logs') with an identifier ('by UUID'). It distinguishes itself from siblings like listDeployments and getLogs by specifying a unique deployment lookup.
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: call with a deployment UUID to retrieve status and logs. However, it doesn't explicitly state when to use this vs alternatives like getLogs or listDeployments, nor does it mention any exclusions or prerequisites.
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?
Annotations already cover safety (readOnly=false, destructive=false, idempotent=true). The description adds valuable context by explaining that unknown fields can be passed via 'extra', which aligns with and operationalizes the openWorldHint annotation. No contradiction.
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 compact sentences, front-loaded with the main action. The second sentence efficiently explains the extensibility mechanism. No filler or redundant information.
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 update-by-UUID tool with four annotations and a schema, the description is largely sufficient: it identifies the resource, the required UUID, and how to handle additional fields. It does not mention return value, but no output schema exists and the tool's purpose 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?
With schema description coverage at only 20%, the description must compensate. It explains that 'extra' accepts 'any other Coolify service field', giving concrete examples. However, it does not elaborate on the meaning/format of 'name', 'description', 'instant_deploy', or how they interact, leaving the other four parameters under-specified.
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 'Update a service by UUID' — a specific verb ('Update') and resource ('service'), distinguishing it from sibling update tools for applications, databases, servers, etc. It also clarifies the parent domain by referencing 'Coolify service field'.
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: use exposed common fields for typical updates and the 'extra' object for any other Coolify service fields. However, it does not explicitly contrast with alternatives (e.g., createService, controlService) or state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that fields not valid for the chosen type are ignored, adding a useful behavioral detail beyond the annotations. Annotations already indicate readOnlyHint=false and destructiveHint=false, so the write nature is known. It does not discuss error cases or side effects, but the annotation coverage lowers the bar, making this a 3.
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 dense paragraph but every sentence adds value, laying out type-specific requirements and the 'extra' field. It is long because the tool is complex, but it is efficiently packed and not verbose. A bulleted list would improve structure, so it earns a 4.
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 complexity and no output schema, the description is comprehensive: it explains all type variants, required fields, and behavior for invalid fields. It lacks a note about return values or error conditions, but for a create operation with this level of detail, it is largely complete, warranting a 4.
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?
With only 21% schema description coverage, the description compensates well by explaining the 'type' enum in depth, the conditional requirements for each type, and the 'extra' field as a catch-all for unspecified Coolify fields. It covers most core parameters, though some like name, domains, and instant_deploy are only implicitly covered via 'extra', preventing a 5.
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 'Create a new application.' with a specific verb and resource, and distinguishes itself from sibling create tools (createProject, createDatabase) by detailing application-specific source types like Git repos, Dockerfiles, and Docker images. This makes the tool's purpose unmistakable.
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 provides clear guidance on when to use each 'type' value and the required parameters for each, such as needing github_app_uuid for 'private-github-app' or docker_registry_image_name for 'dockerimage'. It also clarifies that environment_name or environment_uuid is sufficient. However, it does not explicitly exclude alternatives or say when not to use this tool, so it falls short of a 5.
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?
Annotations already indicate a non-read-only, non-destructive operation. The description adds important behavioral context beyond annotations: it polls until terminal status, returns log tails for failures, and warns about long builds. This provides useful operational detail not captured in the 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 two sentences, front-loaded with the primary action ('Trigger a deployment'), immediately follows with the key wait behavior, and gives a concrete recommendation. No filler or unnecessary repetition.
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?
With 8 parameters and no output schema, the description is only moderately complete. It covers triggering and wait behavior but does not clarify the roles of other parameters or the full return value structure beyond failure log tails. More detail would be needed for a fully complete description.
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 only 13%, so the description must compensate. It explains uuid, tag, and wait, but does not address force, docker_tag, pr, pull_request_id, or timeout_seconds, leaving several parameters with unclear meaning. It partially compensates for the schema gap but is incomplete.
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 identifies the tool as triggering deployments for an application, with explicit mention of identification by UUID or tag. This distinguishes it from sibling tools like cancelDeployment and listDeployments, providing a specific verb and resource.
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 clearly implies usage for triggering deployments and explains the behavior when wait=true, including practical advice to raise MCP client timeout. However, it does not explicitly contrast with alternative deployment-related tools like redeployProject, so exclusions are not fully covered.
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?
Annotations already mark the tool as read-only and open-world, and the description confirms the read behavior. It adds the precondition that 'get' and 'members' require id, but doesn't disclose other behavioral aspects like pagination, error handling, or return formats.
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 followed by a compact action list, 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?
The tool has a simple action-dispatch structure, but the description doesn't specify the return values for each action or the meaning of 'current'. Given the read-only annotation and clear action names, it's adequate but not fully 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?
The description clarifies which actions require the 'id' parameter, complementing the schema where id is optional but conditionally needed. It repeats the enum values but adds dependency information, partially compensating for the 50% schema description 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 'Read Coolify teams' and enumerates the specific actions, making the tool's purpose unambiguous and distinct from sibling tools for other resources.
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 'Read Coolify teams' establishes the domain, and the action list with 'needs id' annotations provides conditional usage guidance. However, it doesn't explicitly contrast with alternative tools or explain selection between actions.
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?
Annotations already indicate a write operation. The description adds that engine-specific fields in `extra` are validated per engine, providing useful context about constraints, but it doesn't go deeper into side effects, async behavior, or failure modes.
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 three sentences long, front-loaded with the core purpose, and every clause adds value. No fluff 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?
For a 12-parameter create tool with no output schema, the description covers the key purpose, required fields, engine selection, and the `extra` parameter validation. It doesn't explain optional fields or return values, but it provides enough to select and invoke the tool correctly in most cases.
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 description adds meaning beyond the schema by explaining that `type` selects the engine, that environment_name and environment_uuid are alternatives (one is enough), and that `extra` carries engine-specific validated fields. This compensates for the low schema coverage, though some fields like name, image, and public_port remain undocumented.
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 opens with 'Create a database' and specifies the exact resource and action. It enumerates the supported engine types, making it unmistakable and distinct from sibling tools like createApplication and createService.
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 states the required fields (project_uuid, server_uuid) and clarifies that environment can be specified by either name or UUID. It doesn't explicitly contrast with alternative tools, but the context and prerequisites imply when this tool should be used.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the HTTP method (GET) and endpoint (/health), but no further behavioral details such as the response format or error behavior. It does not contradict 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 sentence, immediately front-loaded with the action and resource. Every word contributes value, and there is no redundant information.
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 (0 params, no output schema), the description adequately covers the core purpose. It could mention what the response indicates, but for a health check, 'Check that the API is up' sufficiently implies the result. With annotations covering safety, the description is complete enough.
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 0 parameters, so the schema provides complete coverage. The description adds nothing about parameters, which is acceptable given there are none. The baseline of 4 applies 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 tool's function: 'Check that the Coolify API is up (GET /health).' It uses a specific verb ('check') and resource ('Coolify API'), and explicitly mentions the HTTP endpoint, which uniquely distinguishes it from all sibling tools that focus on managing resources, projects, servers, or deployments.
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 usage: it is a health check for the API, so an agent can infer it should be used to verify API availability before other operations. However, it does not explicitly state when to use it versus alternatives or mention any exclusions, though no other sibling tool serves this 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?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful context about the content (status breakdown, currently running deployments) but does not disclose output format or potential variability beyond what annotations imply.
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 core value ('One-call summary') and then uses a colon to list included components. 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?
Given the tool's low complexity (no parameters, no output schema), the description provides a solid overview of what is returned. It could mention the response format or example structure, but the current wording is adequate for an overview endpoint.
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, so the input schema fully covers parameter semantics. The description correctly focuses on the tool's output rather than parameter details, matching the baseline for parameterless tools.
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 identifies the tool as a one-call summary of the entire Coolify estate, enumerating key resource types (servers, projects, applications, databases, services, deployments). This specific scope distinguishes it from sibling tools that focus on individual 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'One-call summary of the whole Coolify estate' establishes the primary use case: getting a high-level overview in a single call. It does not explicitly mention alternatives or when not to use it, but the context is clear enough for an agent to choose it over more granular list tools.
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?
Annotations already declare readOnlyHint and openWorldHint, so the description adds valuable context by disclosing that key material is masked unless showSecrets is true. This behavioral detail is not present in annotations and helps the agent understand the output masking behavior. No contradiction with 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 two concise sentences, front-loaded with the exact purpose and then adding a key behavioral note. Every word earns its place; no redundancy or 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?
Without an output schema, the description adequately explains the return concept (metadata) and the masking behavior. It does not describe error cases or full return fields, but for a simple get-by-UUID tool with one optional boolean, the provided context is sufficient for correct invocation.
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 0%, so the description must compensate. It explains that 'uuid' is the identifier of the private key ('by UUID') and clearly ties 'showSecrets' to the masking behavior. Both parameters receive semantic context, though the description could elaborate on the format or expected values.
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 clearly identifies the resource as 'SSH private key's metadata' with a UUID identifier, distinguishing it from sibling tools like listPrivateKeys (which lists all) or create/update/delete mutations. The scope 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 the tool is used when you have a UUID to fetch a single private key's metadata, but it does not explicitly compare with alternatives like listPrivateKeys or mention when not to use it. The usage context is clear from the verb and identifier but lacks explicit exclusion or alternative 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?
The description goes beyond the readOnlyHint annotation by disclosing that secrets are masked by default and that passing showSecrets reveals them. This is a meaningful behavioral trait that could affect the response and the agent's decision to set showSecrets. It does not mention error handling or rate limits, but given the read-only annotation and the tool's simplicity, this is sufficient.
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 with the action and resource, and immediately includes the critical behavioral note about secrets. Every word earns its place with no filler or repetition of schema details, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter getter with readOnlyHint and no output schema, the description provides the core information needed to invoke the tool correctly: the identifier (UUID) and the one behavioral option (showSecrets). It does not detail the fields or shape of 'service details', but that is not necessary given the tool's straightforward nature. It also omits error cases, but the essential context is covered.
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?
With schema description coverage at 0%, the description carries the burden of explaining parameters. It addresses both params: 'by UUID' clarifies that uuid is the identifier, and 'pass showSecrets to reveal' explains the boolean's effect and implies the default false. It does not specify UUID format or explicitly say showSecrets is optional, but the schema already defines types and requiredness, and the description conveys the essential semantics.
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-resource pair: 'Get service details' and scopes it with 'by UUID', clearly distinguishing it from listServices (which lists all services) and from getters for other resources like getServer or getApplication. It also mentions the key parameter-based behavior (secrets masking), making the tool's purpose 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 usage: it is for retrieving a single service when you know its UUID. However, it does not explicitly state when to use this tool versus alternatives such as listServices (to enumerate services) or serviceEnvs (for environment variables). There are no exclusions or explicit alternative recommendations, relying instead on the resource type and UUID scope to imply use.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds only the UUID requirement and does not mention return shape, pagination, or error behavior. No contradiction with 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?
Two short sentences with no filler. The action and the key requirement are front-loaded, making it easy to parse.
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 read-only list operation with one parameter, this description is complete enough: it states what is listed and what input is needed. No output schema exists, but the simplicity of the operation makes the lack of return details acceptable.
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 has a bare 'uuid' string with no description coverage. The description clarifies that the UUID is for the project, adding essential meaning that would otherwise be missing.
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 identifies a read-only list operation for project environments with a specific verb ('List') and resource ('environments for a project'). It distinguishes itself from sibling tools like applicationEnvs/databaseEnvs by the project-level scope.
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?
It states the prerequisite of a project UUID, which guides the agent to have that identifier available before invoking. It does not explicitly contrast with alternative env-listing tools, but the project-level scope strongly implies its use case.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds the confirmation behavior and 'blast radius' context, which informs the agent about the impact and user interaction. This goes beyond the annotations without contradicting them.
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 concise sentences front-load the primary action and scope, followed by a useful behavioral note. Every word earns its place with no repetition or 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 tool with one optional parameter and strong annotations, the description covers the essential aspects: scope, optional restriction, and confirmation behavior. It does not mention return values or asynchronous nature, but the simplicity and annotation coverage make it sufficiently 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 schema provides 100% coverage for project_uuid with the description 'Restrict to a single project.' The main description reiterates this as 'optionally restricted to one project,' but adds no new semantic details. Baseline 3 is appropriate given the 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 states the specific action (stop) and the resource (every running application), with an optional restriction to one project. It clearly distinguishes itself from sibling tools like stopApplication by emphasizing the plural/global scope.
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 clearly conveys when to use this tool: when you need to stop all running applications, optionally within a project. However, it does not explicitly mention when not to use it or name alternatives like stopApplication, so it falls short of an explicit when/when-not comparison.
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?
Annotations already indicate readOnly=false, openWorld=true, idempotent=true, destructive=false. The description adds useful behavioral context: `extra` fields are validated against the OpenAPI schema, implying invalid fields will be rejected. It also clarifies the UUID-based targeting and the existence of fields beyond the common ones, which is beyond what annotations provide.
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 two sentences, front-loaded with the core purpose, and then elaborates on the `extra` mechanism. No wasted words; every sentence provides necessary context.
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 an update tool with 12 parameters and no output schema, the description, combined with the schema and annotations, gives adequate context. It covers the key points: UUID identification, common vs. extra fields, and validation. The lack of an output schema lowers the burden, and there's no obvious missing information that would prevent correct 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?
With only 8% schema description coverage, the description compensates by explaining the structure: common fields are exposed directly, and any other Coolify field goes into `extra` with validation. This adds meaning to the `extra` parameter and clarifies the overall parameter strategy, even though individual field names are left self-explanatory.
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's function: 'Update an application's configuration by UUID.' It uses a specific verb (update) and resource (application's configuration), distinguishing it from sibling tools like createApplication, deleteApplication, and startApplication. The mention of 'common fields' and 'extra' further clarifies 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 description implies usage context: it's for updating existing applications by UUID, and it explains how to handle common vs. extra fields. However, it doesn't explicitly state when to use this tool over alternatives (e.g., createApplication for new apps), and there are no exclusion criteria or alternative tool references.
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?
Annotations already disclose the operation is not read-only, not destructive, and idempotent. The description adds behavioral context by explaining that the API identifies the key by its private_key content (a non-obvious requirement) and that name/description are optional fields, which clarifies the update semantics beyond the structured 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 two sentences, front-loaded with the core action, and every clause adds value. It is efficient without unnecessary 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?
For a simple update tool with no output schema, the description covers the essential aspects: what it does, how it identifies the target, and which fields are optional. It could be slightly richer by mentioning potential side effects or prerequisites, but given the low complexity and supportive annotations, 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 0%, so the description carries the burden of explaining parameters. It does so effectively: private_key is the required identifier, while name and description are optional updatable fields. This adds meaning beyond the raw schema, though it doesn't specify constraints or default behaviors.
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 begins with 'Update an SSH private key,' which clearly states the action and resource. It further distinguishes this tool from siblings like createPrivateKey, deletePrivateKey, and getPrivateKey by specifying the unique identification method via private_key content.
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 updating an existing private key, and it clarifies that the private_key content is required for identification. However, it does not explicitly name alternative tools or provide when/when-not guidance, such as preferring createPrivateKey for new keys or deletePrivateKey for removal.
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?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds meaningful behavioral context beyond that: it reveals the use of a local index, the absence of network calls, and the return fields (titles, canonical URLs, snippets). This gives the agent a better picture of performance and output.
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 that efficiently states the verb, resource, key differentiator (local index, no network), and return format. Every phrase earns its place with no redundancy or filler.
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 2-parameter tool with no output schema, the description covers all essential aspects: what is searched, how (local index), network independence, and the shape of the returned data. The annotations further fill safety and world-behavior gaps, making the overall context sufficient for an agent to invoke it correctly.
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 50% (query has a description, limit does not). The tool description adds minimal parameter meaning: 'full-text search' implies query semantics, and the mention of return fields indirectly helps. However, limit's behavior (max results, default) is not explained in the description or schema, so the description does not fully compensate for the coverage gap.
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 ('Full-text search') and names the resource ('official Coolify documentation'), plus distinguishes from siblings by detailing the local index and no-network behavior. It clearly states what the tool does and is not confused with other tools.
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 provides clear context for when to use the tool: searching documentation offline via a bundled local index. It doesn't explicitly name alternatives but the sibling list contains no other doc-search tool, making its unique purpose apparent. The 'no network' note adds useful situational 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?
The description goes beyond the destructiveHint annotation by detailing exactly what gets deleted (configurations, volumes, connected networks) and the docker cleanup behavior. It also explains how to prevent those deletions by passing flags as false, which is valuable context for safe invocation.
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 two concise sentences. The first sentence states the primary purpose, and the second adds essential default behavior and flag guidance. No unnecessary words or repetition.
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 it is a destructive operation with 5 parameters and no output schema, the description covers the core action, side effects, and flags. It does not mention prerequisites like stopping the service first, but the openWorldHint and default behavior make it sufficiently complete for correct invocation.
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?
With 0% schema description coverage, the description compensates by explaining the meaning of the boolean flags: 'pass the flags as false to keep them.' It clearly links the options to retaining configurations, volumes, networks, and skipping cleanup, though it does not name each parameter explicitly. The uuid parameter is self-evident.
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 starts with 'Delete a service by UUID,' which is a specific verb and resource, clearly distinguishing it from sibling tools like deleteApplication and deleteDatabase. The noun 'service' is explicit 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting services but does not explicitly state when to prefer this tool over alternatives or when not to use it. It provides no exclusions or alternative tool references, so the guidance is only implied by the tool's purpose.
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?
Annotations already flag the tool as destructive and non-read-only. The description adds the confirmation prompt on supporting clients and emphasizes the broad scope ('every application'), providing extra behavioral context beyond the 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?
Two concise sentences, front-loaded with the main action and no unnecessary wording. The optional environment scope and confirmation behavior are mentioned in a compact manner.
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 two-parameter action with no output schema, the description covers the action, scope, optional restriction, and confirmation behavior. It does not detail return values or error handling, but those are less critical for a restart 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 description clarifies both parameters: 'in a project' explains project_uuid, and 'optionally a single environment' explains the environment parameter. Since the schema only describes environment, the description compensates for the undocumented project_uuid.
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 restarts every application in a project, optionally limited to a single environment. The verb 'Restart' plus the project-wide scope distinguishes it from the sibling restartApplication tool.
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 provides clear context by specifying 'every application in a project' and the optional 'single environment' restriction, implicitly indicating when this tool is appropriate. It does not explicitly mention alternatives, but the scope is self-explanatory.
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?
The description adds critical behavioral context beyond annotations: 'This will delete all environments and resources in the project.' This specifies the cascade scope of destruction, which is not captured by destructiveHint=true. This is valuable transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no waste. It front-loads the action ('Delete a project') and provides the essential scope detail in the second sentence.
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 destructive tool with one parameter and no output schema, the description is complete. It explains the action, the input method (UUID), and the full scope of deletion. Annotations already convey the destructive nature, and the description adds the specific cascade effect.
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 has 0% description coverage, but the description clarifies that the single 'uuid' parameter is used to identify the project to delete. This is sufficient for a one-parameter tool, adding meaning that the string must be a project UUID.
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 'Delete a project by UUID' with a specific verb and resource, clearly identifying the action. It also distinguishes this tool from sibling delete tools (deleteApplication, deleteDatabase, etc.) by specifying the project entity.
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 want to delete a project) but provides no explicit guidance on when to use this tool vs alternatives or when not to use it. It does not mention any exclusions or alternative tools for similar tasks.
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?
Beyond the destructiveHint annotation, the description details exactly what gets deleted by default (configurations, volumes, connected networks, docker cleanup) and how to opt out. This provides valuable operational transparency for an agent.
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, front-loaded with the primary action. No redundant information; every phrase adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 5 parameters, the description adequately explains default behavior and customization. It lacks return value details, but with no output schema and a simple delete operation, the provided context is sufficient.
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?
With 0% schema description coverage, the description compensates by explaining the UUID as the identifier and describing the boolean flags as controlling deletion of specific resources. It groups the params meaningfully, though it doesn't name each individually.
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 ('Delete a database by UUID') with a specific resource and identifier method. It distinguishes from sibling tools like updateDatabase or getDatabase by focusing on deletion and the unique UUID parameter.
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?
Provides clear context on default destructive behavior and how to preserve resources by setting flags to false. While it doesn't explicitly exclude scenarios or name alternatives, the usage context is well-defined for a deletion tool.
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/frndchagas/coolify-mcp/badges/card.svg)](https://glama.ai/mcp/servers/frndchagas/coolify-mcp)

Score Badge

Copy to your README.md:

[![coolify-mcp MCP server](https://glama.ai/mcp/servers/frndchagas/coolify-mcp/badges/score.svg)](https://glama.ai/mcp/servers/frndchagas/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/frndchagas/coolify-mcp'

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