awesome-coolify-mcp

Server Quality Checklist

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

Latest release: v1.1.4
Disambiguation3/5
While each tool targets a distinct domain (applications, databases, servers, etc.), there is notable cross-tool overlap: multiple tools expose `logs` actions (application, deployment, diagnose), and `version` appears in both `system` and `meta`. Also, `resource.list/find` competes with domain-specific listing tools, creating potential for agent misselection.
Naming Consistency5/5
All tool names are lowercase nouns in a consistent singular style (application, private_key, environment), and actions follow a predictable verb pattern (get, list, create, update, delete, start, stop, restart, deploy). Child actions use a uniform colon syntax (envs:list, backup:now), with no mixed casing or stylistic chaos.
Tool Count4/5
With 19 tools, the server is in the 'heavy but reasonable' range. Each tool addresses a meaningful aspect of Coolify administration, though some could be consolidated (e.g., meta/system overlap, resource vs domain-specific lists). The count is not excessive given the domain's complexity.
Completeness4/5
The tool surface covers a broad range of Coolify resources, including applications, services, databases, servers, projects, environments, private keys, and deployments. Minor gaps exist, such as no update action for environments and no application backup actions (database backups are covered), but these are workaround-able and core workflows are well supported.
Average 4/5 across 19 of 19 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 271 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
Annotations only provide openWorldHint=true, so the description carries the burden of disclosing side effects. It states 'Safety: optional instance · reveal opt-in only', but this largely duplicates schema descriptions (e.g., instance optional, reveal default false). It does not disclose that create actions provision real resources, require specific permissions, or are irreversible. No contradiction with annotations, but insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the purpose, and lists actions in a structured signature format. The safety line is brief and informative, though somewhat cryptic. No wasted sentences, but could be slightly clearer in the safety section.
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 25 parameters, 4 actions, and an output schema, the description provides action signatures and a safety note, covering the core structure. However, it lacks usage selection guidance, behavioral details beyond the schema, and context on what 'recipes' entails. The output schema covers return values, but the description is not fully complete for a complex orchestration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3. The description adds significant value by mapping actions to their specific parameter groups (e.g., create-git-app(server_uuid, git_repository, git_branch, repo_path?, build_pack?)), which the schema does not provide since it lists all parameters flatly. This helps agents know which parameters apply to each action, exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as multi-resource orchestration with specific action names (create-git-app, create-app-db, create-one-click, recommend) and parameter signatures. It is distinct from sibling tools focused on single resources, though it does not explicitly name an alternative. The verb 'orchestration' and action list make the purpose concrete.
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 application, database, or service. The 'multi-resource orchestration' phrase implies it is for combined workflows, but there are no exclusions, prerequisites, or comparisons. The action signatures show what can be done, but not when to choose this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds safety-related behavior beyond the annotations, such as 'no auto-push' and 'optional instance', which is useful. However, it doesn't disclose other important traits like auth requirements, rate limits, or side effects, and the 'gh soft-pause' note is cryptic and unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, using three short lines to convey purpose, actions, and safety. Each sentence has a distinct role, and there is no wasted wording.
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 high complexity (37 parameters, 3 actions), the description is too brief. It doesn't explain the differences between actions, which parameters belong to which action, or how the output schema relates to the tool's behavior. The description leaves many questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter descriptions, so the baseline is 3. The description's action signatures (e.g., wire(mode, set_env?, ...)) do not add meaningful semantics beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for workspace setup, involving gh preflight, Coolify linkage, and optional greenfield provisioning. It lists specific actions (preflight, wire, resume), giving a general sense of the tool's scope, but it doesn't fully explain what each action does, so it's not as clear as it could be.
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 alternative tools like deployment or resource. There's no mention of when to use preflight vs wire vs resume, or any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that operations are destructive and require confirmation ('Safety: confirm for destructive ops'), which adds behavioral context beyond the openWorldHint annotation. However, it does not detail potential side effects, the return format, or what happens on failure, leaving gaps given the open-world hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single introductory sentence followed by a compact list of action signatures and a safety note. Every part serves a purpose, and the key information is front-loaded.
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 10 parameters (all described in schema) and an output schema existing, the description covers the main actions and safety. However, it omits explanatory context about the grouping rationale or cross-tool relationships, which would help an agent decide when to invoke this tool over siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description doesn't need to compensate heavily. However, it adds value by showing the action signatures (e.g., 'stop_all(confirm)') and indicating which parameters are relevant per action, clarifying usage beyond the schema's general descriptions.
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 lists the three actions (stop_all, redeploy_project, restart_project) and states 'Emergency and bulk operations', providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'deployment' or 'application', which could also handle similar actions individually.
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 says 'Emergency and bulk operations' but offers no guidance on when to use this tool versus its siblings. It doesn't mention prerequisites, exclusions, or suggest alternatives for non-emergency or single-item operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds 'Safety: read-only meta tool', reinforcing the non-destructive nature but not adding additional behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief (two lines) and front-loaded with purpose. Every sentence serves a purpose, though structure could be slightly improved (e.g., separate sections).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple metadata tool with output schema, description sufficiently covers purpose and safety. No major gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers parameter 'action' with enum and description at 100% coverage. Description only reiterates 'version()' without adding new semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'MCP server metadata (version)' and specifies action 'version()', making purpose clear. However, it does not differentiate from sibling tools like system or resource, which could also return metadata.
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?
Implies usage when version info is needed, but no explicit when-not or alternative tools. The simplicity makes this adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include openWorldHint, indicating potential side effects. Description adds safety requirement for destructive operations and reveals opt-in behavior, but does not detail other side effects, error behavior, or state changes beyond these notes.
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?
Description is compact, front-loaded with purpose, and uses a clear list of actions. Every sentence adds value without repetition, though formatting could be improved for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 41 parameters and 16 actions, the description is too brief. It does not explain per-action parameters, dependencies, or return values. An output schema exists but is not shown; the description should provide more guidance for such complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond listing action signatures, which are already in the enum. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Service CRUD, lifecycle, and environment-variable actions' and distinguishes from sibling 'resource' tool by noting 'list via resource tool'. Enumerates all actions, establishing a specific verb+resource mapping.
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?
Provides safety notes on 'confirm for destructive ops' and mentions optional instance and reveal opt-in. However, lacks explicit guidance on when to use this tool versus siblings like 'application' or 'deployment', and no when-not-to instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits such as safety confirmations for destructive ops, optional instance parameter, and reveal opt-in. While annotations only include openWorldHint, the description adds useful context beyond that. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a compact list of actions and safety notes. However, it is lengthy due to the many actions listed. It could be more concise by grouping or summarizing less common actions.
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 (80 parameters, numerous actions) and the presence of an output schema, the description is incomplete. It does not explain return values, common parameter combinations, or prerequisites beyond basic safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, and the description adds little meaning beyond listing actions with parenthesized parameters (e.g., 'get(uuid?, name?)'). Many of the 80 parameters are not explained in the description, leaving gaps for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Database CRUD, lifecycle, env vars, and backup-schedule actions'. It lists specific actions and distinguishes from sibling tools by noting 'list via resource tool'. The scope is well-defined.
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 guidance on when to use this tool versus others (e.g., 'list via resource tool'). It also includes safety notes for destructive ops. However, it does not explicitly differentiate from other sibling tools like 'application' or 'service'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose key safety behaviors: destructive ops require confirm, and reveal is opt-in (tokens masked by default). However, it does not mention how tokens are stored, whether operations are idempotent, or the consequences of delete beyond requiring confirm. The file path and action list add useful context, but the description remains somewhat thin for a tool with this many actions.
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, starting with the resource and file path, then listing actions and safety constraints in a structured, scannable format. Every sentence adds value, and the length is appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, 8 actions, and an output schema, the description does a good job covering the essential actions and safety rules. It omits nuance around import-env and cloud-info but those are niche. The presence of an output schema means return values need not be described, so the description is adequately complete for the 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?
Schema coverage is low at 60%, so the description compensates somewhat by mapping parameters to actions (e.g., list(reveal?), delete(name, confirm)). This clarifies which optional parameters apply to each action, which the schema alone does not convey. However, it does not explain the meaning of verifySsl or token beyond what the schema already provides, missing an opportunity to fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Multi-instance registry CRUD' and enumerates the exact actions, giving a specific verb+resource focus. It differentiates from sibling tools by pointing to a specific config file and instance management domain, but it does not explicitly contrast with alternatives like server or resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for managing instances but does not provide explicit guidance on when to choose this tool over alternatives. It mentions safety confirm and reveal opt-in, which are behavioral constraints rather than usage context. No examples of when this tool is preferred are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds safe behaviors like 'optional instance' and 'reveal opt-in only', but the note 'confirm for destructive ops' contradicts the readOnlyHint, creating confusion. The added value over annotations is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with purpose in one sentence and action/safety notes in another. It is front-loaded and without fluff, though it could be slightly more organized.
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 (15 parameters, output schema exists), the description is brief. It lacks details on pagination behavior, parameter interactions, and result format. The output schema covers return values, but the description could provide more guidance for a 15-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps parameters to actions (e.g., list(type?, format?, page?, per_page?)), adding clarity beyond the schema. However, not all 15 parameters are explained (e.g., max_chars, include_full), and schema coverage is 60%, so the description partially compensates.
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 'Unified resource listing and cross-type discovery,' which sets it apart from sibling tools that focus on specific resource types (application, service, etc.). The actions 'list' and 'find' are enumerated, making the purpose explicit and distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing/finding across all resource types, but does not explicitly guide when to use this tool versus sibling tools for specific types. No exclusions or alternatives are mentioned, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include openWorldHint=true, indicating potential unknown side effects. The description mentions safety confirm for destructive ops, adding some context, but does not detail permissions, irreversible consequences, or other behavioral traits beyond CRUD.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line purpose, action signatures, and a safety line. All information is front-loaded and no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a 100% schema coverage, output schema present, and clear action signatures, the description is largely complete. Minor omission: no mention of response formats or errors, but these are covered by the 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 coverage is 100%, so parameters are fully documented in the schema. The description adds value by grouping parameters per action (e.g., list(format?, page?, per_page?)), showing required vs optional, but does not explain parameter details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a "Private key CRUD for SSH keys registered in Coolify." and explicitly lists each action with parameters, making the purpose very clear. It distinguishes itself from sibling tools which are high-level categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides safety guidance for destructive operations (confirm) and reveals (reveal opt-in only). Implicitly guides when to use each action via the parameter signatures, but does not explicitly compare to alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite sparse annotations (only openWorldHint), the description voluntarily discloses important behavioral traits: analyze is advisory-only, reveal is opt-in only, and confirm is needed for destructive ops. This goes beyond the schema and annotations, though it could still elaborate on which specific actions are destructive or how confirmation is triggered.
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 compact and structured: first a one-line purpose, then a dense action list with parameter signatures, then a safety section. Every sentence conveys necessary information without fluff, and the line breaks make it scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (22 parameters, 5 actions) and the existence of an output schema, the description covers the purpose, action breakdown, and safety constraints sufficiently. It does not explain return values (unnecessary due to output schema) but adequately orients the agent on the tool's scope and boundaries.
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?
Input schema has 100% description coverage for all 22 parameters, so the schema already documents each parameter well. The description's action list repeats parameter names but adds only marginal semantics (e.g., 'pattern triage on runtime logs' for analyze). This meets the baseline for schema-covered parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool synthesizes diagnose views for applications and servers or runs a global fleet scan, then enumerates five distinct actions (app, server, scan, logs, analyze) with their parameter signatures. This provides a specific verb+resource mapping for each action, fully distinguishing it from sibling tools like resource or server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear intra-tool guidance: analyze is explicitly advisory-only with no restart/redeploy/rollback, and safety notes confirm for destructive ops. However, it does not explicitly compare to sibling tools (e.g., when to use diagnose vs resource or system), so it lacks alternative exclusions but still provides actionable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true; description enhances with 'Safety: reveal opt-in only', indicating sensitive values are masked unless reveal is set. 'Static' also clarifies the data source. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely compact: two sentences, front-loaded with the primary action. Each clause carries meaning—purpose, signature, and safety caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with a full output schema and 100% schema parameter coverage, the description covers the core behavior and safety. It does not mention pagination or projection, but schema covers these; the main gap is the misleading signature omitting the required action parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all 9 parameters. The description's signature is minimal and omits action, pagination, and projection params, adding no new semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the tool as searching static Coolify documentation guides, with a specific verb ('search') and resource ('documentation guides'). This distinguishes it from sibling operational tools like deployment, server, and database.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the tool is for searching static documentation, placing it in clear context relative to operational siblings. However, it does not explicitly mention alternatives or when not to use it, so no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only openWorldHint and no readOnly/destructive annotations, the description adds behavioral value by specifying the local file path, listing action signatures, and stating 'confirm for destructive ops' and 'optional instance'. It does not detail side effects of sync/prune or audit output, but it provides meaningful safety and scope context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences: the first states purpose and resource, the second lists action signatures and safety information. The content is front-loaded and scannable, with no redundant words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-action CRUD/sync/diff tool with 12 parameters and a rich nested schema, the description provides the essential action-parameter matrix and safety caveat. Combined with the output schema, this covers most operational needs, though it does not explain the semantics of sync/diff/audit actions or clarify UUID-vs-name alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 17%, and the description compensates by mapping each action to its valid parameters, marking optional ones with '?' (e.g., sync(dry_run?, confirm?, prune?)). This adds clear meaning beyond the raw schema. However, it omits the name-based alternatives (project_name/environment_name) present in the schema, leaving minor ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Local manifest cache CRUD and sync/diff for .coolify/manifest.json', naming exactly the file/resource and the operation families. The action enumeration (get, upsert, set, remove, clear, sync, diff, audit) gives specific verbs and distinguishes this from sibling tools like resource or deployment by scoping it to the local manifest cache.
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 targeting the local manifest cache, but it lacks explicit 'when to use' or 'when not to use' guidance relative to sibling tools. The action signatures and safety note provide context, but there is no direct statement like 'use this for cache-only operations' or 'use resource for remote operations'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include openWorldHint: true. The description adds behavioral context: safety notes for destructive operations ('confirm'), optional instance, and reveal opt-in. It also notes that initial_environment requires user input per D-09/D-10, which is non-obvious behavior not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 lines) and well-structured: first line states purpose, second line action signatures, third line safety/behavior notes. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, 6 actions, output schema exists), the description covers all crucial aspects: action signatures, parameter semantics, safety, optional instance, reveal behavior, and output format options. It leaves no major gaps for an AI agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the description adds value by grouping parameters per action (e.g., 'create(name, initial_environment?)') and providing semantic guidance like 'ask user for production vs custom per D-09/D-10' for initial_environment, which goes beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Project CRUD for Coolify organizational containers' and enumerates specific actions (list, get, create, update, delete, delete_preview), making the tool's purpose distinct from siblings like 'system' or 'application'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists actions and safety notes but does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied through action names and parameter hints (e.g., 'confirm for destructive ops'), but no direct comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral details beyond the sparse openWorldHint annotation: destructive operations require explicit confirmation, instance is optional, and reveal is opt-in only for sensitive values. It also flags the runtime-only follow capability check, giving the agent useful safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficiently structured: a one-line scope statement, a compact action list with signatures, and a safety note. Every sentence adds actionable information, and the format is easy to scan for action selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 100-parameter tool with many actions, the description provides a strong overview, action signatures, safety rules, and a capability check. It falls short of full completeness by not mentioning the build-logs path via deployment_uuid or elaborating on open-world side effects, but the output schema and sibling context fill some 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?
With 100 parameters and only 59% schema coverage, the description compensates by listing per-action signatures (e.g., get(uuid, format?, projection?, reveal?)) and required fields like server_uuid for create and confirm for destructive ops. However, the logs signature omits build-logs parameters such as deployment_uuid, type, and include_hidden, leaving a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names the resource domain ('Application lifecycle, deploy, log, and environment-variable actions') and enumerates every supported action with its signature. It also distinguishes itself from the sibling resource tool by saying 'list via resource tool,' making the scope clear.
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 concrete guidance for when to use certain actions, such as 'list via resource tool' and 'follow runtime only; check system.version capabilities.application_logs_follow.' It does not comprehensively contrast with all sibling tools like deployment or environment, but the key alternatives and conditional requirements are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given annotations only include openWorldHint, the description carries the burden of behavioral disclosure. It openly states that cancel and rollback are destructive ('confirm for destructive ops', 'rollback requires confirm:true'), preflight is read-only, and reveal is opt-in. This goes beyond annotations and adds meaningful safety context, though it does not detail watch or logs 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 well-structured and efficient: an overview sentence, a compact action list with parameter signatures, and a safety note. Every line carries distinct information with no redundancy, making it easy to parse despite the breadth of actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 25 parameters, an output schema, and 7 actions, the description provides a comprehensive overview, action signatures, and safety caveats. It does not delve into when to prefer one action over another (e.g., watch vs. logs), but the schema and output schema fill many gaps. Overall, it is sufficiently complete for an agent to select and invoke actions correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100% (baseline 3), the description adds value by grouping parameters into action signatures and clarifying alternative inputs (e.g., 'deployment_uuid|application_uuid' for logs, 'uuid|name|fqdn' for preflight/rollback). The safety notes also clarify semantic constraints (confirm required, reveal opt-in), enriching beyond the schema's descriptive text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List per-app deployments, get deployment details, or cancel an in-flight deployment,' which clearly identifies the tool as deployment management. The subsequent 'Actions:' list enumerates all seven operations, distinguishing it from sibling tools like 'application' or 'service' by explicitly focusing on deployment lifecycle.
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 contextual usage guidance through the 'Safety:' note, indicating that confirm is required for destructive operations, preflight is advisory read-only, and rollback requires confirm:true. It lacks explicit 'when not to use' or alternative tool references, but the action names and parameter lists imply appropriate scenarios, giving clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful safety context beyond the sparse openWorldHint annotation: it notes that delete requires explicit confirmation, that reveal is opt-in, and that instance is optional. It does not cover broader behaviors like auth or error handling, but the safety flags are relevant and actionable.
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 compact and well-structured into scope, action list, and safety notes. Every sentence earns its place, and the use of a single-line signature per action keeps it scannable without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 14-parameter, multi-action tool with an output schema, the description covers the action set, scope, required confirmations, and param action-specificity. It lacks examples or deeper return semantics, but the output schema and per-action signatures make the tool sufficiently complete for an agent to select and invoke it.
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 action signatures in the description add per-action applicability and optionality that the flat schema doesn't convey, such as 'name' being required for create and optional query parameters for list/get/delete. Since schema descriptions cover 100% of parameters, the baseline is 3, but the action grouping adds meaningful selection semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'Environment CRUD scoped to a parent project', with an explicit note that there is no update action. It enumerates all five actions, making the tool's purpose and scope immediately distinct from siblings like project or deployment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it's for environment operations scoped to a parent project and explicitly excludes the update action. It does not name alternative tools or provide direct when-not-to-use guidance beyond the no-update caveat, but the action list and scope define suitable usage well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only openWorldHint as an annotation, the description carries the burden of safety disclosure. It does well by stating 'advisory impact only' and cleanup safeguards/defaults, which tells the agent that impact is non-mutating and destructive actions require explicit confirmation. It does not elaborate on open-world effects or output behavior, but the output schema partially covers returns.
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 compact and well-structured: a purpose line, action signatures, and a safety line. Every word contributes useful information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 18-parameter, five-action tool, the description covers purpose, action signatures, and mutation safety well, and an output schema exists for returns. It falls short only by omitting mapping for pagination/projection parameters and lacking any guidance on choosing among sibling tools, but overall it is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by grouping parameters per action (e.g., impact(uuid, type, intent?, max_depth?, instance?)) and noting defaults like 'delete_volumes/configurations default false', which the schema does not convey. However, some params (page, per_page, reveal, projection, include_full) are not mapped to any action in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly defines the tool as an 'Instance health scorecard, dependency graph, impact analysis, and janitor cleanup' and then enumerates five distinct actions with their signatures. This clearly differentiates it from sibling tools like instance or diagnose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides per-action signatures and safety rules (e.g., 'cleanup requires confirm:true · delete_volumes/configurations default false'), giving actionable invocation context. However, it does not explicitly state when to use this tool vs alternatives or provide when-not-to-use exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no readOnly/destructive annotations besides openWorldHint, the description adds useful safety context: 'confirm for destructive ops,' 'reveal opt-in only,' and optional instance selection. It discloses secret-masking defaults and the need for confirmation, which is valuable behavioral transparency, though it does not mention all side effects like volume deletion.
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?
Three dense, front-loaded sentences deliver purpose, action signatures, and safety notes with zero filler. Every phrase earns its place, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 26-parameter tool with an output schema, the description covers the key decision points: action selection, safety, and high-level parameters. The action signatures and safety section are sufficient for initial invocation, though a few action-specific fields and the meaning of openWorldHint are not elaborated, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, but the description goes beyond it by grouping parameters per action (e.g., get(uuid, format?, projection?, reveal?), create(name, ip, private_key_uuid)). This action-to-parameter mapping adds significant semantic meaning not obvious from the flat schema, though some update fields remain unlisted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Server CRUD and validate,' naming the exact resource and operations. It uniquely identifies the tool's scope and explicitly distinguishes it from the resource tool for listing servers, resolving possible sibling 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?
It clearly states that server listing is handled by the resource tool, not this tool, and enumerates the specific actions. It does not explicitly discuss when not to use the tool for adjacent operations, but the action list and the pointer to resource for listing provide solid selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral details beyond the annotations: version() returns a specific structure and explicitly warns 'not legacy { version }', clarifying a potential breaking change. It also discloses 'reveal opt-in only', which informs the agent that sensitive values are masked unless opted in. These details are not present in annotations (readOnlyHint true, openWorldHint true). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: first sentence states the purpose and lists actions, second gives return type info for version, third covers safety and options. No redundant filler; every clause adds information. It is well-structured for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 sub-actions, 9 parameters, and an output schema, the description covers the key points: it enumerates actions, clarifies the version return shape, and mentions safety. However, it does not explain pagination parameters (page, per_page) or how they relate to infrastructure_overview, and the 'confirm for destructive ops' line is vague since all listed actions are read-only. Still, with a rich schema and output schema, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all 9 parameters, so schema alone is strong. The description adds value by linking 'format?' and 'max_chars?' specifically to infrastructure_overview, helping the agent know which parameters apply to which action. Without this, the agent might not know the action-parameter mapping. This goes beyond the generic schema descriptions.
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 this tool provides 'System actions for Coolify' and enumerates the four specific actions: health, version, verify, and infrastructure_overview. This is a specific verb-resource combination that distinguishes it from sibling tools that handle deployments, servers, databases, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives some usage context: 'Safety: confirm for destructive ops · optional instance · reveal opt-in only'. It indicates that destructive operations (if any) require confirmation, that an optional instance can be specified, and that reveal is opt-in. However, it does not explicitly say when to prefer this tool over siblings or exclude alternatives. The usage is implied by listing the actions.
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:

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

Score Badge

Copy to your README.md:

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

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/clezcoding/awesome-coolify'

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