hcloud-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes targeting specific resources and actions, such as create_server vs. update_server. However, there is some potential overlap between power_off_server and shutdown_server (both stop a server) and between reboot_server and reset_server (both restart a server), which could cause minor confusion for an agent.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with clear action prefixes like create_, list_, update_, delete_, attach_, detach_, etc. All names use snake_case uniformly, making them predictable and easy to parse.
Tool Count2/5
With 67 tools, the count is excessive for typical MCP server purposes, making it overwhelming for agents to navigate. While the server covers a broad cloud infrastructure domain, the toolset feels bloated and could benefit from consolidation or better scoping to reduce cognitive load.
Completeness5/5
The toolset provides comprehensive CRUD and lifecycle coverage for all major resources (servers, networks, load balancers, volumes, etc.), including create, list, update, delete, attach/detach, and power management operations. There are no obvious gaps, ensuring agents can handle full workflows without dead ends.
Average 2.9/5 across 67 of 67 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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

Behavior1/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. 'Create a new server' implies a write/mutation operation but reveals nothing about permissions needed, whether creation is reversible, what happens on failure, rate limits, or expected response format. This leaves critical behavioral aspects completely undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, which could be appropriate if it were more informative. However, this brevity borders on under-specification rather than efficient communication, as it fails to provide necessary context for such a complex operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 9 parameters, nested objects, no annotations, and no output schema, the description is completely inadequate. It doesn't address behavioral aspects, parameter meanings, usage context, or expected outcomes. The agent would struggle to use this tool correctly based solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 11% schema description coverage (only the 'ssh_keys' parameter has a description), the description adds zero information about any of the 9 parameters. It doesn't explain what 'server_type', 'image', 'location' mean, what format they expect, or how they interact. For a complex tool with many parameters, this is severely inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new server' is a tautology that restates the tool name without adding specificity. It doesn't distinguish this tool from other creation tools in the sibling list like 'create_firewall' or 'create_volume', nor does it clarify what type of server or in what context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'create_network', 'create_volume'), there's no indication of prerequisites, dependencies, or appropriate contexts for server creation versus other infrastructure components.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to do so. It doesn't indicate whether this is a mutating operation, what permissions are required, if it's idempotent, or what happens on success/failure. The word 'create' implies mutation but lacks critical details like rate limits or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that wastes no words. While under-informative, it is front-loaded and efficiently phrased without redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with 3 parameters (including complex types), 0% schema coverage, no annotations, and no output schema, the description is completely inadequate. It fails to explain what the tool does beyond the obvious, leaving critical gaps in understanding behavior, parameters, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (name, rules, labels) are documented in the schema. The description provides no information about these parameters—their purposes, formats, or constraints—leaving them completely unexplained despite the presence of complex types like arrays and nested objects.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new firewall' is a tautology that restates the tool name without adding meaningful specificity. It mentions the verb 'create' and resource 'firewall' but lacks details about what a firewall entails in this context or how it differs from other creation tools like create_network or create_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, dependencies, or comparisons with sibling tools like list_firewalls, update_firewall, or delete_firewall, leaving the agent with no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It does not address critical aspects like required permissions, rate limits, idempotency, or the impact of creation (e.g., costs, time to provision). This is inadequate for a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, clear sentence. It is front-loaded and wastes no words, though this brevity contributes to its lack of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no schema descriptions, no annotations, no output schema), the description is severely incomplete. It does not compensate for the missing structured data, leaving the agent unable to understand how to use the tool effectively or what to expect from its execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning all 6 parameters are undocumented in the schema. The description adds no parameter information beyond the tool name, failing to explain what 'algorithm', 'location', or other inputs mean or how they affect the load balancer creation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new load balancer' restates the tool name with minimal elaboration, making it tautological. It specifies the verb ('create') and resource ('load balancer') but lacks differentiation from sibling tools like 'create_server' or 'create_network', failing to clarify what makes this creation distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, dependencies, or comparisons to sibling tools such as 'add_load_balancer_service' or 'update_load_balancer', leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. 'Create a new volume' implies a write/mutation operation but doesn't disclose any behavioral traits: no information about permissions required, whether this is idempotent, what happens on failure, rate limits, or what the tool returns. For a creation tool with 7 parameters, this lack of behavioral context is a critical 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 maximally concise at just three words. While this represents severe under-specification rather than ideal conciseness, from a pure structural perspective, it's front-loaded with the core action and contains zero wasted words. Every word earns its place, even though more words are desperately needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, creation operation), complete lack of annotations, 0% schema coverage, and no output schema, the description is completely inadequate. It doesn't explain what a volume is, what parameters mean, what happens during creation, what gets returned, or how this differs from sibling tools. For a tool with this level of complexity and zero structured documentation, the description fails to provide even basic contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 7 parameters, the description provides zero parameter semantics. It doesn't explain what 'name', 'size', 'automount', 'format', 'location', 'server', or 'labels' mean, their expected formats, or how they interact. The description fails to compensate for the complete lack of schema documentation, leaving all parameters semantically undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new volume' is essentially a tautology that restates the tool name without adding specificity. It doesn't explain what a 'volume' is in this context (storage volume, network volume, etc.) or what resources it creates. While it includes a verb ('Create') and resource ('volume'), it lacks the specificity needed to distinguish it from sibling tools like 'create_server' or 'create_network'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when this operation is appropriate, what happens after creation, or how it differs from related tools like 'attach_volume' or 'update_volume'. The agent must infer usage entirely from the tool name and schema.
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 'create' implies a mutation, but fails to describe what a floating IP is, whether it incurs costs, requires permissions, or what happens on success/failure. This leaves critical behavioral traits unaddressed for a creation 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 extremely concise with a single three-word sentence, front-loaded and free of unnecessary words. However, this brevity comes at the cost of under-specification, but as per scoring rules, conciseness is evaluated separately from completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is severely inadequate. It provides no context on what a floating IP is, how to use it, or what to expect, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning all 5 parameters are undocumented in the schema. The description adds no parameter information beyond the tool name, failing to explain what 'type', 'home_location', 'server', 'description', or 'labels' mean or how they affect the creation process.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a floating IP' is a tautology that merely restates the tool name without elaboration. It specifies the verb 'create' and resource 'floating IP', but lacks any detail about what a floating IP is or what this creation entails, making it vague and minimally informative beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'create_primary_ip' or 'assign_floating_ip'. The description offers no context, prerequisites, or exclusions, leaving the agent with no information to make an informed choice among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers only the basic action. It doesn't mention that deletion is likely permanent/destructive, whether it requires specific permissions, if there are confirmation prompts, rate limits, or what happens to associated resources. This is inadequate for a destructive operation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at three words, front-loading the essential action and resource with zero wasted text. Every word earns its place, though this brevity comes at the cost of completeness for other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, no output schema, and 0% schema coverage, the description is completely inadequate. It doesn't address behavioral risks, parameter meaning, expected outcomes, or error conditions. The agent lacks critical information needed to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single parameter 'id', and the tool description provides no parameter information whatsoever. While the parameter count is low (1), the description fails to explain what 'id' represents (e.g., server ID, numeric identifier) or where to obtain it, leaving the agent with incomplete guidance for proper invocation.
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 'Delete a server' clearly states the action (delete) and resource (server), making the purpose immediately understandable. However, it doesn't differentiate this tool from other destructive operations like delete_firewall or delete_volume, which would require sibling tool awareness for optimal agent selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., server must be powered off), consequences (irreversible deletion), or when to choose this over similar operations like shutdown_server or reset_server. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but offers none. It doesn't indicate if this is a mutation (likely yes), what permissions are required, potential side effects (e.g., affecting load balancer traffic), or error conditions. This leaves the agent with insufficient information to use the tool safely.
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, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse. Every word earns its place, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters with nested objects, no output schema, and no annotations), the description is incomplete. It lacks details on behavior, parameters, and expected outcomes, making it inadequate for safe and effective use. The conciseness comes at the cost of necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain the six parameters (e.g., 'id', 'type', 'server'), their relationships (e.g., 'type' determines which nested object to use), or usage examples. This leaves critical input details undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('a target to a load balancer'), making the purpose immediately understandable. It distinguishes from siblings like 'create_load_balancer' or 'remove_load_balancer_target' by focusing on target addition. However, it doesn't specify what a 'target' entails (e.g., server, IP, label selector), 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing load balancer), exclusions, or comparisons with siblings like 'add_load_balancer_service'. The description assumes context without explicit instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the action but fails to describe any behavioral traits: it doesn't mention if this requires specific permissions, whether the assignment is reversible (though 'unassign_floating_ip' exists as a sibling), what happens on failure, or any rate limits. This is inadequate for a mutation 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.
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 without unnecessary words. Every word earns its place by specifying the key elements (assign, floating IP, server), making it highly concise and well-structured for quick understanding.
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 (a mutation operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, error conditions, or return values, which are critical for safe invocation. The description alone is insufficient for an agent to use this tool effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'floating IP' and 'server' but doesn't explain what 'id' and 'server' parameters represent (e.g., that 'id' likely refers to the floating IP identifier and 'server' to the server identifier). No format, constraints, or examples are provided, leaving parameters ambiguous despite the low 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 ('assign') and target resources ('floating IP to a server'), making the purpose immediately understandable. It distinguishes from sibling tools like 'create_floating_ip' (creation) and 'unassign_floating_ip' (removal), though it doesn't explicitly mention these distinctions. The description avoids tautology by specifying what is being assigned to what.
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 an existing floating IP and server), exclusions, or related tools like 'assign_primary_ip' for similar operations. Usage is implied only by the action name, with no explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this is a destructive operation, what permissions are needed, potential side effects (e.g., server downtime), or error conditions. This is inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words, making it easy to parse. It's appropriately sized for a simple action, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (0% schema coverage), no annotations, and no output schema, the description is insufficient. It lacks critical context like behavioral traits, parameter meanings, and expected outcomes, leaving the agent poorly equipped to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so parameters 'id', 'server', and 'automount' are undocumented in the schema. The description adds no parameter semantics beyond implying 'id' refers to a volume and 'server' to a server, leaving 'automount' completely unexplained and lacking format details (e.g., numeric IDs).
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 ('Attach') and resource ('a volume to a server'), making the purpose immediately understandable. However, it doesn't differentiate from the sibling tool 'detach_volume' or explain what 'attach' means operationally in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like 'create_volume' or 'detach_volume', nor about prerequisites such as volume/server states or permissions. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the action. It doesn't disclose if deletion is permanent, requires specific permissions, affects dependent resources (e.g., subnets, attached servers), or has rate limits. 'Delete' implies destructive mutation, but behavioral details like confirmation prompts or error conditions are missing, leaving 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 extremely concise—three words—and front-loaded with the core action. There is zero waste or redundancy, making it easy to parse quickly. However, this brevity contributes to underspecification in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature (implied by 'delete'), no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks critical context: what a network is, deletion effects, prerequisites, error handling, and return values. For a mutation tool with one parameter, this minimal description leaves too many unknowns for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with one parameter 'id' undocumented in both schema and description. The description adds no parameter semantics—it doesn't explain what 'id' represents (e.g., network ID), its format, or where to find it. This fails to compensate for the schema's lack of documentation, making parameter usage unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a network' states the verb (delete) and resource (network), which is clear but basic. It doesn't differentiate from sibling deletion tools like delete_firewall or delete_server, nor specify what constitutes a 'network' in this context. While it avoids tautology, it lacks specificity about scope or type of network being deleted.
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., network must exist, be detached from servers), consequences (e.g., irreversible deletion), or when to choose other tools like update_network or detach_server_from_network. The description offers only the bare action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Detach' implies a mutation that likely requires permissions and may have side effects (e.g., making data inaccessible), but the description doesn't clarify this, mention reversibility, rate limits, or error conditions, leaving 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 extremely concise with a single sentence, 'Detach a volume', which is front-loaded and wastes no words. However, this conciseness comes at the cost of completeness, as it lacks necessary details for effective tool use.
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 mutation tool with no annotations, 1 undocumented parameter, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, parameter meaning, or expected outcomes, making it insufficient for an agent to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the schema provides no semantic context. The description adds no parameter information beyond the tool name, failing to explain what 'id' represents (e.g., volume ID) or any constraints, which is inadequate given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Detach a volume' states the basic action (detach) and resource (volume), which is clear but vague. It doesn't specify what 'detach' means operationally or differentiate from sibling tools like 'detach_iso' or 'detach_server_from_network', leaving ambiguity about the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., volume must be attached), exclusions, or related tools like 'attach_volume' or 'delete_volume', leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Power on a server' implies a state-changing operation but reveals nothing about permissions required, whether it's destructive (e.g., could cause data loss), rate limits, expected response, or error conditions. This is inadequate for a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word earns its place, though the brevity contributes to information gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is severely incomplete. It doesn't address behavioral aspects, parameter meaning, or expected outcomes. Given the complexity of server power management, this leaves critical gaps for the agent to operate safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the single parameter 'id'. The agent must guess what 'id' represents (server ID, numeric identifier) without any context about format, constraints, or where to obtain it. The description adds no value beyond the bare 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 'Power on a server' clearly states the action (power on) and the resource (server), making the purpose immediately understandable. It distinguishes from siblings like 'power_off_server' and 'reboot_server' by specifying the power state change direction. However, it doesn't specify what 'power on' entails in this context (e.g., booting from a powered-off state).
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., server must be powered off), when not to use it (e.g., if server is already running), or how it differs from similar tools like 'reboot_server' or 'reset_server'. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 action but lacks behavioral details: it doesn't specify if this is destructive (likely yes, as it modifies state), permission requirements, rate limits, or what happens post-unassignment (e.g., IP becomes available). This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It's front-loaded and efficiently conveys the core action, though it lacks depth. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with no annotations, 0% schema coverage, and no output schema), the description is incomplete. It doesn't explain the parameter, behavioral implications, or return values, making it inadequate for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. The single parameter 'id' is undocumented in both schema and description, leaving its meaning (e.g., floating IP ID) ambiguous. The description doesn't compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unassign a floating IP' clearly states the action (unassign) and resource (floating IP), which is adequate. However, it doesn't differentiate from sibling tools like 'unassign_primary_ip' or specify what 'unassign' means operationally (e.g., disassociating from a server). It's not tautological but remains somewhat vague.
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 an assigned floating IP), exclusions, or related tools like 'assign_floating_ip' or 'delete_floating_ip'. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Add' which implies a write/mutation operation, but doesn't describe permissions needed, whether this is idempotent, what happens on failure, or any rate limits. The description lacks critical behavioral context for a complex creation 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 extremely concise with a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 7 parameters, nested objects, no annotations, and no output schema, the description is severely inadequate. It doesn't explain what constitutes a 'service', what the tool returns, error conditions, or relationships with other load balancer operations, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 7 parameters (5 required), the description provides no information about any parameters. It doesn't explain what 'id', 'protocol', ports, or nested objects like 'health_check' and 'http' represent, leaving all parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target ('a service to a load balancer'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'add_load_balancer_target' or other load balancer-related tools, missing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing load balancer), exclusions, or relationships with sibling tools like 'create_load_balancer' or 'delete_load_balancer_service'.
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 'Create a new network,' which implies a write/mutation operation, but doesn't disclose any behavioral traits such as required permissions, whether the operation is idempotent, potential side effects (e.g., network configuration changes), rate limits, or what happens on failure. This is a significant gap for a creation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no wasted words—and front-loaded with the core action. It efficiently communicates the basic purpose without unnecessary elaboration, making it easy to parse quickly.
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 (a creation tool with 3 parameters, nested objects, and no output schema) and the lack of annotations (0% coverage), the description is incomplete. It doesn't explain the return value, error conditions, or behavioral context needed for safe and effective use. For a tool that creates network resources, this minimal description is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 3 parameters (name, ip_range, labels) are documented in the schema. The description adds no parameter semantics beyond the tool name—it doesn't explain what 'name', 'ip_range', or 'labels' represent, their formats, constraints, or examples. This leaves all parameters undocumented, failing to compensate for the schema 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 the action ('Create') and resource ('a new network'), making the purpose immediately understandable. It distinguishes from siblings like 'update_network' or 'delete_network' by specifying creation rather than modification or deletion. However, it doesn't specify what a 'network' entails in this context beyond the basic verb+resource.
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 specific permissions or resources), when it's appropriate (e.g., for setting up infrastructure), or what to do instead in different scenarios (e.g., use 'update_network' for modifications). This leaves the agent with minimal context for decision-making.
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. 'Create' implies a write operation, but it doesn't specify permissions needed, whether it's idempotent, what happens on failure, or the response format. This is a significant gap for a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what a placement group is, how it's used, or what the tool returns, leaving critical gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds no information about the three parameters (name, type, labels), their meanings, or constraints (e.g., 'type' has an enum with only 'spread'). It fails to compensate for the schema's lack of 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 states the action ('Create') and resource ('a new placement group'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'update_placement_group' or 'list_placement_groups', but it's not vague or tautological.
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 'update_placement_group' or 'list_placement_groups'. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Create a new SSH key' implies a write/mutation operation but doesn't specify permissions needed, whether the key becomes immediately usable, rate limits, or what happens on failure. For a creation 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 extremely concise at just 4 words, with zero wasted language. It's front-loaded with the essential action and resource. While it may be too brief for completeness, as a standalone statement it's perfectly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, what the parameters mean, or any behavioral aspects. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 3 parameters (name, public_key, labels) are documented in the schema. The description provides no information about any parameters, not even mentioning that parameters exist. This leaves the agent completely in the dark about what inputs are needed.
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 ('SSH key'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'update_ssh_key' or 'delete_ssh_key', but the verb+resource combination is specific enough for basic understanding.
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 'update_ssh_key' or 'list_ssh_keys'. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent with minimal context for decision-making.
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 that deletion unassigns from servers if attached, which is useful behavioral context. However, it doesn't disclose critical details like whether this action is reversible, requires specific permissions, has rate limits, or what happens to associated resources beyond unassignment.
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 with no wasted words. It front-loads the core action ('Delete a floating IP') and adds essential clarification in parentheses, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on error conditions, return values, side effects (e.g., billing implications), and doesn't fully compensate for the missing structured information, leaving gaps for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the 'id' parameter. It doesn't explain what the ID represents (e.g., numeric identifier of the floating IP), how to obtain it, or format requirements, leaving the parameter's meaning unclear beyond the schema's type constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('floating IP'), making the purpose evident. It distinguishes from 'unassign_floating_ip' by specifying that deletion also unassigns if attached, but doesn't explicitly contrast with other deletion tools like 'delete_server' or 'delete_primary_ip'.
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 'unassign_floating_ip' or other deletion tools. The description implies usage for removing floating IPs, but lacks context on prerequisites, consequences, or typical workflows.
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 'Delete' which implies a destructive, irreversible mutation, but doesn't specify permissions required, side effects (e.g., if it affects traffic routing), error conditions, or confirmation steps. This is a significant gap for a destructive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with 2 undocumented parameters, no annotations, and no output schema, the description is inadequate. It lacks critical details like parameter meanings, behavioral traits (e.g., idempotency, error handling), and expected outcomes, leaving the agent poorly equipped to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds no information about the two required parameters ('id' and 'listen_port'), such as what they represent (e.g., load balancer ID vs. service ID, port ranges), units, or constraints. This fails to compensate for the schema's lack of 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 action ('Delete') and resource ('a service from a load balancer'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'delete_load_balancer' or 'remove_load_balancer_target', which would require more specificity about what constitutes a 'service' versus other load balancer components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., whether the load balancer must exist or be in a specific state), exclusions, or comparisons to siblings like 'delete_load_balancer' or 'remove_load_balancer_target', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Delete' which implies a destructive, irreversible mutation, but doesn't disclose behavioral traits like required permissions, confirmation prompts, error conditions (e.g., if key is in use), or what happens post-deletion (e.g., immediate effect). This is inadequate for a destructive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste—'Delete an SSH key' is maximally concise. Every word earns its place, and there's no redundant or verbose language, making it easy to parse quickly.
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 destructive nature, lack of annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It doesn't cover critical aspects like success/error responses, side effects, or dependencies, leaving significant gaps for safe and correct usage by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter (id) with 0% description coverage, and the description adds no meaning beyond the schema. It doesn't explain what 'id' refers to (e.g., SSH key ID from list_ssh_keys), its format, or constraints. With low schema coverage, the description fails to compensate, leaving the parameter undocumented.
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 'Delete an SSH key' clearly states the verb (delete) and resource (SSH key), making the purpose immediately understandable. It distinguishes from sibling tools like 'create_ssh_key' and 'update_ssh_key' by specifying the delete action. However, it doesn't specify scope (e.g., from a server, account, or project), 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., SSH key must exist), exclusions, or related tools like 'list_ssh_keys' for reference. Without annotations or context, the agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the action but doesn't explain effects (e.g., if the server restarts, if data is lost, permissions required, or rate limits). This leaves critical behavioral traits undocumented for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it easy to parse. It's appropriately sized for the tool's apparent simplicity, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on behavior, parameters, and outcomes, failing to provide sufficient context for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description doesn't mention the 'id' parameter at all. It fails to add any meaning beyond the bare schema, such as what the ID refers to (server ID, ISO ID, or another resource) or format examples, leaving the parameter's purpose unclear.
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 ('detach') and the resource ('ISO from a server'), making the purpose immediately understandable. However, it doesn't differentiate from its sibling 'attach_iso' beyond the opposite action, missing explicit contrast in usage context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'attach_iso' or other server modification tools. The description lacks context about prerequisites, such as whether an ISO must be attached first, or when this operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List all images' implies a read-only operation, but it doesn't specify aspects like pagination, sorting, filtering, rate limits, authentication needs, or what 'all' entails (e.g., scope or limits). This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('List all images'), consisting of a single, front-loaded sentence with no wasted words. It's appropriately sized for a simple listing tool, though it could benefit from more detail without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a listing operation with no parameters) and lack of annotations or output schema, the description is incomplete. It doesn't explain return values, behavioral traits, or usage context, leaving the agent with minimal guidance. For a tool in a server with many siblings, more completeness is needed to aid selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description doesn't add parameter details, but that's appropriate here. Baseline is 4 for 0 parameters, as the schema fully covers the absence of inputs, and the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all images' clearly states the verb ('List') and resource ('images'), providing a basic purpose. However, it doesn't differentiate from sibling tools like 'list_servers' or 'list_volumes' beyond the resource name, making it somewhat vague about what makes this listing operation unique. It's not tautological but lacks specificity.
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. With many sibling tools for listing different resources (e.g., 'list_servers', 'list_volumes'), there's no indication of context, prerequisites, or exclusions. Usage is implied by the resource name alone, but no explicit guidelines are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'soft' reboot, implying a graceful shutdown versus a hard reset, but fails to disclose critical behavioral traits: whether this requires specific permissions, if it's destructive (likely yes, but unspecified), expected downtime, error conditions, or what 'soft' entails operationally. This leaves significant gaps 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 extremely concise—a single, front-loaded sentence with no wasted words. Every part ('reboot', 'server', 'soft') earns its place by conveying essential information efficiently.
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 (a mutation tool with potential downtime), lack of annotations, no output schema, and 0% schema coverage, the description is incomplete. It omits critical details: behavioral implications, parameter semantics, error handling, and output expectations, making it inadequate for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with one parameter ('id') undocumented in both schema and description. The description adds no meaning about the parameter—it doesn't explain what 'id' refers to (e.g., server ID), its format, or where to obtain it. This fails to compensate for the lack of 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 ('reboot') and resource ('a server'), with the qualifier '(soft)' providing additional specificity about the type of reboot. It distinguishes from siblings like 'reset_server' and 'shutdown_server' by specifying a soft reboot, though it doesn't explicitly contrast with these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'reset_server', 'shutdown_server', 'power_off_server', or 'power_on_server'. The description lacks context about prerequisites (e.g., server state), exclusions, or comparative scenarios, leaving usage ambiguous.
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 'Remove' implies a destructive mutation, it doesn't specify whether this requires specific permissions, if the action is reversible, what happens to load balancer traffic during removal, or error conditions. This is inadequate for a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable at a basic level.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with 5 parameters (including complex nested objects), 0% schema coverage, no annotations, and no output schema, the description is severely incomplete. It provides only basic purpose without addressing behavioral implications, parameter meanings, or expected outcomes, leaving critical gaps for safe and correct tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain the 'id' parameter (load balancer ID?), the 'type' enum values, or the nested objects for different target types. With 5 parameters (including complex nested objects) completely undocumented, this creates significant ambiguity for proper tool invocation.
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 ('Remove') and resource ('a target from a load balancer'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'delete_load_balancer_target' (which doesn't exist in the list) or 'delete_load_balancer_service', leaving some ambiguity about scope.
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 about when to use this tool versus alternatives. The description doesn't mention prerequisites, consequences, or relationships with sibling tools like 'add_load_balancer_target' or 'delete_load_balancer', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'soft' shutdown, which suggests a graceful rather than forced termination, but doesn't explain what 'soft' means operationally, whether data is preserved, how long it takes, or what permissions are required. For a destructive operation with zero annotation coverage, this leaves significant 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 extremely concise - just 4 words - and front-loads the essential information. Every word earns its place: 'shutdown' (action), 'server' (resource), and '(soft)' (qualifier). There's zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive server operation with no annotations, no output schema, and 0% parameter documentation, the description is insufficient. It doesn't explain what 'soft' shutdown entails, what happens to running processes/data, whether the operation is reversible, what permissions are needed, or what the response looks like. The context demands more complete disclosure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the single parameter 'id' is completely undocumented in the schema. The description adds no information about what 'id' represents (server ID), what format it should have, or where to find it. This leaves the agent guessing about the parameter's meaning and source.
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 ('shutdown') and target resource ('a server'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'power_off_server' or 'reboot_server' beyond the '(soft)' qualifier, which provides some distinction but not explicit comparison.
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 'power_off_server', 'reboot_server', or 'reset_server'. There's no mention of prerequisites, consequences, or appropriate contexts for choosing this specific shutdown method.
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 an update operation (implying mutation), but doesn't cover critical aspects like required permissions, whether changes are reversible, error conditions, or rate limits. 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 extremely concise with just four words, front-loading the essential information. Every word earns its place by specifying the action, resource, and updatable fields without any redundant or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't address behavioral risks, parameter details beyond a partial list, or expected outcomes. Given the complexity of updating a firewall (which could affect network security), more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'name, labels' which maps to two of the three parameters, but doesn't explain the 'id' parameter (required for identifying which firewall to update) or provide any details about format, constraints, or how labels should be structured. This leaves key parameters inadequately documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('a firewall'), and specifies which fields can be updated ('name, labels'). This distinguishes it from sibling tools like 'create_firewall' and 'delete_firewall' by focusing on modification rather than creation or deletion.
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 an existing firewall ID), compare it to similar tools like 'update_network' or 'update_server', or specify scenarios where it's appropriate versus not.
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's an update operation. It doesn't disclose permission requirements, whether changes are reversible, rate limits, or what happens to unspecified fields. 'Update' implies mutation but lacks behavioral details needed for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single parenthetical phrase—with zero wasted words. It's front-loaded with the core action and efficiently lists updatable fields, though this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters (1 required), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the update behavior, parameter usage, or what to expect upon success/failure, leaving too much undefined for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only lists parameters ('name, labels') without explaining their purpose, format, or constraints. It doesn't mention the required 'id' parameter or clarify that 'labels' is an object with string values, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('a load balancer'), and specifies what can be updated ('name, labels'). It distinguishes this from create/delete operations but doesn't explicitly differentiate from other update tools like update_firewall or update_server.
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. While sibling tools include create_load_balancer and delete_load_balancer, the description doesn't mention prerequisites (e.g., requires existing load balancer) or when to choose this over other update operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It indicates this is a mutation tool ('Update'), but doesn't disclose permissions required, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool with zero annotation coverage, 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 extremely concise (5 words) and front-loaded with the essential action and resource. Every word earns its place with no wasted text, though this conciseness comes at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It lacks crucial information about behavioral traits, parameter details beyond field names, and expected outcomes, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds limited value. It mentions 'name' and 'labels' as updatable fields, which helps interpret two of the three parameters, but doesn't explain the 'id' parameter's purpose or provide any format/constraint details. This partially compensates but leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('a placement group'), and specifies the updatable fields ('name, labels'). However, it doesn't explicitly differentiate from sibling tools like 'create_placement_group' or 'delete_placement_group' beyond the obvious 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?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing placement group ID), compare with similar tools (like 'create_placement_group'), or indicate when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool performs an update operation but doesn't disclose critical traits: whether it requires specific permissions, if changes are reversible, what happens to existing fields not mentioned, or potential side effects (e.g., impact on associated resources). The description is minimal and lacks behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single phrase that efficiently conveys the core functionality. It's front-loaded with the essential information (update action and modifiable fields) without any redundant or verbose language. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with 3 parameters, nested objects, no annotations, and no output schema), the description is incomplete. It doesn't address behavioral aspects, fully explain parameters, or provide usage context. For a tool that modifies resources, more information about effects, requirements, and output would be necessary for adequate understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'name, labels' which correspond to two of the three parameters, but doesn't explain the 'id' parameter (required) or provide any semantic details about format, constraints, or usage. The description adds minimal value beyond naming some parameters without context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('Primary IP') along with the specific fields that can be modified ('name, labels'). It distinguishes from sibling tools like 'create_primary_ip' and 'delete_primary_ip' by focusing on modification rather than creation or deletion. However, it doesn't specify what a Primary IP is or its role in the system.
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. The description doesn't mention prerequisites (e.g., needing an existing Primary IP), exclusions, or comparisons to related tools like 'assign_primary_ip' or 'unassign_primary_ip'. Usage is implied through the verb 'Update' but lacks contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutation operation ('Update') but doesn't specify permissions required, whether changes are reversible, side effects (e.g., downtime), or response format. This is inadequate for a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core action and fields. Every word earns its place, making it 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's mutation nature, no annotations, no output schema, and low schema coverage (0%), the description is incomplete. It lacks critical details like behavioral traits, parameter meanings beyond basic names, and usage context, making it insufficient for safe and effective agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'name' and 'labels' as updatable fields, which partially maps to two of the three parameters, but doesn't explain the 'id' parameter's role or provide any syntax or format details beyond the schema. This adds limited value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('a server'), and specifies the updatable fields ('name, labels'), which provides a specific verb+resource combination. However, it doesn't explicitly differentiate this from other update tools like 'update_firewall' or 'update_volume' beyond the resource type, preventing 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 prerequisites (e.g., server existence), exclusions (e.g., what cannot be updated), or comparisons to sibling tools like 'change_server_type' or 'reset_server', leaving the agent with minimal contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates an SSH key, implying a mutation operation, but lacks critical details: it doesn't specify required permissions, whether changes are reversible, error conditions (e.g., invalid ID), or what happens to unspecified fields (e.g., if only name is provided, are labels preserved?). This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single, efficient sentence that front-loads the core action ('Update an SSH key') and specifies updatable fields. There is zero waste or redundancy, making it easy to parse quickly.
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 (mutation with 3 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It lacks behavioral context (e.g., side effects, error handling), parameter details, and output expectations. For a mutation tool with zero annotation coverage, this minimal description is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions parameters ('name, labels') but doesn't explain their semantics: 'id' is required but not mentioned, 'name' purpose is unclear (e.g., display name vs identifier), and 'labels' structure/usage is undefined. The description adds minimal value beyond the schema, failing to address 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 the verb ('Update') and resource ('SSH key'), and specifies what can be updated ('name, labels'). It distinguishes from sibling tools like 'create_ssh_key' and 'delete_ssh_key' by focusing on modification rather than creation or deletion. However, it doesn't explicitly differentiate from other update tools like 'update_server' or 'update_volume' in terms of resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 an existing SSH key ID), exclusions, or comparisons to other tools like 'create_ssh_key' for initial setup or 'list_ssh_keys' for viewing existing keys. Usage is implied by the action but not explicitly 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is an update operation (implying mutation) but doesn't disclose critical behavioral traits: whether it requires specific permissions, if changes are reversible, what happens to unspecified fields (partial vs. full updates), rate limits, or error conditions. For a mutation 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 extremely concise (5 words) and front-loaded with the essential action and resource. Every word earns its place, with no redundant or verbose phrasing. It efficiently communicates the core purpose without 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?
Given the complexity (mutation tool with 3 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It lacks behavioral context (permissions, side effects), parameter details (especially the required 'id'), and doesn't address what the tool returns or how to handle errors. For a tool that modifies resources, this level of brevity leaves too many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'name, labels' which maps to two of the three parameters (name, labels), but doesn't explain the required 'id' parameter or provide any semantic context beyond naming the fields. The description adds minimal value over the schema, failing 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 the verb ('Update') and resource ('a volume'), and specifies what can be updated ('name, labels'). It distinguishes from sibling tools like 'create_volume' or 'delete_volume' by focusing on modification rather than creation or deletion. However, it doesn't explicitly differentiate from other 'update_' tools (e.g., update_server, update_network) beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 an existing volume ID), when not to use it (e.g., for creating vs. updating), or refer to sibling tools like 'create_volume' or 'list_volumes' for context. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'add' (implying mutation) and gives an example, but lacks critical details: required permissions, whether the operation is idempotent, error conditions (e.g., overlapping IP ranges), or what happens on success/failure. For a mutation tool with zero annotation coverage, 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 a single, efficient sentence with zero waste. It front-loads the core action ('Add a subnet to a network') and includes a helpful example in parentheses. Every word earns its place, making it easy to parse quickly.
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 (mutation with 5 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral context (e.g., side effects, error handling), output expectations, and sufficient usage guidance. While concise, it doesn't compensate for the missing structured data, leaving the agent under-informed.
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 80%, providing a strong baseline. The description adds marginal value by implying 'ip_range' is optional ('omit for auto /24'), which aligns with schema details. However, it doesn't clarify parameter interactions (e.g., 'vswitch_id' dependency on 'type') or semantics beyond the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a subnet') and resource ('to a network'), with a specific example ('private networking 10.0.0.0/16 in a zone'). It distinguishes from siblings like 'create_network' (creating vs. modifying) and 'delete_network_subnet' (add vs. delete), though not explicitly named. The purpose is specific but could better differentiate from similar tools like 'attach_server_to_network'.
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 is provided. The example hints at usage for private networking, but there's no mention of prerequisites (e.g., network must exist), exclusions, or comparisons to siblings like 'update_network'. Usage is implied rather than clearly defined, leaving gaps for an AI agent.
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 states the action but doesn't mention permissions required, whether the server must be powered off, if this affects server operation, what happens if an ISO is already attached, or what the response looks like. For a mutation tool with zero annotation coverage, 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 a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple tool with only 2 parameters.
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, no output schema, and incomplete parameter documentation, the description is insufficient. It doesn't address behavioral aspects like side effects, error conditions, or response format that would help an agent use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'iso' parameter has a description). The tool description doesn't add any parameter information beyond what's in the schema - it doesn't explain what 'id' refers to (server ID), doesn't clarify ISO format requirements, or provide examples. With partial schema coverage, the description doesn't compensate for the gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('attach') and target resource ('ISO to a server'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'detach_iso', but it's not misleading or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'detach_iso' or other server modification tools. The description only states what it does, not when it's appropriate or what prerequisites might be needed.
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. 'Attach' implies a mutation operation, but it doesn't disclose whether this requires specific permissions, if it's reversible, potential side effects (e.g., network downtime), rate limits, or what happens on success/failure. For a mutation 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, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word earns its place, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters, 50% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't cover behavioral aspects, parameter meanings beyond the schema, error conditions, or return values. The agent lacks critical context to use this tool effectively and safely.
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 50% (only 'network' and 'ip' have descriptions), and the description adds no parameter information beyond the tool name. It doesn't explain what 'id' refers to (server ID), the format of 'alias_ips', or constraints on 'ip' assignment. The baseline is 3 because the schema provides some documentation, but the description fails to 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 the action ('attach') and resource ('server to a network'), making the purpose immediately understandable. It distinguishes from sibling tools like 'detach_server_from_network' by specifying the opposite operation, though it doesn't explicitly contrast with other network-related tools like 'create_network' or 'add_network_subnet'.
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., server must exist, network must be available), exclusions (e.g., cannot attach to multiple networks simultaneously), or related tools like 'detach_server_from_network' for reversal. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Delete' which implies a destructive mutation, but doesn't mention if this action is reversible, requires specific permissions, has side effects (e.g., removing associated services/targets), or what happens on success/failure. This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Delete a load balancer') with zero wasted words, making it front-loaded and easy to parse. Every word earns its place, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a destructive tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't cover behavioral traits, parameter meaning, or expected outcomes, leaving the agent with insufficient information to use the tool safely and 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 input schema has 1 parameter with 0% description coverage, so the description must compensate. It doesn't mention the 'id' parameter at all, leaving it undocumented. However, since there's only one parameter and 'delete' implies an identifier is needed, the baseline is 3—adequate but with a clear gap in explaining what 'id' represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a load balancer'), which provides a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'delete_load_balancer_service' or 'delete_server', leaving some ambiguity about scope.
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 'update_load_balancer' or 'list_load_balancers', nor does it mention prerequisites (e.g., needing the load balancer ID from a list operation). It simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Delete' implies a destructive mutation, but the description doesn't specify whether this action is reversible, requires specific permissions, has side effects, or returns confirmation data. This leaves critical behavioral aspects undocumented.
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 maximally concise with a single, clear sentence that front-loads the essential information. There's no wasted language or 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 destructive mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't address behavioral risks, parameter meaning, return values, or usage context, leaving significant gaps for an AI agent to understand how to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description doesn't mention the 'id' parameter at all, providing no additional meaning beyond what the bare schema indicates. However, with only one parameter, the baseline is higher than for multi-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a placement group'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'delete_server' or 'delete_network', but the specificity of 'placement group' provides inherent differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., whether the placement group must be empty), consequences, or relationships with sibling tools like 'list_placement_groups' or 'update_placement_group'.
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 the basic action without behavioral details. It doesn't disclose if this requires specific permissions, is destructive (likely yes, as it changes network configuration), has side effects, or what happens on success/failure.
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 easy to parse quickly.
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, no output schema, and incomplete parameter documentation, the description is inadequate. It lacks crucial context about behavioral impact, error conditions, and usage scenarios, leaving significant gaps for an AI agent to understand when and how to invoke it safely.
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 50% (only 'network' parameter has a description). The description adds no parameter semantics beyond the schema, but the parameters are straightforward (server ID and network ID). With two required parameters and partial schema coverage, the baseline 3 is appropriate as the description doesn't 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 the action ('detach') and resource ('server from a network'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'detach_iso' or 'detach_volume', which follow the same pattern but target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., server must be powered off), consequences (e.g., network connectivity loss), or related tools like 'attach_server_to_network' for reattachment.
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. 'Get all prices' implies a read-only operation, but it doesn't disclose behavioral traits like whether it requires authentication, rate limits, pagination, or what format the prices are returned in (e.g., JSON, structured data). For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the core action. There's no wasted language or redundancy. For a simple tool with no parameters, this brevity is efficient and clear.
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 apparent simplicity (0 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'prices' refers to in this context (e.g., cloud service pricing, all resources), how results are structured, or any limitations. For a tool in a server with many sibling operations, more context is needed to understand its role fully.
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 doesn't add parameter details, which is appropriate here. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all prices' states the basic action (get) and resource (prices), but it's vague about scope and format. It doesn't specify what type of prices (e.g., server pricing, volume pricing, all services) or distinguish from potential siblings like list_server_types which might include pricing info. The purpose is understandable but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools (e.g., list_server_types, list_volumes) that might include pricing details, the description doesn't clarify if this is a comprehensive pricing endpoint or how it relates to other listing tools. There's no mention of prerequisites or context for use.
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 'Get a single Primary IP by ID', implying a read-only operation, but doesn't specify if it requires authentication, rate limits, error handling, or what the output looks like. 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 a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary details, earning a top score for brevity and clarity.
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, no output schema, and low parameter semantics, the description is incomplete. It lacks details on behavior, usage context, and output format, making it insufficient for a tool that likely returns structured data. More information is needed to fully guide an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with one parameter 'id' of type 'number' documented only in the schema. The description adds minimal semantics by specifying 'by ID', clarifying it's an identifier, but doesn't explain format, constraints, or examples. Baseline is 3 as the schema provides basic structure, but the description doesn't 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 the verb 'Get' and the resource 'Primary IP by ID', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_primary_ips' or 'update_primary_ip', which would require mentioning it's for retrieving a single specific instance rather than listing or modifying.
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_primary_ips' for multiple IPs or 'update_primary_ip' for modifications, nor does it specify prerequisites such as needing a valid ID or when this tool is appropriate in workflows.
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. 'List all locations' implies a read-only operation but doesn't disclose behavioral traits like pagination, rate limits, authentication requirements, or what 'all' means (e.g., all accessible locations vs. all in system). For a 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 extremely concise with just three words, front-loaded with the core action. There's zero waste or unnecessary elaboration, making it easy to parse while still conveying the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple 0-parameter tool, the description is incomplete. It doesn't explain what 'locations' are, what data is returned, or how this differs from other list tools. For adequate context, it should clarify the resource type and typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of parameters. The description doesn't need to add parameter information, and 'List all locations' appropriately implies no filtering parameters are needed. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all locations' clearly states the verb ('List') and resource ('locations'), but it's vague about scope and doesn't distinguish from sibling tools like 'list_datacenters' or 'list_servers'. It provides basic purpose but lacks specificity about what 'locations' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. With many sibling list tools (e.g., list_datacenters, list_servers, list_networks), the description doesn't explain what makes 'locations' different or when it should be preferred over other listing 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. 'List all networks' implies a read-only operation, but it doesn't specify critical details like whether it returns all networks at once (vs. paginated), the format of the output (e.g., JSON array), error conditions (e.g., if no networks exist), or any rate limits. This leaves significant gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'List all networks' is extremely concise—three words that directly convey the core action. It's front-loaded with the verb and resource, leaving no wasted space. For a simple list operation with no parameters, this brevity is efficient and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation with no parameters) and lack of annotations or output schema, the description is incomplete. It doesn't explain what the output contains (e.g., network IDs, names, statuses) or behavioral aspects like pagination or error handling. For a tool in a server management context with many siblings, more context would help the agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't add parameter details, which is appropriate since there are none to explain. It accurately reflects the tool's lack of inputs, so it meets the baseline for zero-parameter tools without introducing confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all networks' clearly states the verb ('List') and resource ('networks'), making the basic purpose understandable. However, it lacks specificity about what 'networks' refers to in this context (e.g., virtual networks, network configurations) and doesn't differentiate from sibling tools like 'list_servers' or 'list_load_balancers' beyond the resource name. This makes it vague but not tautological or misleading.
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), context (e.g., after creating a network), or comparisons to siblings like 'get_primary_ip' or 'list_firewalls'. Without any usage hints, the agent must infer context solely from the tool name and sibling list.
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. 'List all servers' implies a read-only operation, but it doesn't specify whether this requires authentication, returns paginated results, includes metadata, or has rate limits. For a tool with zero annotation coverage, this leaves significant 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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place in this minimal but complete phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is incomplete. It doesn't address behavioral aspects like authentication needs, response format, pagination, or error handling. With no annotations and no output schema, 'List all servers' leaves too many contextual questions unanswered for effective agent 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 with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and 'List all servers' appropriately implies no filtering parameters. Baseline 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all servers' clearly states the verb ('List') and resource ('servers'), but it's vague about scope and doesn't differentiate from sibling tools like 'list_server_types' or 'list_actions'. It provides basic purpose but lacks specificity about what 'all servers' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that also list resources (e.g., 'list_server_types', 'list_actions', 'list_volumes'), there's no indication of when this specific listing tool is appropriate versus others. No 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 full burden. It indicates a destructive action ('power off') but lacks details on permissions, reversibility (e.g., via 'power_on_server'), side effects (e.g., data loss), or rate limits. The '(hard)' hint adds some context but is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations, 0% schema coverage, and no output schema, the description is inadequate. It lacks critical details like behavioral traits, parameter meaning, and usage context, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, with one parameter 'id' undocumented. The description adds no parameter details beyond implying it targets a server. Baseline is 3 due to low coverage, but the description doesn't compensate by explaining the 'id' format or requirements.
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 ('power off') and target ('a server'), with the qualifier '(hard)' suggesting a forceful shutdown. It distinguishes from sibling tools like 'shutdown_server' (likely graceful) and 'reboot_server' (restart), but could be more explicit about the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'shutdown_server' or 'reboot_server'. The description implies a hard power-off but doesn't specify scenarios (e.g., for unresponsive servers or maintenance).
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 'hard' reset, which implies more forceful behavior than a standard reboot, but doesn't disclose critical details like whether this causes data loss, requires specific permissions, affects uptime, or has irreversible consequences. For a potentially destructive operation with zero annotation coverage, 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 extremely concise—just four words—and front-loaded with the core action. Every word earns its place: 'reset' (action), 'server' (resource), 'hard' (modifier). No wasted words or redundant phrasing.
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 potentially destructive tool with no annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't explain what 'hard' means, what the parameter represents, what happens during the reset, or what the agent should expect as a result. This leaves significant gaps for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't mention the 'id' parameter at all, leaving it completely undocumented. However, since there's only one parameter, the baseline is higher, but the description adds no semantic value beyond what the schema name implies.
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 ('reset') and resource ('server'), and specifies it's a 'hard' reset, which distinguishes it from softer resets like reboot. However, it doesn't explicitly differentiate from sibling tools like 'reboot_server' or 'power_off_server' in terms of what 'hard' means operationally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'reboot_server' or 'power_off_server'. The description mentions 'hard' but doesn't explain the implications or when this type of reset is appropriate versus other power management 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 for behavioral disclosure. It states this is an update operation but doesn't mention required permissions, whether changes are reversible, potential side effects, or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 purpose. Every word earns its place with no wasted text or redundancy. It's appropriately sized for a simple update operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It should explain more about the update behavior, parameter requirements, and what to expect in response. The current description leaves too many contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'description, labels' which maps to two of the three parameters, but doesn't explain the required 'id' parameter or provide any format details for labels. It adds some value but doesn't 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 the action ('Update') and resource ('floating IP'), and specifies which attributes can be updated ('description, labels'). It distinguishes this from create/delete floating IP tools in the sibling list. However, it doesn't explicitly differentiate from other update tools like update_server or update_network, 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing floating IP), exclusions, or comparisons to sibling tools like assign_floating_ip or unassign_floating_ip. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the tool updates fields but doesn't disclose permissions needed, whether changes are reversible, rate limits, or what happens to unspecified fields. For a mutation tool, this leaves critical behavioral traits undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just four words, front-loading the essential action and fields. There's no wasted language, making it efficient for quick scanning while covering the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It lacks behavioral context (e.g., side effects, permissions), doesn't fully explain parameters, and provides no output information, leaving the agent with significant uncertainty about tool invocation and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds some value by listing updatable fields ('name, labels'), which maps to two of the three parameters. However, it doesn't explain the 'id' parameter's purpose or provide format details for 'labels' (e.g., key-value pairs), leaving gaps in parameter understanding.
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 ('Update') and resource ('a network'), and specifies what can be updated ('name, labels'). It distinguishes from other network-related tools like 'create_network' or 'delete_network' by focusing on modification rather than creation or deletion.
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. While it's implied for modifying existing networks, there's no mention of prerequisites (e.g., network must exist), constraints, or comparisons to similar tools like 'update_firewall' or 'update_server' 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.
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. 'List all volumes' implies a read-only operation, but it doesn't specify whether it requires permissions, returns paginated results, includes metadata, or has rate limits. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
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 'List all volumes' is extremely concise—three words that directly convey the core action. It's front-loaded with the verb and resource, with no wasted words or unnecessary elaboration. This efficiency makes it easy to parse and understand at a glance.
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 minimally adequate but lacks depth. It doesn't explain what 'volumes' are in this context or what the output might look like (e.g., a list of volume objects). For a basic list operation, it meets the bare minimum but could benefit from slight elaboration to enhance usability.
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 doesn't add parameter details, which is appropriate here. Baseline is 4 for 0 parameters, as the schema fully covers the absence of inputs, and the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all volumes' clearly states the verb ('List') and resource ('volumes'), making the basic purpose understandable. However, it lacks specificity about what 'volumes' refers to (e.g., storage volumes in a cloud context) and doesn't differentiate from siblings like 'list_servers' or 'list_networks', which follow a similar pattern. It avoids tautology but remains somewhat vague without contextual elaboration.
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 (e.g., filtered volumes), or related tools like 'create_volume' or 'delete_volume' from the sibling list. Without such context, an agent might struggle to apply it appropriately in complex scenarios.
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. 'List all firewalls' implies a read-only operation but doesn't specify details like pagination, rate limits, authentication requirements, or output format. For a tool with zero annotation coverage, this leaves significant behavioral gaps, making it inadequate for informed use.
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 'List all firewalls' is a single, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for a simple tool, making it easy to parse and understand quickly.
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 the tool returns (e.g., a list of firewall objects, error conditions) or behavioral aspects like permissions. For a tool in a complex server environment with many siblings, more context is needed to ensure 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 no parameter documentation is needed. The description doesn't add parameter details, which is appropriate. A baseline of 4 is applied since the schema fully handles parameters, 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 'List all firewalls' clearly states the verb ('List') and resource ('firewalls'), making the purpose immediately understandable. It distinguishes from siblings like 'create_firewall', 'delete_firewall', and 'update_firewall' by indicating a read-only operation. However, it lacks specificity about what 'all' entails (e.g., scope or filtering), preventing 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 prerequisites, context for listing firewalls, or how it differs from other list operations (e.g., 'list_servers'). Without any usage instructions, the agent must infer context from sibling tools, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List all load balancers' implies a read-only operation but doesn't specify whether this requires authentication, what format the results come in, whether there's pagination, or any rate limits. For a tool with zero annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's perfectly front-loaded with the essential information and earns its place as the minimum viable description for this simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a listing tool. It doesn't explain what information is returned about load balancers, whether results are filtered or paginated, or any error conditions. While the tool is simple, the description leaves too many behavioral questions unanswered.
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 there are no parameters to document. The description appropriately doesn't discuss parameters, which aligns with the schema. A baseline of 4 is appropriate for tools with zero parameters that don't need parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all load balancers' clearly states the verb ('List') and resource ('load balancers'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'list_load_balancer_types', but the specificity of 'load balancers' versus 'load balancer types' provides implicit distinction.
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. With siblings like 'get_pricing' or 'list_load_balancer_types', there's no indication of when this listing tool is appropriate versus other list operations or how it relates to creation/deletion tools for load balancers.
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. 'List all SSH keys' implies a read-only, non-destructive operation, but it doesn't specify authentication requirements, rate limits, pagination, error handling, or output format. 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 a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan. Every word ('List', 'all', 'SSH keys') contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimal but incomplete. It lacks context on authentication, output structure, pagination, or error scenarios. For a list operation in a server management context, more behavioral details would help the agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% description coverage, so no parameters need documentation. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied for zero-parameter tools, 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 'List all SSH keys' clearly states the verb ('List') and resource ('SSH keys') with the scope 'all'. It distinguishes this tool from sibling tools like 'create_ssh_key' and 'delete_ssh_key' by indicating it's a read operation. However, it doesn't specify if it lists keys for a specific user, account, or project, which could differentiate it further from potential alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), context (e.g., after creating a key), or exclusions (e.g., not for filtering). With sibling tools like 'get_primary_ip' for specific retrieval, the lack of comparison leaves usage ambiguous.
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 a critical constraint ('must not be in use'), which is valuable, but fails to address other important aspects such as permissions required, whether the deletion is permanent or reversible, error handling, or what happens to associated resources. This leaves significant gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no wasted words—and front-loads the core action ('Delete a firewall') followed by a critical constraint. Every part earns its place, 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?
For a destructive tool with no annotations and no output schema, the description is incomplete. It lacks details on permissions, side effects, return values, error conditions, and how to verify if a firewall is 'in use'. Given the complexity and risk of deletion operations, this leaves the agent with insufficient guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description provides no information about the 'id' parameter beyond what the schema implies (it's a number). However, with only one parameter and a straightforward operation, the baseline is 3 as the minimal context is somewhat adequate, though no additional semantic value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete') and resource ('a firewall'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'delete_network' or 'delete_server' beyond the resource type, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an implied usage guideline with 'must not be in use', suggesting a prerequisite condition. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., 'update_firewall' for modifications) or mention any other contextual constraints.
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 the prerequisite to detach servers first, which is valuable context about destructive behavior. However, it doesn't disclose other important traits: whether deletion is permanent/reversible, what permissions are required, what happens to other resources attached to the subnet, or what the response looks like. For a destructive operation 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 extremely concise - a single sentence with a parenthetical note. It's front-loaded with the core action and target, and the prerequisite warning is efficiently included. Every word serves a purpose with zero 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?
For a destructive operation with no annotations and no output schema, the description is incomplete. While it mentions the server detachment prerequisite, it doesn't cover other critical aspects: whether the operation is idempotent, what error conditions exist, what the return value contains, or what happens to other subnet resources. Given the tool's complexity and lack of structured documentation, 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 both parameters ('id' and 'ip_range') clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target ('a subnet from a network'), making the purpose immediately understandable. It distinguishes from siblings like 'delete_network' (which deletes entire networks) by specifying subnet deletion. However, it doesn't explicitly mention what happens to the subnet's resources beyond the parenthetical note about servers.
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 guidance with the parenthetical '(detach servers from it first)', suggesting a prerequisite condition for successful use. However, it doesn't explicitly state when to use this tool versus alternatives like 'detach_server_from_network' or provide clear exclusion criteria. No explicit comparison to sibling 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 full burden. It states it's a list operation but doesn't disclose behavioral traits like pagination, rate limits, authentication requirements, or what format the data returns. The example 'ash-dc1' hints at format but isn't comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core purpose, includes an example and context efficiently. 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?
For a simple list tool with no parameters and no output schema, the description is adequate but lacks details on behavior and output. Without annotations, it should ideally mention return format or constraints, but the core purpose is clear.
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. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. Baseline is 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('all datacenters') with a specific example ('ash-dc1') and context ('where servers can be created'). It distinguishes from siblings by focusing on datacenters, but doesn't explicitly differentiate from similar list tools like list_locations or list_servers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description mentions 'where servers can be created' which implies a use case, but doesn't specify when to choose this over other list tools or what prerequisites might be needed.
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. 'List all floating IPs' implies a read-only operation but doesn't specify whether it returns all floating IPs in the system, if there are pagination limits, authentication requirements, or rate limits. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and gets straight to the point, making it easy 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 simplicity (0 parameters, no output schema), the description is adequate but has clear gaps. It lacks behavioral details like pagination or authentication, and without annotations or output schema, it doesn't fully prepare an agent for usage. It meets the minimum viable standard but could be more informative.
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 doesn't add parameter information, but since there are no parameters, this is acceptable. Baseline is 4 for 0 parameters, as the description doesn't need to compensate for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all floating IPs' clearly states the verb ('List') and resource ('floating IPs'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_primary_ip' or 'list_primary_ips' which might list similar network resources, so it doesn't reach the highest 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_primary_ips' or 'get_primary_ip' that might list related resources, nor does it specify any prerequisites or contexts for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'List all placement groups' but doesn't describe output format, pagination, sorting, error conditions, or authentication needs. For a read-only list operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond its 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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable. Every word ('List all placement groups') directly contributes to understanding the tool's purpose 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?
Given the tool's low complexity (0 parameters, list operation) and lack of annotations/output schema, the description is minimally adequate. It states what the tool does but lacks details on behavior, output, or usage context. For a simple list tool, this might suffice, but it doesn't provide complete guidance for an agent to use it effectively without additional assumptions.
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% (empty schema). The description doesn't need to add parameter details, so it meets the baseline. No parameters means no semantic gaps to compensate for, and the description correctly implies no inputs are required for listing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('placement groups'), making the purpose immediately understandable. It distinguishes from siblings like 'create_placement_group' and 'delete_placement_group' by specifying listing rather than modification. However, it doesn't specify scope (e.g., 'all' is implied but not explicit) or differentiate from other list tools like 'list_servers' beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., after creating a placement group), or comparisons to other list tools (e.g., 'list_servers' for different resources). Usage is implied by the name alone, with no explicit when/when-not statements.
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. 'List all server types' implies a read-only operation, but it doesn't specify whether this requires authentication, returns paginated results, includes metadata like pricing or specs, or has any rate limits. 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 a single, efficient sentence ('List all server types') that front-loads the core action and resource. There's zero waste or redundancy, making it highly concise 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 the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. However, without annotations or output schema, it lacks details on authentication needs, return format, or behavioral constraints. For a list operation in a context with many sibling tools, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, aligning with the schema. A baseline of 4 is applied since no parameters exist, and the description doesn't add unnecessary details.
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 ('server types'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_servers' or 'list_load_balancer_types', which would require specifying what distinguishes server types from those 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 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. With siblings like 'list_servers' and 'list_load_balancer_types', there's no indication of whether server types refer to hardware configurations, instance types, or other categories, leaving the agent to guess based on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions checking 'progress or status', hinting at read-only behavior, but doesn't explicitly state whether it's safe, idempotent, or has side effects. For a retrieval tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
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 with no wasted words. It front-loads the core purpose ('Get a single action by ID') and adds clarifying context in parentheses, making it 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?
For a simple retrieval tool with 1 parameter and no output schema, the description is minimally adequate. It covers the basic purpose and usage hint, but lacks details on authentication, error handling, or return format, which could be important 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?
The input schema has 1 parameter with 0% description coverage. The description adds value by specifying 'by ID' and implying it's a numeric ID, but doesn't detail format, constraints, or examples beyond the schema. With low schema coverage, it partially compensates but not fully.
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 a single action by ID' specifies the verb (get) and resource (action), with an example clarifying the scope. It distinguishes from sibling 'list_actions' by focusing on a single item, though it doesn't explicitly name the sibling.
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 'e.g. to check progress or status after create/delete', suggesting it's for follow-up operations. However, it doesn't explicitly state when to use this versus 'list_actions' or other alternatives, nor does it mention prerequisites like needing a valid action ID.
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 server must be off for assignment, which is a critical behavioral constraint, but lacks details on permissions, rate limits, error handling, or what happens on creation (e.g., is it immediately usable?). 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 front-loaded with the core action and key constraints in two concise sentences. Every word earns its place, with no redundancy or fluff, making it easy to parse quickly.
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 (6 parameters, mutation tool), lack of annotations, and no output schema, the description is incomplete. It misses details on return values, error cases, and full parameter meanings. For a tool that creates resources with multiple options, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%), with only 'datacenter' and 'assignee_id' having descriptions. The description adds value by explaining the mutual exclusivity of 'datacenter' and 'assignee_id,' but doesn't clarify other parameters like 'name,' 'type,' 'auto_delete,' or 'labels.' It partially compensates but leaves most parameters underspecified.
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 Primary IP') and specifies it's 'datacenter-scoped,' which distinguishes it from sibling tools like 'create_floating_ip' or 'assign_primary_ip.' However, it doesn't explicitly differentiate from 'update_primary_ip' in terms of creation vs. modification, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context on when to use certain parameters ('Provide datacenter OR assignee_id') and includes a prerequisite ('server must be off to assign'), which helps guide usage. It doesn't mention alternatives like 'assign_primary_ip' for reassignment or when to choose this over other IP-related tools, but the guidance is clear for its own context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'poll/wait for create/delete results,' which hints at asynchronous operations and potential delays, but it doesn't specify pagination behavior (implied by 'page' and 'per_page' parameters), rate limits, authentication requirements, or error handling. For a tool with 5 parameters and no 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 extremely concise with two clear parts: the core functionality and usage guidance. Every word earns its place, and it's front-loaded with the primary purpose. There's no redundant or verbose language.
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 (5 parameters, no annotations, no output schema), the description is incomplete. It lacks details on pagination behavior, return format, error conditions, and the semantics of unmentioned parameters. While the usage guidance is strong, it doesn't compensate for the missing behavioral and parameter context needed for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions 'id' and 'status' as filter options, ignoring 'sort', 'page', and 'per_page'. This leaves three parameters (60% of total) without any semantic explanation, failing to adequately supplement 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 verb ('List') and resource ('actions'), and specifies optional filtering capabilities ('filter by id, status'). It distinguishes itself from sibling tools like 'get_action' by indicating it returns multiple items with filtering options rather than retrieving a single specific action. However, it doesn't explicitly contrast with all list_* siblings beyond the action domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with 'use to poll/wait for create/delete results,' which clearly indicates when this tool should be employed. This distinguishes it from other list tools that might be used for general inventory purposes, and it suggests an alternative pattern (polling/waiting) rather than immediate retrieval.
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 it's a list operation, implying read-only behavior, but lacks details like pagination, rate limits, authentication needs, or return format. This is a significant gap 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 a single, efficient sentence that front-loads the purpose and includes usage context. There's no wasted text, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description is minimally adequate but lacks behavioral details (e.g., response format, pagination). It provides purpose and usage context but doesn't fully compensate for 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.
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 information is needed. The description doesn't add param details, which is appropriate, but it could mention any implicit filters (e.g., by region), keeping it from a 5.
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 load balancer types'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'list_load_balancers' or 'list_server_types', 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by mentioning 'for create_load_balancer load_balancer_type', indicating when to use this tool (to get types for creation). It doesn't specify when not to use it or name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the prerequisite (powered-off state) and hints at resource scaling behavior, but doesn't mention permission requirements, whether changes are reversible, rate limits, or what happens to existing data. The 'upgrade_disk' parameter description in the schema adds some behavioral context about downgrade limitations.
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 main purpose followed by a critical prerequisite. Every word serves a purpose with no wasted text 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?
For a mutation tool with no annotations and no output schema, the description provides basic purpose and a critical prerequisite. However, it lacks information about return values, error conditions, side effects beyond scaling, or how this differs from similar update operations among the many sibling tools.
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 67% (2 of 3 parameters have descriptions). The description doesn't add explicit parameter information, but the schema provides good coverage for 'server_type' and 'upgrade_disk'. The 'id' parameter lacks description in both schema and description, but overall parameter understanding is adequate given the context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('change the type of a server') and the effect ('scales resources'), which distinguishes it from generic update operations. However, it doesn't explicitly differentiate from sibling tools like 'update_server' or 'list_server_types' beyond the specific resource scaling focus.
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 a clear prerequisite ('Server must be powered off'), which is essential usage guidance. However, it doesn't specify when to use this versus alternatives like 'update_server' or explain if this is for scaling only versus other server modifications.
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 reveals the critical constraint about server power state, which is essential behavioral information. However, it doesn't mention other important aspects like required permissions, whether this is a destructive operation, what happens if the server already has a primary IP, or what the expected response format is.
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 communicates the core purpose and critical constraint upfront. There's no wasted verbiage, repetition, or unnecessary elaboration. Every word serves a clear purpose in helping the agent understand when and how to use this tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides the essential operational constraint but lacks other important context. It doesn't explain what happens to any existing primary IP, whether this operation is reversible, what permissions are required, or what the tool returns. Given the complexity of a server configuration change, more behavioral context 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 both parameters clearly documented in the schema. The description doesn't add any additional semantic information about the parameters beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even without parameter details 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 clearly states the specific action ('Assign a Primary IP') and target resource ('to a server'), with the additional constraint 'server must be powered off' that distinguishes it from similar tools like 'assign_floating_ip' or 'unassign_primary_ip'. It uses precise verbs and provides operational context beyond just the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite condition 'server must be powered off', which provides clear guidance on when this tool can be used. However, it doesn't mention when to use alternatives like 'assign_floating_ip' or 'unassign_primary_ip', nor does it specify any other exclusions or complementary 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 it's a list operation but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, or what happens if no IPs exist. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 purpose ('List all Primary IPs') followed by clarifying details. There's zero waste 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 low complexity (0 parameters, no output schema, no annotations), the description is complete enough for basic understanding. However, without annotations or output schema, it lacks details on return format, pagination, or error handling, which could be important for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage. The description doesn't need to explain parameters, and it appropriately doesn't mention any. A baseline of 4 is given since no parameters exist and the schema fully covers them.
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 Primary IPs') with specific scope ('static IPs bound to a datacenter, assignable to one server'). It distinguishes from sibling tools like 'get_primary_ip' (singular) and 'create_primary_ip' (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all primary IPs, but doesn't explicitly state when to use this vs. alternatives like 'get_primary_ip' (for a specific IP) or 'list_floating_ips' (for a different IP type). It provides clear context about what's listed but lacks 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.
Behavior4/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 effectively describes key behavioral traits: it's a destructive operation (implied by 'Delete'), it unassigns from servers if assigned, and it has a prerequisite (server must be off). However, it doesn't mention permissions, rate limits, or what happens to associated resources beyond unassignment.
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 and front-loaded, consisting of a single sentence that directly states the action and critical constraints. Every word earns its place with no wasted information, 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 complexity (destructive operation with prerequisites) and lack of annotations or output schema, the description is partially complete. It covers the main action and key constraints but misses details like parameter semantics, error conditions, and return values, which are important for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the single parameter 'id', and the tool description provides no information about what 'id' represents (e.g., Primary IP ID, format, or how to obtain it). This leaves the parameter undocumented, failing to compensate for the schema's lack of 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 the specific action ('Delete a Primary IP') and includes important behavioral details ('unassigns from server if assigned; server must be off'), which distinguishes it from sibling tools like 'unassign_primary_ip' that might only unassign without deletion. The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 by specifying prerequisites ('server must be off'), but it does not explicitly mention when NOT to use it or name alternatives like 'unassign_primary_ip' for different scenarios. This gives adequate guidance but lacks explicit exclusions or sibling 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates this is a destructive/mutating operation ('Unassign'), but doesn't specify what happens to the Primary IP after unassignment (does it become available for reassignment? is it deleted?), nor does it mention authentication requirements, error conditions, or rate limits. The power-off requirement is valuable context, but more behavioral details would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that communicates the core action, target, and critical constraint without any wasted words. It's front-loaded with the main purpose and follows with the essential condition, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description provides the essential power-off constraint but lacks details about parameter meaning, what happens after unassignment, possible side effects, or return values. Given the complexity of infrastructure management tools, more context would help the agent use this tool correctly and predict outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, providing only that 'id' is a required number. The description doesn't explain what 'id' refers to (Primary IP ID? Server ID?), what format it expects, or where to obtain it. This leaves a significant semantic gap that the agent must infer from context or trial-and-error.
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 ('Unassign a Primary IP') and the target resource ('from its server'), with the additional constraint 'server must be powered off' that distinguishes it from similar operations. It uses precise language that leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite condition 'server must be powered off' which tells the agent exactly when this tool can be used. This is a clear usage guideline that prevents the agent from attempting the operation when the server is running, which would likely fail.
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 annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates critical behavioral traits: the destructive nature ('all data destroyed') and the prerequisite condition ('must be detached'). This gives the agent essential context about irreversible data loss and operational constraints.
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 and front-loaded with all essential information in a single, efficient sentence. Every word earns its place by conveying critical constraints and consequences without any redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description does well to warn about data destruction and prerequisites. However, it lacks information about permissions needed, error conditions, or what happens after deletion. Given the high-stakes nature of this operation, more context would be beneficial.
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 0% description coverage, but the description doesn't provide any parameter-specific information beyond what's implied by context. It doesn't explain what 'id' represents or its format. Since schema coverage is low, the description should compensate more, but it only adds minimal context about prerequisites.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a volume'), making the purpose immediately apparent. It distinguishes from siblings like 'detach_volume' by specifying this is a permanent deletion operation rather than detachment.
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 explicit usage guidance with the prerequisite 'must be detached,' which helps the agent understand when this tool is applicable. However, it doesn't explicitly mention when NOT to use it or name specific alternatives, keeping it from a perfect score.
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:

[![hcloud-mcp MCP server](https://glama.ai/mcp/servers/Xodus-CO/hcloud-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Xodus-CO/hcloud-mcp)

Score Badge

Copy to your README.md:

[![hcloud-mcp MCP server](https://glama.ai/mcp/servers/Xodus-CO/hcloud-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Xodus-CO/hcloud-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Xodus-CO/hcloud-mcp'

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