Coolify MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources (applications, services, servers, projects, teams) and actions (create, get, list, restart, start, stop), with clear boundaries. However, some overlap exists between application and service tools (e.g., restart_application vs restart_service) that could cause confusion if the distinction between 'applications' and 'services' isn't fully understood, though descriptions help clarify.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as create_application, list_servers, get_project, restart_service, and stop_application. All tools use snake_case without deviations, making them predictable and easy to parse for agents.
Tool Count3/5
With 32 tools, the count is borderline high for a deployment management server, potentially feeling heavy and overwhelming. While it covers many operations, it might include redundant or overly granular tools that could be consolidated, such as separate start/stop/restart for applications and services.
Completeness5/5
The tool set provides comprehensive CRUD and lifecycle coverage for the Coolify domain, including creation, listing, retrieval, management (start/stop/restart), logging, deployment tracking, and validation. No obvious gaps exist; it supports full workflows from server setup to application deployment and monitoring.
Average 3.3/5 across 32 of 32 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool creates something, implying a mutation, but doesn't cover critical aspects: whether this triggers a deployment, what permissions are needed, if it's idempotent, error handling, or what the return value contains. The Git repository mention hints at source, but lacks depth on behavioral impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste. The first sentence states the core purpose, and the second adds useful context about applications without redundancy. It's appropriately sized and front-loaded, with every sentence earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral details (e.g., deployment consequences, error cases), usage prerequisites, and output expectations. The agent must rely heavily on schema and trial-and-error, which is inadequate for a creation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no parameter-specific information beyond the general context of Git repositories, which is implied by the git_repository parameter. This meets the baseline of 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new application') and resource ('in Coolify'), with additional context about what applications are ('deployable units that can be sourced from Git repositories'). It distinguishes from siblings like create_environment or create_project by focusing specifically on applications, though it doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't mention prerequisites (e.g., needing a project or server first), when to choose this over other creation tools, or any constraints like permissions or quotas. The agent must infer usage from parameter requirements alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a creation operation but doesn't mention any behavioral traits: no information about permissions required, whether this is idempotent, what happens on duplicate names, rate limits, or what the response contains. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place, and there's no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects (permissions, idempotency, error conditions) or explain what the tool returns. Given the complexity of creating a resource and the lack of structured fields to compensate, the description should provide more context about how this operation works.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter semantics beyond what's in the schema (it doesn't explain parameter relationships, constraints, or provide usage examples). The baseline score of 3 reflects adequate but minimal value added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new environment within a project'), making the purpose immediately understandable. It distinguishes from siblings like 'create_project' by specifying the resource type, though it doesn't explicitly contrast with other environment-related tools like 'list_environments'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't mention prerequisites (like needing an existing project), when not to use it, or how it differs from other creation tools (e.g., 'create_project' for projects vs. 'create_environment' for environments within projects).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool creates a project but lacks details on permissions required, whether creation is idempotent, what happens on duplicate names, or the response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without redundancy. It is front-loaded with the core action and resource, making it easy to parse. Every word earns its place, with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation (create) with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like error conditions, response structure, or integration with sibling tools (e.g., how projects relate to applications/services). For a creation tool in this context, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for both parameters (name and description). The description adds no additional parameter semantics beyond what the schema provides, such as naming constraints or description usage. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new project') and the resource ('project'), specifying its purpose is 'to organize applications and services.' This distinguishes it from other creation tools like create_application or create_service by focusing on project-level organization. However, it doesn't explicitly contrast with siblings like get_project or list_projects beyond the verb difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't mention prerequisites (e.g., needing a team context from get_current_team), exclusions, or comparisons to siblings like list_projects for viewing existing projects. Usage is implied only through the verb 'Create,' with no contextual boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves project details and environments, but doesn't cover critical aspects like whether it's a read-only operation, authentication requirements, error handling, rate limits, or the format of returned data. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose. It's front-loaded with the main action and includes a useful detail ('including its environments') without unnecessary elaboration. There's zero waste, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'details' entail, how environments are included, error scenarios, or the response format. For a tool that retrieves project data, more context is needed to understand its full behavior and output, especially without structured fields to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'project_uuid' fully documented in the schema (including description, examples, pattern, and type). The description doesn't add any semantic information beyond what the schema provides, such as clarifying the scope of 'details' or 'environments'. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details of a specific project including its environments.' It uses a specific verb ('Get') and resource ('project'), and mentions the inclusion of environments. However, it doesn't explicitly differentiate from sibling tools like 'list_projects' or 'get_team', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't mention sibling tools like 'list_projects' (for listing projects) or 'get_team' (for team details), nor does it specify prerequisites or exclusions. The input schema hints at getting the UUID from 'list_projects', but this isn't stated in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions initialization and accessibility but lacks details on permissions, side effects, error conditions, or response format. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste, front-loaded with the core purpose. Every word earns its place, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It should cover more behavioral aspects like what 'accessible' means, potential errors, or confirmation of success, but it only provides basic operational info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'uuid' parameter thoroughly. The description adds no additional parameter information beyond what's in the schema, meeting the baseline of 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start') and resource ('a previously created service'), specifying it initializes the container and makes it accessible. However, it doesn't explicitly differentiate from sibling tools like 'restart_service' or 'start_application', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'restart_service' or 'start_application', nor does it mention prerequisites or exclusions. It only states what the tool does, not when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool lists projects but lacks details on behavior like pagination, sorting, error handling, or authentication requirements. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first states the purpose clearly, and the second adds useful context about what projects organize. It's front-loaded and wastes no words, though the second sentence could be considered slightly extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain return values, error cases, or behavioral traits like rate limits. For a list operation, this leaves gaps in understanding how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('projects'), specifying that it retrieves all projects accessible by the current user. It distinguishes from siblings like 'get_project' by indicating it lists multiple items rather than fetching a single one, though it doesn't explicitly contrast with other list tools like 'list_applications'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites, such as needing authentication, or compare it to similar tools like 'get_project' for single-project retrieval or 'list_teams' for other resources, leaving usage context implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions the domains are 'used for routing traffic to applications and services', adding some context, but lacks details on permissions, rate limits, response format, pagination, or error handling for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste, front-loading the core purpose and efficiently explaining the domains' use. Every word contributes meaning without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 1 parameter and no output schema, the description is adequate but incomplete. It covers the basic purpose but lacks guidance on usage, behavioral details, and output expectations, which are needed given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'uuid' fully documented in the schema. The description adds no additional parameter semantics beyond implying the tool fetches domains for a specific server, aligning with but not enhancing the schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a list') and resource ('domains configured for a server'), with the purpose being to retrieve routing information for applications and services. It distinguishes from siblings like 'list_servers' by focusing on domains, but doesn't explicitly differentiate from other 'get_' tools like 'get_server_resources'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It doesn't mention prerequisites (e.g., needing a server UUID from 'list_servers'), exclusions, or comparisons to similar tools like 'get_server_resources' or 'list_servers', leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'provides an overview' without detailing behavioral traits like response format, pagination, error handling, or authentication needs. It mentions the server must be specified via UUID but doesn't clarify if this is a read-only operation or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two concise sentences that are front-loaded and waste-free. Each sentence adds value: the first states the core purpose, and the second clarifies the scope as an overview of all resources on the server.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter with full schema coverage and no output schema, the description adequately covers the tool's purpose and scope. However, as a read operation with no annotations, it lacks details on return values, error cases, or behavioral constraints, making it minimally viable but incomplete for optimal agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'uuid' fully documented in the schema as the server ID to check, sourced from list_servers. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'list of applications and services running on a server', specifying it provides an overview of all deployed resources. It distinguishes from siblings like list_applications/list_services by focusing on a specific server's resources, though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like list_applications or list_services is provided. The description implies usage for server-specific resource overviews but lacks context on prerequisites, exclusions, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool lists deployments but doesn't describe any behavioral traits such as pagination, rate limits, authentication needs, or what the output looks like (e.g., format, fields). For a list tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence clearly states the tool's purpose, and the second adds useful context about what deployments represent. Both sentences earn their place, with no wasted words or redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of listing deployments (which could involve historical data, filtering, or pagination), the description is incomplete. There are no annotations to cover behavioral aspects, no output schema to describe return values, and the description lacks details on scope, format, or limitations. This leaves significant gaps for an agent to understand how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, so it meets the baseline expectation. No additional parameter information is required or provided, which is appropriate for this case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all deployments across your Coolify instance.' It specifies the verb ('list'), resource ('deployments'), and scope ('across your Coolify instance'), with an additional clarifying sentence explaining what deployments represent. However, it doesn't explicitly differentiate from sibling tools like 'get_deployment' or other list tools, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't mention sibling tools like 'get_deployment' (for a single deployment) or other list tools (e.g., 'list_applications'), nor does it specify any prerequisites, contexts, or exclusions for usage. This leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions authentication requirements, which is useful, but fails to describe other critical behaviors: whether this is a mutating operation (implied by 'Create'), potential side effects, error handling, or what happens on success (e.g., server state). For a creation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Create a new server') and includes essential prerequisites. Every word earns its place with no redundancy or waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a server creation tool with 9 parameters, no annotations, and no output schema, the description is incomplete. It lacks information on what the tool returns, error conditions, or detailed behavioral context. For a mutation tool with significant parameters, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds minimal value beyond the schema by mentioning SSH access and private keys, which relate to parameters like 'private_key_uuid' and 'user,' but doesn't provide additional syntax or format details. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new server in Coolify'), making the purpose unambiguous. It distinguishes from siblings like 'create_application' or 'create_project' by specifying server creation. However, it doesn't explicitly contrast with similar tools like 'validate_server'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'Requires SSH access details and a private key for authentication,' suggesting prerequisites. However, it doesn't explicitly state when to use this tool versus alternatives like 'validate_server' or 'list_servers,' nor does it provide exclusions or clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the tool is for 'debugging and monitoring' and 'retrieve logs from running applications,' it doesn't disclose important behavioral traits like whether this is a read-only operation, if it requires specific permissions, rate limits, pagination behavior, or what format/log-level the logs are returned in. For a tool with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that are front-loaded with the core purpose. However, the second and third sentences are somewhat redundant ('debugging and monitoring' vs 'troubleshoot deployment issues and monitor application health'), which slightly reduces efficiency. Overall, it's well-structured but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic purpose and usage context but lacks critical behavioral details (e.g., read-only nature, permissions, return format). For a tool with 2 parameters and 100% schema coverage, the description is minimally adequate but incomplete for safe and effective use by an AI agent without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (uuid and lines). The description doesn't add any parameter-specific semantics beyond what's in the schema—it doesn't explain UUID format constraints, line count implications, or provide additional usage examples. Baseline 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get application logs by UUID' with specific verbs ('get', 'retrieve') and resource ('application logs'). It distinguishes from siblings like list_applications (which lists applications rather than retrieving logs) but doesn't explicitly differentiate from other logging or monitoring tools that might exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context: 'Essential for debugging and monitoring application behavior, errors, and performance issues' and 'to troubleshoot deployment issues and monitor application health.' However, it doesn't explicitly state when to use this tool versus alternatives (like other logging tools or monitoring endpoints) or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Shows who has access to team resources,' which adds some behavioral context about output content. However, it lacks details on permissions needed, rate limits, pagination, or what the list includes (e.g., roles, status). For a read operation with zero annotation coverage, this is insufficient to fully inform the 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?
The description is two concise sentences that are front-loaded with the core purpose. Every word earns its place, with no redundancy or fluff. It efficiently communicates the tool's function and a key output 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?
Given the tool's low complexity (0 parameters, no annotations, no output schema), the description is minimally adequate. It explains what the tool does but lacks details on output format, error handling, or authentication requirements. With no output schema, the agent might need more guidance on return values, making this incomplete for optimal 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?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info, which is appropriate. Baseline is 4 for zero parameters, as the schema fully covers the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('list of all members in the currently authenticated team'), making the purpose specific and understandable. It distinguishes from siblings like 'get_current_team' (which likely returns team metadata) by focusing on members. However, it doesn't explicitly contrast with 'list_teams' or 'get_team', which might be about listing multiple teams or getting a specific team's details, leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication state), exclusions, or compare to siblings like 'list_teams' or 'get_team'. The phrase 'currently authenticated team' implies context but doesn't specify when this is appropriate over other team-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves 'detailed information' but doesn't disclose behavioral traits like what information is included, whether it's read-only (implied by 'Get'), error conditions, authentication needs, or rate limits. The description is minimal and lacks essential context for a tool that likely returns complex deployment data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose. Every word earns its place: the first sentence defines the action, and the second provides usage context. There's no redundancy or unnecessary elaboration, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (likely returning detailed deployment data), no annotations, and no output schema, the description is insufficient. It doesn't explain what 'detailed information' includes, potential response formats, or error handling. For a tool in a deployment management context with many siblings, more completeness is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'uuid' well-documented in the schema. The description adds no parameter-specific information beyond what the schema provides (e.g., no additional constraints or examples). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about a specific deployment', which is specific and unambiguous. It distinguishes from siblings like list_deployments by focusing on a single deployment rather than listing multiple. However, it doesn't explicitly differentiate from other get_* tools (e.g., get_application_logs) beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context with 'to monitor deployment status and troubleshoot issues', suggesting when this tool is appropriate. It doesn't explicitly state when NOT to use it or name alternatives, but the context implies it's for detailed views rather than listings. No explicit comparison to siblings like list_deployments or other get_* tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Returns the current version' but doesn't specify format (e.g., string, object), error handling, or any side effects. For a read-only tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and concise, consisting of two clear sentences that directly state the purpose and return value without any unnecessary details. Every sentence earns its place, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on return format or behavioral context. With no output schema, it should ideally specify the return type, but it's complete enough for basic understanding, scoring at the minimum viable level.
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, and the input schema coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied since no parameters exist, and the description doesn't introduce confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('Coolify version information'), and specifies what it returns ('current version of the Coolify instance'). However, it doesn't explicitly differentiate from sibling tools like 'health_check', which might also return version-related information, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't mention any prerequisites, context for usage, or compare it to similar tools like 'health_check' that might overlap in functionality, leaving the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it lists applications but doesn't cover important aspects like whether it requires authentication, if there are rate limits, how results are paginated or sorted, or what happens if no applications exist. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy for an agent to parse 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?
Given the tool's low complexity (0 parameters, no output schema), the description is adequate but incomplete. It explains what the tool does but lacks behavioral details like authentication needs or result format. With no annotations to fill gaps, this leaves the agent with insufficient context for reliable 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?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately doesn't mention any parameters, earning a baseline score of 4 for not introducing confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all applications'), specifying they are 'deployable units sourced from Git repositories' which adds useful context. However, it doesn't explicitly differentiate from sibling tools like 'list_projects' or 'list_services', which might also list related resources in the Coolify instance.
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 doesn't mention prerequisites, such as needing to be authenticated or having a specific role, nor does it compare to other list tools like 'list_projects' or 'list_services' that might be more appropriate in certain contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that keys are 'used for server authentication and Git repository access', which adds some context, but fails to disclose critical behavioral traits such as whether this is a read-only operation, if it requires specific permissions, how results are formatted, or any rate limits. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose and add value with contextual information about key usage. Every sentence earns its place without waste, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the what and why of the tool but lacks details on behavioral aspects like safety, permissions, or output format, which are important for a list operation in a system with sensitive data like SSH keys.
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, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose without redundant parameter details, aligning with the baseline for zero 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 clearly states the verb 'List' and the resource 'SSH private keys stored in Coolify', with additional context about their use for server authentication and Git repository access. It distinguishes from siblings like 'create_private_key' by focusing on listing rather than creation, though it doesn't explicitly contrast with other list tools (e.g., 'list_applications').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. While the description implies usage for viewing SSH keys, it doesn't mention prerequisites, timing considerations, or comparisons with other tools like 'get_server_resources' that might overlap in functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the action (restart) but lacks details on permissions needed, whether it's destructive (likely yes, as it stops and starts), potential downtime, error handling, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste: the first defines the action, and the second provides usage context. It's front-loaded with the core purpose and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a mutation (restart) with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, permissions, or return values, which are crucial for an agent to use it correctly. The high schema coverage helps with parameters, but overall context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'uuid' fully documented in the schema (including description, pattern, and type). The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('restart a service') and the mechanism ('by stopping and starting it again'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'restart_application' or 'start_service/stop_service', which would require mentioning it's for services specifically (though implied by the name).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context ('useful for applying configuration changes or recovering from issues'), which gives general guidance on when to use it. However, it doesn't explicitly state when not to use it or name alternatives like 'start_service' or 'stop_service' for partial operations, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions initialization and accessibility, but lacks critical details: whether this requires specific permissions, potential side effects (e.g., resource consumption), expected runtime, error conditions, or what 'accessible' means operationally. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that directly address the tool's purpose and effect. Every word earns its place, with no redundant information or fluff. It's front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after starting (e.g., how to verify success, what 'accessible' means, potential errors, or return values). Given the complexity of starting an application container, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the UUID parameter well-documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema (which explains how to obtain the UUID). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('start') and resource ('previously created application'), specifying that it initializes the container and makes it accessible. It distinguishes from 'create_application' by focusing on starting existing applications, but doesn't explicitly differentiate from similar tools like 'restart_application' or 'start_service'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'previously created application' and referencing where to obtain the UUID, suggesting it should be used after creation. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'restart_application' or 'start_service', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this is a read-only operation, what permissions are required, what happens during validation, whether it modifies anything, what the output format is, or any error conditions. The description adds minimal behavioral context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the core purpose, the second provides usage context. No wasted words, well-structured, and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation/diagnostic tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'validate' entails, what aspects are checked, what the expected output looks like, or how to interpret results. Given the complexity of server validation and the lack of structured output documentation, more detail would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'uuid' well-documented in the schema itself. The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('validate', 'verify', 'troubleshoot') and resource ('server's configuration and connectivity'). It distinguishes from most siblings that create, get, list, or control resources, but doesn't explicitly differentiate from 'health_check' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context ('verify server setup and troubleshoot connection issues') but doesn't explicitly state when to use this tool versus alternatives like 'health_check' or other diagnostic tools. No explicit exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool creates a key but doesn't disclose behavioral traits such as whether this requires admin permissions, if the key is stored securely, potential rate limits, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and purpose without unnecessary words. Every part of the sentence contributes to understanding the tool's function, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 3 parameters), no annotations, and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose and usage context but lacks details on behavioral aspects, error handling, or return values, which are crucial for a tool that creates sensitive resources like SSH keys.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't clarify format constraints or usage examples for parameters). Baseline 3 is appropriate when the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new SSH private key') and the resource ('in Coolify'), with specific purposes mentioned ('for server authentication or Git repository access'). It distinguishes from siblings like list_private_keys by focusing on creation rather than listing, though it doesn't explicitly contrast with all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('for server authentication or Git repository access'), suggesting when this tool might be appropriate. However, it lacks explicit guidance on when to use alternatives (e.g., list_private_keys for viewing existing keys) or any prerequisites, leaving usage somewhat inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a listing operation, implying it's read-only and non-destructive, but doesn't confirm this explicitly. It misses details like pagination, rate limits, authentication needs, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: the first states the core purpose, and the second adds useful context about environments. Every sentence earns its place by clarifying the tool's scope without redundancy. It's front-loaded with the main action and avoids unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 (single parameter, no output schema, no annotations), the description is minimally complete. It covers the basic purpose and context but lacks details on behavior, usage scenarios, or output format. Without annotations or output schema, the description should do more to compensate, such as hinting at return values or error cases, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention any parameters, but the input schema has 100% coverage with a well-documented 'project_uuid' parameter. Since schema_description_coverage is high, the baseline score is 3. The description adds no parameter semantics beyond what the schema provides, such as clarifying the relationship between projects and environments, but this doesn't detract from the adequate schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all environments in a project'), making the purpose specific and understandable. It distinguishes from siblings like 'get_project' or 'list_applications' by focusing on environments, though it doesn't explicitly contrast with them. The addition of 'Environments separate different deployment stages...' provides helpful context but doesn't fully differentiate from similar listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'project' context and deployment stages, suggesting it's for viewing environment configurations. However, it lacks explicit guidance on when to use this versus alternatives like 'list_applications' or 'get_project', and doesn't mention prerequisites or exclusions. The input schema hints at needing 'project_uuid' from 'list_projects', but this isn't stated in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the requirement for a team ID but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what 'details' include (e.g., team members, settings). This leaves significant gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 followed by a prerequisite. Every word earns its place with no redundancy or fluff, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and prerequisite but lacks details on return values or behavioral context, which would be helpful for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'team_id' well-documented in the schema. The description adds minimal value by reinforcing that the ID comes from 'list_teams', but doesn't provide additional semantics beyond what the schema already covers, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get details') and resource ('a specific team'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_current_team' or 'list_teams', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 that a team ID from 'list_teams' is required, which helps guide usage. It doesn't explicitly state when to use this versus alternatives like 'get_current_team' or exclude other scenarios, preventing a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a listing operation but doesn't disclose behavioral traits like pagination, sorting, rate limits, permissions required, or what data is returned. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded with the core purpose and provide essential context without waste. Every sentence earns its place by defining the action and clarifying what services are.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose but lacks details on behavior, output format, or usage context, which are needed for full understanding despite the low complexity.
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 with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all services') and resource ('services across your Coolify instance'), with additional context defining services as 'containerized applications running on your servers'. It distinguishes from siblings like list_applications, list_servers, etc., by focusing specifically on services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like list_applications or list_servers. The description implies usage for viewing services but lacks any context about prerequisites, timing, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool 'gracefully shut[s] down the service container', which implies a controlled stop rather than immediate termination. However, it doesn't disclose important behavioral aspects like required permissions, whether the stop is reversible, error conditions, or what happens to dependent resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first states the core purpose, the second adds important behavioral context about graceful shutdown. No wasted words or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation (stopping a service) with no annotations and no output schema, the description provides basic purpose and behavioral context but lacks important details. It doesn't explain what 'gracefully' means operationally, what the response looks like, or potential side effects. Given the complexity of stopping a running service, more completeness would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'uuid' well-documented in the schema. The description doesn't add any parameter information beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('stop') and resource ('a running service'), specifying it's a graceful shutdown of the service container. It distinguishes from siblings like 'restart_service' and 'stop_application' by focusing specifically on stopping services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a service needs to be stopped gracefully, but doesn't explicitly state when to use this vs alternatives like 'restart_service' or 'stop_application'. It mentions getting the UUID from 'list_services', which provides some context but not explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the type/docker_compose_raw constraint, it doesn't describe what happens after creation (e.g., does the service start automatically?), what permissions are required, whether this is an idempotent operation, or what error conditions might occur. For a creation tool with significant impact, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - two sentences that each earn their place. The first establishes purpose and context, the second provides a critical constraint. No wasted words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what a successful creation returns, what happens to the service after creation, or potential side effects. The agent would need to guess about the outcome format and behavioral consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds the important constraint about type/docker_compose_raw mutual exclusivity, which provides context beyond the individual parameter descriptions. However, it doesn't add significant semantic value beyond what's already in the well-documented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new service') and the resource ('on a specified server'), with specific context about services being 'containerized applications that run on your Coolify servers.' It distinguishes from siblings like create_application by focusing specifically on services rather than applications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (creating containerized services) and includes an important constraint ('Either "type" or "docker_compose_raw" must be provided - you cannot specify both'). However, it doesn't explicitly differentiate when to use create_service versus create_application or other creation tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about version-dependent availability, which isn't captured in structured fields. However, it doesn't describe other behavioral traits such as response format, error handling, authentication requirements, or rate limits, leaving gaps for a tool that likely returns system status information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, consisting of two sentences that directly state the purpose and a key constraint. Every sentence earns its place by providing essential information without redundancy or fluff, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but has clear gaps. It covers the basic purpose and a version constraint, but without annotations or output schema, it doesn't explain what the health check returns (e.g., status codes, metrics) or other contextual details like authentication needs. This makes it minimally viable but incomplete for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it appropriately avoids redundant information. A baseline of 4 is applied as per the rules for zero-parameter tools, since no parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as checking the Coolify API health status with a specific verb ('Check') and resource ('Coolify API health status'). It distinguishes itself from sibling tools which are focused on CRUD operations for applications, servers, projects, etc., rather than system health monitoring. However, it doesn't explicitly contrast with potential alternatives like 'get_version' which might provide related system information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by noting that the endpoint may not be available in all Coolify versions, suggesting it should be used cautiously in version-dependent contexts. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'get_version' for version checks or other health-related tools if they existed), and doesn't specify prerequisites or exclusions beyond version availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the action ('stopping and starting') but lacks details on permissions needed, downtime implications, whether it's reversible, or error handling. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 followed by usage context. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a mutation tool with no annotations and no output schema, the description should do more to explain behavioral aspects like side effects or return values. It covers purpose and basic usage but lacks depth for safe operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'uuid' well-documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('restart') and resource ('application'), specifying it involves 'stopping and starting it again'. It distinguishes from siblings like start_application and stop_application by describing the full restart cycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 it ('useful for applying configuration changes or recovering from issues'), but does not explicitly mention when not to use it or name alternatives like restart_service for similar operations on different resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action will 'gracefully shut down the application container,' which implies a controlled, non-destructive operation, but it does not cover potential side effects, permissions required, or error conditions. This is a moderate disclosure but lacks depth for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are front-loaded and waste-free. The first sentence states the core action, and the second adds important behavioral context ('gracefully shut down'), making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a simple input schema, the description is somewhat complete but could be improved. It covers the action and behavioral intent but lacks details on outcomes, errors, or dependencies, which are important for a mutation tool like stopping an application.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the uuid parameter fully documented in the schema. The description does not add any additional meaning or context beyond what the schema provides, such as format details or usage examples, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('stop') and resource ('a running application'), specifying it performs a graceful shutdown of the application container. This distinguishes it from sibling tools like restart_application (which restarts) and start_application (which starts), making the purpose specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an application needs to be stopped gracefully, but it does not explicitly state when to use this tool versus alternatives like restart_application or stop_service. No exclusions or prerequisites are mentioned, leaving some ambiguity in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool executes commands in a container (implying mutation/action) and notes availability constraints ('may not be available in all Coolify versions'), which is useful context. However, it lacks details on permissions, side effects, rate limits, or response format, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage context and a note on availability. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a mutation tool. It covers purpose and basic usage but lacks details on behavioral traits (e.g., security implications, error handling) and output expectations, which are critical for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters. The description does not add meaning beyond the schema (e.g., it doesn't explain command syntax or UUID sourcing further). Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('execute a command') and target ('inside a running application container'), distinguishing it from siblings like 'get_application_logs' (read-only logs) or 'restart_application' (restart operations). It provides a verb+resource+scope combination that is precise and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('useful for debugging, maintenance, or running one-off tasks'), giving clear context. However, it does not specify when NOT to use it or name alternatives (e.g., vs. 'get_application_logs' for read-only access), missing full sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool lists servers and provides UUIDs, but lacks details on pagination, rate limits, permissions required, or output format. For a read operation with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose, and the second provides usage guidance. It is front-loaded with the core function and efficiently adds value without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but incomplete. It explains what the tool does and why to use it, but lacks behavioral details like output structure or limitations, which are important for a list operation even without complex inputs.
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, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on usage context, which aligns with the baseline score for zero-parameter 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 states the verb ('List') and resource ('all servers registered in your Coolify instance'), making the purpose specific and unambiguous. It distinguishes from siblings by focusing on servers rather than applications, projects, or 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 description provides clear context for when to use this tool ('to get server UUIDs needed for other operations'), which helps guide usage. However, it does not explicitly state when not to use it or name alternatives among siblings, such as 'get_server_resources' for detailed server info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions authentication context ('authenticated team', 'API token'), which adds useful behavioral context. However, it does not disclose other traits like rate limits, error handling, or response format, leaving gaps in 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 two concise sentences that are front-loaded with the core purpose. Every sentence adds value by clarifying the tool's scope and authentication context, with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the purpose and authentication context but lacks details on return values or error behavior, which could be helpful for completeness despite the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately does not discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get details') and resource ('currently authenticated team'), distinguishing it from sibling tools like 'get_team' or 'get_current_team_members'. It precisely identifies what the tool does without ambiguity.
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 'currently authenticated team' and 'team associated with your API token', which implicitly guides when to use this tool. However, it does not explicitly state when to use alternatives like 'get_team' or 'list_teams', missing explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it lists teams accessible to the authenticated user, implying read-only behavior and authentication needs, but lacks details on rate limits, pagination, or return format. It adds some behavioral context but is incomplete for a tool with no 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 sentences with zero waste: the first states the purpose, and the second provides usage guidance. It is front-loaded with the core function and efficiently adds value without redundancy, 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 tool's low complexity (0 parameters, no output schema, no annotations), the description is reasonably complete by covering purpose and usage. However, it lacks details on output format or behavioral traits like pagination, which could be helpful despite the simplicity. It meets most needs but has 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 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, maintaining focus on the tool's purpose and usage. Baseline is 4 for zero parameters, as it avoids unnecessary 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 the specific action ('List all teams') and resource ('teams the authenticated user has access to'), with a distinct purpose from siblings like 'get_current_team' or 'get_team' that retrieve specific teams. It provides a concrete use case for obtaining team UUIDs, making it highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('to get team UUIDs needed for other operations'), which provides clear context for its application. However, it does not specify when not to use it or name alternatives (e.g., 'get_current_team' for a single team), missing full exclusion guidance.
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-server MCP server](https://glama.ai/mcp/servers/wrediam/coolify-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/wrediam/coolify-mcp-server)

Score Badge

Copy to your README.md:

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

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/wrediam/coolify-mcp-server'

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