Contabo (VPS) MCP Server

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, but the description adds no behavioral context beyond the basic action. It does not explain what 'destructive' entails (e.g., network disruption, instance downtime), permissions required, or side effects, leaving significant gaps despite annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single repetitive sentence ('Add instance to a Private Network - Add a specific instance to a Private Network'), which is under-specified rather than concise. It wastes space on redundancy without adding value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation tool with 4 parameters (0% schema coverage) and no output schema, the description is severely incomplete. It lacks details on behavior, parameters, outcomes, and error conditions, 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.

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 parameters. It does not explain what 'instanceId' or 'privateNetworkId' represent, their formats, or the purpose of 'x-request-id' and 'x-trace-id', failing 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description restates the title and name with minimal variation ('Add instance to a Private Network - Add a specific instance to a Private Network'), making it tautological. It does not specify what 'add' entails operationally or distinguish it from siblings like 'unassignInstancePrivateNetwork'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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, prerequisites, or exclusions. It does not reference sibling tools like 'unassignInstancePrivateNetwork' or 'createPrivateNetwork' for context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate this is a destructive, non-read-only operation, which aligns with the 'assign' action implying mutation. However, the description adds minimal behavioral context beyond this—it doesn't mention side effects, permission requirements, idempotency, or what happens if the VIP is already assigned. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, repetitive sentence that restates the title with minimal added value. It's front-loaded but under-specified, wasting space on redundancy ('Assign a VIP to an VPS/VDS/Bare Metal - Assign a VIP to a VPS/VDS/Bare Metal') instead of providing useful details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with 5 parameters, 0% schema coverage, and no output schema, the description is inadequate. It lacks critical context: what a VIP is, how assignment affects existing configurations, error conditions, or return values. Sibling tools like 'retrieveVip' suggest VIP management complexity that isn't addressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage and 5 parameters (4 required), the description provides no semantic information about parameters like 'ip', 'resourceId', 'resourceType', or the UUID-patterned 'x-request-id'. It mentions 'machine id' vaguely but doesn't clarify which parameter this corresponds to or how to use enums like 'instances' vs 'bare-metal'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action ('Assign a VIP') and target resources ('VPS/VDS/Bare Metal'), but it's repetitive and vague about what 'VIP' means (Virtual IP?). It doesn't clearly differentiate from sibling tools like 'unassignIp' or explain the specific relationship between VIP assignment and other networking operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'unassignIp' or networking-related siblings. The description mentions 'using the machine id' but doesn't explain prerequisites, dependencies, or typical scenarios for VIP assignment versus regular IP configuration.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, covering safety and mutation aspects. The description adds minimal context by specifying 'bulk' deletion, implying multiple records, but lacks details on permissions, rate limits, or irreversible effects. It doesn't contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief but repetitive ('Bulk delete DNS zone records - Delete multiple zone records from a DNS Zone'), wasting words on redundancy. It's front-loaded but could be more efficient by eliminating tautological phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with 4 parameters (3 required), 0% schema coverage, no output schema, and nested objects, the description is inadequate. It doesn't address parameter meanings, behavioral nuances beyond annotations, or expected outcomes, 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.

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 fails to explain parameters. It mentions 'zone records' but doesn't clarify 'zoneName', 'recordIds', or header parameters like 'x-request-id', leaving semantics unclear beyond what the schema minimally provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('bulk delete') and resource ('DNS zone records'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'deleteDnsZoneRecord' (singular delete) or 'deleteDnsZone' (entire zone deletion), 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.

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 'deleteDnsZoneRecord' for single deletions or 'deleteDnsZone' for zone removal. The description merely restates the purpose without contextual usage advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, which the description does not contradict. The description adds no behavioral details beyond these annotations, such as rate limits, authentication needs, or effects on related resources. However, since annotations cover the core safety profile, the description meets the lower bar without adding value, scoring above baseline but not excelling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is repetitive ('Cancel a specific domain - Cancel a specific domain'), wasting space without adding value. It lacks structure and front-loading of useful information, making it inefficient despite its brevity. Every sentence does not earn its place, as it merely echoes the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 4 parameters, nested objects, no output schema, and 0% schema coverage), the description is inadequate. It fails to explain parameter meanings, usage scenarios, or expected outcomes, leaving significant gaps for the agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning parameters like 'domain', 'x-request-id', and 'cancelDomainBody' are undocumented in the schema. The description provides no information about these parameters, failing to compensate for the schema gap. It does not explain what 'domain' refers to, the purpose of 'x-request-id', or the structure of 'cancelDomainBody'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description is tautological, merely restating the tool name and title ('Cancel a specific domain - Cancel a specific domain'). It specifies the verb ('Cancel') and resource ('domain'), but fails to differentiate from sibling tools like 'cancelInstance' or 'revokeCancelDomain', offering no additional clarity beyond what's already obvious from the name and title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, appropriate contexts, or exclusions, such as how it differs from 'revokeCancelDomain' or when cancellation is irreversible. This leaves the agent without necessary usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, covering safety. The description adds that cancellation applies to 'previously created instance' and 'at any time', offering some context. However, it doesn't detail irreversible effects, billing implications, or response behavior, leaving gaps despite annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the core action, avoiding redundancy. However, the second sentence ('Your are free...') is slightly awkward and could be more precise, but overall it's efficient with minimal waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with 4 parameters (0% schema coverage), no output schema, and complex siblings, the description is inadequate. It lacks parameter explanations, behavioral details (e.g., cancellation effects), and usage context, failing to compensate for missing structured data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 fails to explain parameters. It mentions 'by id' (hinting at instanceId) but ignores x-request-id, x-trace-id, and cancelInstanceBody (including cancelDate). No semantic details are provided beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('cancel') and target ('specific instance by id'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'deleteInstance' (which doesn't exist but similar destructive operations like 'deleteUser' do), missing explicit distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance ('at any time'), but lacks explicit when-to-use context, prerequisites (e.g., instance must be running), or alternatives (e.g., vs. shutdown or delete). No comparison to siblings like 'deleteInstance' or 'shutdown' is made.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, covering the safety profile. The description adds context about cancellation timing ('at the next possible date') and contract periods, which are useful behavioral details not in annotations. However, it doesn't disclose potential side effects like data loss or billing changes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is inefficiently repetitive ('Cancels the specified object storage at the next possible date' is stated twice) and lacks front-loading of key information. It wastes space without adding value, though it's not excessively long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with 4 parameters, 0% schema coverage, and no output schema, the description is inadequate. It misses critical details like parameter purposes, cancellation effects, error conditions, and return values. The context signals indicate high complexity, but the description doesn't address this.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 4 parameters. It only mentions 'object storage' vaguely, without explaining parameters like objectStorageId, x-request-id, or CancelObjectStorageBody.cancelDate. The description fails to add meaningful semantics beyond what the schema names imply.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool cancels object storage at the next possible date, which provides a basic verb+resource. However, it's vague about what 'cancels' entails (termination vs. suspension) and doesn't distinguish from sibling tools like cancelDomain or cancelInstance beyond the resource type. The repetition in the description adds no clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'Please be aware of your contract periods,' which implies a constraint but doesn't explicitly state when to use this tool versus alternatives like deleteObjectStorage (not in siblings) or updateObjectStorage. No guidance on prerequisites, timing, or comparisons with similar cancellation tools is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, which already signal this is a mutating, potentially irreversible operation. The description adds no behavioral details beyond this, such as what 'confirm' entails, whether it's reversible, or any side effects. However, it doesn't contradict the annotations, so it meets the lower bar with annotations present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is overly concise to the point of being unhelpful, consisting of a repetitive phrase that adds no value. While it's brief, it's not effectively structured or front-loaded with useful information, making it inefficient rather than concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a destructive domain operation with three parameters, no output schema, and 0% schema coverage), the description is severely inadequate. It lacks essential details about the tool's purpose, parameters, behavior, and output, failing to provide a complete picture for safe and correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 (domain, x-request-id, x-trace-id) are documented in the schema. The description provides no information about these parameters, failing to compensate for the schema's lack of documentation, which is critical for understanding required inputs like the UUID-patterned x-request-id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description is a tautology that merely restates the tool name and title ('Confirm transfer out for a domain - Confirm transfer out for a domain'), providing no additional clarity about what the tool actually does. It doesn't specify what 'confirm transfer out' entails operationally or how it differs from sibling tools like 'cancelDomain' or 'revokeDomainTransferOut'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no guidance on when to use this tool versus alternatives. There are no mentions of prerequisites, timing considerations, or distinctions from related tools like 'cancelDomain' or 'revokeDomainTransferOut', leaving the agent with no usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, which the description aligns with by implying a write operation ('create') and potential access restriction effects. However, it doesn't add significant behavioral context beyond annotations, such as rate limits, idempotency, or error conditions. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with some redundancy (repeats 'create a new assignment'), but it's front-loaded with the core purpose. It could be more concise by merging ideas, yet it avoids excessive verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 (0% schema coverage) and no output schema, the description is incomplete. It lacks details on parameter meanings, expected outcomes, error handling, and how it fits with sibling tools like 'deleteAssignment', making it insufficient for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 5 parameters. It only vaguely references 'specified resource' and 'specified tag', without explaining parameter roles (e.g., tagId, resourceType, resourceId), formats, or constraints like x-request-id's UUID pattern. This leaves key semantics undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('create') and resource ('tag assignment'), specifying it marks a resource with a tag for organizing or access restriction. It distinguishes from sibling tools like 'createTag' (creates tag itself) and 'deleteAssignment' (removes assignment), but doesn't explicitly contrast with 'retrieveAssignment' or 'retrieveAssignmentList' for read operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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. It mentions purposes (organizing or restricting access) but doesn't specify prerequisites (e.g., tag and resource must exist), exclusions, or direct comparisons to sibling tools like 'updateTag' for modifying tags or 'retrieveAssignment' for checking assignments.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by describing a creation/download process. The description adds valuable behavioral context beyond annotations: it notes format restrictions, potential download delays, status checking via GET, and download limits. This compensates well for the lack of annotations on these specific behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately concise but could be better structured. It front-loads the core action but includes somewhat verbose notes (e.g., 'depending on network speed resp. bandwidth'). Sentences are mostly relevant, but the flow could be improved for clarity, such as separating requirements from behavioral notes more distinctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (destructive creation with nested inputs) and lack of output schema, the description is partially complete. It covers key behaviors like format constraints and status checking, but omits details on error handling, response format, or interactions with sibling tools (e.g., how this relates to 'retrieveImage'). More context on outcomes and integration would enhance completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 only mentions the 'url' parameter explicitly and vaguely references 'limits' without detailing parameters like 'x-request-id' or 'createCustomImageBody' fields (e.g., 'name', 'osType'). The description fails to add meaningful semantics for most parameters, leaving significant gaps in understanding inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Provide a custom image' with the requirement to specify a downloadable URL. It distinguishes itself from sibling tools like 'retrieveImage' or 'deleteImage' by focusing on creation/upload. However, it doesn't explicitly contrast with 'createInstance' or 'createSnapshot' which might involve images, leaving some sibling differentiation incomplete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by specifying format requirements ('.iso' or '.qcow2') and mentioning that status can be checked via a GET request (likely referring to 'retrieveImage'). However, it doesn't explicitly state when to use this tool versus alternatives like 'createInstance' (which might use pre-existing images) or warn against misuse. Guidelines are present but not comprehensive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, which the description doesn't contradict (it describes a creation operation, not read-only). The description adds that this creates 'for a customer,' providing context about ownership that annotations don't cover. However, it lacks details on permissions needed, rate limits, or what 'destructive' means in this context (e.g., if it overwrites existing zones). With annotations covering safety basics, the description adds some value but could be more informative.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief (one sentence) and front-loaded with the core action, which is efficient. However, it's arguably too concise—it repeats the title ('Create DNS zone') and adds minimal value in the second clause. While not verbose, it under-specifies key details, making the conciseness feel more like omission than precision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive creation tool with 3 parameters (0% schema coverage), no output schema, and complex siblings, the description is inadequate. It doesn't explain parameters, return values, error conditions, or how it fits into the broader DNS management context. Annotations provide basic safety hints, but the description fails to address the tool's operational context, leaving significant gaps for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries full burden for explaining parameters. It mentions none of the 3 parameters (x-trace-id, x-request-id, createDnsZoneBody with zoneName). The description doesn't explain what 'zoneName' should be, what the request IDs are for, or any parameter constraints. This leaves critical input semantics 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action ('create') and resource ('DNS zone'), which is clear but minimal. It adds 'for a customer' which provides some context, but doesn't differentiate from sibling tools like 'createDnsZoneRecord' or explain what a DNS zone is versus a DNS record. The description is functional but lacks specificity about what distinguishes this creation operation from other DNS-related creations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a domain first), when not to use it, or how it relates to sibling tools like 'createDnsZoneRecord' or 'deleteDnsZone'. The phrase 'for a customer' hints at some context but doesn't provide actionable usage rules or comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, showing it's a mutation with destructive potential. The description adds no behavioral context beyond this, such as what gets destroyed, auth needs, rate limits, or side effects. It doesn't contradict annotations, but provides minimal value beyond them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief but under-specified and repetitive ('Create DNS zone record - Create resource record in a zone'). It wastes space with tautology instead of adding useful information, making it inefficient despite its short length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation tool with 4 parameters, 0% schema coverage, no output schema, and complex nested objects, the description is inadequate. It lacks details on behavior, parameters, usage, or expected outcomes, leaving significant gaps for an AI agent to understand and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning no parameters are documented in the schema. The description adds no parameter information—it doesn't explain 'zoneName', 'createDnsZoneRecordBody', or their sub-properties (e.g., 'type', 'ttl'). 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action ('Create DNS zone record') and resource ('resource record in a zone'), but it's repetitive and vague. It doesn't specify what a 'resource record' entails or differentiate from siblings like 'createDnsZone' or 'updateDnsZoneRecord', leaving the purpose unclear beyond 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.

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 DNS zone), exclusions, or compare to siblings like 'bulkDeleteDnsZoneRecords' or 'updateDnsZoneRecord', offering no usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate this is a destructive write operation (readOnlyHint: false, destructiveHint: true), but the description adds no behavioral context beyond what annotations already provide. It doesn't explain what 'destructive' means in this context, what permissions are required, whether the operation is idempotent, or what happens on success/failure. The description doesn't contradict annotations but fails to add meaningful behavioral information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

While technically concise, the description is under-specified rather than efficiently informative. The repetition 'Create specific handle - Create specific handle' wastes space without adding value. It lacks any meaningful structure or front-loading of important information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive write operation with 3 parameters (including a complex nested object), 0% schema description coverage, and no output schema, the description is completely inadequate. It provides no information about what the tool does, what parameters mean, what behavior to expect, or what results are returned. The description fails to compensate for the lack of structured documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage and 3 parameters (including a complex nested object), the description provides absolutely no information about parameters. It doesn't mention any of the required fields like 'handleType', 'firstName', 'lastName', 'email', 'gender', 'address', or 'phone', nor does it explain what a 'handle' represents or what data should be provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create specific handle - Create specific handle' is a tautology that merely restates the tool name and title. It provides no meaningful information about what the tool actually does, what a 'handle' represents in this context, or how it differs from sibling tools like 'createUser' or 'createRole'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, appropriate contexts, or how it relates to sibling tools like 'createUser', 'createRole', or 'listHandles'. There's no indication of when this tool should or shouldn't be used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, which correctly align with the 'create' action. The description adds the product table showing available instance types, which provides useful context beyond annotations about what can be created. However, it doesn't mention behavioral aspects like whether creation is immediate, asynchronous, or has rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is poorly structured with redundant phrasing ('Create a new instance - Create a new instance') and includes a massive HTML table that makes it verbose and difficult to parse. The core information is buried in markup rather than being front-loaded in clear prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive creation tool with complex nested parameters and no output schema, the description is incomplete. While the product table helps with productId selection, it doesn't address other critical parameters, expected return values, error conditions, or dependencies on other tools like 'createSecret' for SSH keys. The annotations provide basic safety context but more operational guidance is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage (parameters have no descriptions in the schema), the description carries the full burden. The product table provides crucial semantic information about valid productId values and their corresponding configurations, which compensates significantly for the schema gap. However, it doesn't explain other required parameters like 'period' or 'createInstanceBody'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Create a new instance for your account with the provided parameters', which is a tautology that essentially restates the tool name and title. It doesn't specify what type of instance (compute/VPS/VDS) or distinguish it from sibling tools like 'createObjectStorage' or 'createPrivateNetwork' that also create resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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. While the table shows product options, it doesn't explain prerequisites, when this should be used instead of other creation tools, or any constraints like account limits or billing implications.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, which the description aligns with by describing a creation/purchase action (non-read-only) and implying a financial commitment. The description adds valuable behavioral context beyond annotations: it notes the 'one per location' constraint and references a resize endpoint, which helps the agent understand limitations and related operations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main action and includes two additional sentences that provide important constraints and alternatives. It avoids unnecessary fluff, but the second sentence could be more streamlined (e.g., merging the constraint and alternative into one clearer statement).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (destructive creation with financial implications), no output schema, and 0% schema description coverage, the description is incomplete. It covers the core action and some behavioral constraints but lacks details on parameters, error conditions, or return values, leaving gaps for the agent to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 tool description does not mention any parameters (e.g., region, totalPurchasedSpaceTB) or their meanings, leaving them undocumented. However, with 3 parameters and no schema descriptions, the baseline is low, and the description fails to compensate, resulting in a minimal score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create / purchase a new object storage') and resource ('object storage in your account'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'createInstance' or 'createPrivateNetwork' beyond mentioning 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides some usage context by noting 'you can only buy one object storage per location' and mentions an alternative action ('increase the object storage space via POST...'), which implies when not to use this tool. However, it lacks explicit guidance on when to choose this over other creation tools (e.g., 'createInstance') or prerequisites like authentication needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, which already inform the agent that this is a write operation with potential destructive effects. The description does not contradict these annotations, as 'Create' aligns with a write operation. However, it adds no behavioral context beyond what annotations provide, such as what gets destroyed (e.g., resource limits, costs), authentication needs, or rate limits. With annotations covering the core safety profile, the description adds minimal value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is overly repetitive ('Create a new Private Network - Create a new Private Network in your account'), wasting space without adding value. It is front-loaded but with redundant phrasing. While brief, it lacks meaningful structure or efficiency, as the repetition does not serve any informative purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (a destructive write operation with 3 parameters and nested objects) and the absence of an output schema, the description is insufficient. It does not explain what the tool returns, potential errors, or the impact of the destructive hint. With 0% schema coverage and no output schema, the description should provide more context but fails to do so, leaving significant gaps in understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning none of the parameters (x-request-id, createPrivateNetworkBody with name, region, description) are documented in the schema. The description provides no information about these parameters, their purposes, or how they affect the creation process. It fails to compensate for the lack of schema documentation, leaving all parameters unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description is a tautology that essentially restates the name and title ('Create a new Private Network - Create a new Private Network in your account'). It does not provide any specific details about what a Private Network is or what resources it creates. While it mentions the resource (Private Network), it lacks a clear, distinct purpose statement that differentiates it from siblings like 'createInstance' or 'createObjectStorage'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., account permissions, available resources), typical use cases, or comparisons to sibling tools like 'patchPrivateNetwork' or 'deletePrivateNetwork'. The description offers 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, which the description doesn't contradict—it implies creation (a write operation) and doesn't claim safety. However, the description adds minimal behavioral context beyond annotations: it specifies 'Only IPv6 can be created', which is a constraint not covered by annotations. It lacks details on permissions, side effects, or response behavior, leaving gaps for a destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is repetitive and inefficient, starting with a redundant phrase ('Create a new PTR Record using ip address - Create a new PTR Record using ip address.') before adding the IPv6 constraint. It's not front-loaded with key information and wastes space on tautology rather than providing useful details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a destructive tool with 3 parameters, 0% schema coverage, no output schema, and complex nested objects, the description is inadequate. It doesn't explain what a PTR record is, the creation process, expected inputs/outputs, or error conditions. The IPv6 constraint is noted, but overall, it lacks the depth needed for effective tool use in this context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning no parameters have descriptions in the schema. The description provides no information about parameters beyond implying 'ip address' is used. It doesn't explain the three required parameters (x-request-id, createPtrRecordBody with ptr, ip, ttl), their purposes, formats, or relationships. 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description is tautological, repeating the title verbatim ('Create a new PTR Record using ip address') and adding only a minor constraint ('Only IPv6 can be created'). It states the verb (create) and resource (PTR Record) but lacks specificity about what a PTR record is or its DNS context. It doesn't distinguish from siblings like 'createDnsZoneRecord' or 'updatePtrRecord' beyond the IPv6 limitation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 description mentions 'Only IPv6 can be created', which hints at a constraint but doesn't clarify when to choose this over other DNS-related tools like 'createDnsZoneRecord' or 'updatePtrRecord'. There's no mention of prerequisites, dependencies, or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict. The description adds some behavioral context about where to find API endpoints and how resources work with tags, but doesn't elaborate on the destructive nature (what gets modified/permanently changed), authentication requirements, or error conditions. It provides partial value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is poorly structured with redundant phrasing ('Create a new role - Create a new role'). While it attempts to be concise, it under-specifies critical information. The sentences about API permissions and tag management are useful but feel tacked on without clear organization, making it inefficient rather than truly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive creation tool with 3 parameters, nested objects, no output schema, and 0% schema coverage, the description is inadequate. It misses explanations of key inputs, behavioral implications, expected outcomes, and error handling. The mention of external endpoints doesn't compensate for the lack of core tool context needed for proper invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries full burden for parameter explanation. It only mentions 'apiName' and 'resources' (tag ids) briefly, ignoring the 3 parameters and nested structure. Key parameters like 'name', 'admin', 'accessAllResources', and 'permissions' array aren't addressed, leaving significant gaps in understanding what inputs are needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool creates a new role, which is a specific verb+resource. However, it doesn't differentiate from sibling tools like 'updateRole' or 'deleteRole' beyond the basic action. The description repeats 'Create a new role' twice, adding redundancy rather than clarity about what distinguishes this creation operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 'updateRole' or 'deleteRole'. It mentions referring to another endpoint for API permissions and tag management for resources, but these are implementation details rather than usage context. There's no mention of prerequisites, constraints, or typical scenarios for role creation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, which the description doesn't contradict—it correctly implies a write operation ('Create'). However, the description adds minimal behavioral context beyond annotations: it mentions attributes (name, type, value) but doesn't disclose critical behaviors like authentication needs, rate limits, or what 'destructive' entails (e.g., overwriting existing secrets).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the main action, but it's somewhat redundant (repeats 'Create a new secret'). The second sentence adds parameter details efficiently, but overall structure could be improved by avoiding repetition and integrating information more cohesively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 parameters, destructive operation, no output schema), the description is insufficient. It lacks information on return values, error conditions, authentication requirements, and doesn't fully explain parameters or usage context. With annotations covering only read/write and destructiveness, more behavioral and operational details are needed for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 lists parameters (name, type, value) and explains type options (password or ssh), adding some semantics. However, it omits details on 'x-request-id' and 'x-trace-id' parameters, and doesn't clarify parameter constraints (e.g., value complexity rules from schema). The description partially addresses the coverage gap but leaves key parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create a new secret') and specifies the resource ('in your account'), which matches the tool name and title. It distinguishes itself from siblings like 'deleteSecret' and 'updateSecret' by focusing on creation. However, it doesn't explicitly differentiate from other creation tools (e.g., 'createInstance') 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.

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, appropriate contexts, or when not to use it. For example, it doesn't clarify if this should be used instead of 'updateSecret' for new secrets or how it relates to 'generateClientSecret'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, which the description doesn't contradict. However, it adds no behavioral context beyond this, such as explaining what 'destructive' entails (e.g., potential impact on instance performance), rate limits, or authentication needs, leaving gaps despite annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded, but it includes redundant phrasing ('Create a new instance snapshot - Create a new snapshot') that wastes space. It could be more efficient by eliminating repetition and focusing on unique aspects.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema and low schema coverage, the description is inadequate. It lacks details on return values, error conditions, or operational constraints, failing to provide a complete picture for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 it only vaguely mentions 'name and description attributes' without detailing parameters like 'instanceId', 'x-request-id', or nested object specifics. This adds minimal value beyond the schema's structural information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool creates a new snapshot for an instance with name and description attributes, which clarifies the verb and resource. However, it doesn't differentiate from sibling tools like 'rollbackSnapshot' or 'updateSnapshot', and the phrasing is somewhat redundant with the title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 'createCustomImage' or 'rollbackSnapshot'. The description lacks context about prerequisites, such as needing an existing instance, or exclusions, making it minimal in usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, which the description does not contradict—it implies a creation action. The description adds minimal behavioral context by mentioning attributes (name and optional color), but does not elaborate on permissions, rate limits, or what 'destructive' entails (e.g., if it overwrites existing tags). With annotations covering safety, it adds some value but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the main action, but it is somewhat redundant ('Create a new tag - Create a new tag'). It could be more efficient by avoiding repetition and better structuring the attribute details. However, it is not overly verbose and conveys the core idea in one sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (creation with destructive hint, 3 parameters, no output schema), the description is inadequate. It lacks details on behavioral traits (e.g., what destruction means), parameter meanings beyond name/color, and usage context. With annotations providing some safety info but no output schema, the description should do more to explain the tool's operation and expected outcomes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 mentions 'attribute name and optional attribute color', which partially covers two parameters (name and color) but omits the third parameter (description) and does not explain the required 'x-request-id' or optional 'x-trace-id'. It fails to compensate for the low coverage, leaving key parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create a new tag') and specifies the resource ('in your account'), which is a specific verb+resource combination. However, it does not explicitly differentiate from sibling tools like 'updateTag' or 'deleteTag', though the action is distinct. The description is not tautological as it adds details beyond the name/title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, such as 'updateTag' for modifying existing tags or 'deleteTag' for removal. It lacks context about prerequisites, like whether the tag name must be unique or if there are limits on tag creation, and does not mention any exclusions or specific scenarios for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond the annotations. While annotations indicate this is a destructive write operation (readOnlyHint=false, destructiveHint=true), the description explains the security constraint about password specification and that users must set their own secrets. This provides important operational context that the annotations alone don't convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with two sentences that each serve a clear purpose: the first states the action and key attributes, the second explains the security constraint. It's front-loaded with the core functionality and wastes no words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive creation tool with no output schema and poor schema documentation (0% coverage), the description does a reasonably complete job. It explains the core functionality, lists key attributes, and provides important security context. However, it could be more complete by explaining the response format or error conditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the schema provides no parameter descriptions. The description lists several attributes (name, email, enabled, totp, admin, accessAllResources, roles) but doesn't fully explain all parameters from the input schema. It adds some semantic value but doesn't completely compensate for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Create a new user') and distinguishes it from siblings by specifying the required attributes. It explicitly mentions what cannot be done ('You can't specify any password / secrets for the user'), which helps differentiate it from potential password-setting tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool (to create a new user with specific attributes) and includes an important security constraint about not specifying passwords. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by describing a deletion action. The description adds valuable context beyond annotations: it specifies that the tag is removed from a resource and warns about potential access restriction impacts. This helps the agent understand side effects not captured in structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. The first sentence restates the purpose, and the second adds critical behavioral context about access restrictions. It's front-loaded and efficiently structured, though slightly repetitive with the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema and 0% parameter coverage, the description is moderately complete. It covers the core action and a key side effect, but lacks parameter explanations, success/failure conditions, or error handling. Annotations help by marking it as destructive, but more behavioral detail would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The tool description provides no information about parameters like tagId, resourceType, or resourceId, failing to compensate for the lack of schema documentation. This leaves the agent guessing about parameter meanings and formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Delete existing tag assignment') and specifies the resource affected ('tag assignment will be removed from the specified resource'), which matches the tool name and title. However, it doesn't explicitly differentiate from sibling tools like 'deleteTag' (which likely deletes the tag itself rather than its assignment) or 'createAssignment' (its counterpart).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 mentions a consequence ('If this tag is being used for access restrictions...'), but this is behavioral information, not usage guidance. There's no mention of prerequisites, when to choose this over other deletion tools, or contextual triggers.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate this is a destructive, non-read-only operation, which the description aligns with by using 'Delete'. The description doesn't add behavioral details beyond this (e.g., irreversibility, confirmation steps, or error conditions), but since annotations cover the safety profile, the bar is lower. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief but inefficient—the second sentence repeats the first without adding value. It's front-loaded with the core action but wastes space on redundancy. A single, clearer sentence would improve conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with 3 parameters (0% schema coverage) and no output schema, the description is inadequate. It lacks details on parameter usage, expected outcomes, error handling, or dependencies (e.g., relation to DNS records). Annotations help but don't fill these gaps, making the tool hard to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description mentions 'zone name' but doesn't explain what 'zoneName' is, its format, or the purpose of 'x-request-id' and 'x-trace-id'. It fails to compensate for the lack of schema documentation, leaving key parameters unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action ('Delete a DNS zone') and resource ('DNS zone'), which is clear but basic. It doesn't distinguish this tool from its sibling 'bulkDeleteDnsZoneRecords' or explain what a DNS zone deletion entails versus other DNS operations. The second sentence is redundant, adding no new information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 'bulkDeleteDnsZoneRecords' or 'deleteDnsZoneRecord'. There's no mention of prerequisites (e.g., needing to delete records first) or consequences (e.g., impact on domains). The description offers only the basic action without context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description doesn't add behavioral context beyond what annotations provide. Annotations already indicate this is destructive (destructiveHint: true) and not read-only (readOnlyHint: false). The description doesn't mention permissions needed, irreversible consequences, rate limits, or what happens to DNS resolution after deletion.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely brief (essentially one repeated phrase), which could be seen as concise. However, it's under-specified rather than efficiently informative - it wastes space repeating itself ('Delete a DNS zone record - Delete a DNZ Zone's record') instead of providing useful content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive operation with 4 parameters (0% documented in schema) and no output schema, the description is severely inadequate. It doesn't explain what gets deleted, how to identify records, what happens after deletion, error conditions, or return values. The annotations help but don't compensate for the missing operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage and 4 parameters (3 required), the description provides zero information about what parameters mean or how to use them. It doesn't explain what 'recordId', 'zoneName', 'x-request-id', or 'x-trace-id' represent or how to obtain them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description is tautological - it essentially restates the tool name/title ('Delete a DNS zone record') without adding meaningful specificity. While it mentions the resource (DNS zone record), it doesn't distinguish this from sibling tools like 'bulkDeleteDnsZoneRecords' or 'deleteDnsZone', nor does it specify what type of DNS record is affected.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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. There's no mention of prerequisites (like needing the record ID), when not to use it, or how it differs from related tools like 'bulkDeleteDnsZoneRecords' or 'updateDnsZoneRecord'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, already signaling a destructive write operation. The description adds context by confirming deletion is allowed 'at any time', which hints at no time-based restrictions, but doesn't detail authentication needs, rate limits, or irreversible effects beyond what annotations imply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the core action, but includes a redundant phrase ('Your are free to delete a previously uploaded custom images at any time') that could be trimmed without losing meaning. Overall, it's efficient but not maximally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with 3 parameters (0% schema coverage), no output schema, and annotations only covering safety, the description is insufficient. It lacks details on parameter usage, error conditions, or what happens post-deletion (e.g., confirmation, side effects), making it incomplete for safe agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 'by its id', which aligns with the 'imageId' parameter, but doesn't explain 'x-request-id' or 'x-trace-id' (e.g., their purposes or formats). This leaves two parameters inadequately covered.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 ('uploaded custom image'), with the title specifying 'by its id'. It distinguishes from siblings like 'deleteSnapshot' or 'deleteDnsZone' by focusing on images, but doesn't explicitly differentiate from 'updateImage' or 'retrieveImage' 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance with 'Your are free to delete a previously uploaded custom images at any time', which implies no restrictions but doesn't specify when to use this over alternatives like 'updateImage' or prerequisites. No explicit when-not-to-use or sibling tool comparisons are included.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=false and destructiveHint=true, indicating it's a destructive mutation. The description adds valuable context beyond annotations by specifying that deletion 'automatically unassign all instances from it', which clarifies side-effects not captured in annotations. No contradictions with annotations exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and efficiently adds critical behavioral detail in a single sentence. No redundant information is present, though it could be slightly more structured for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema and 0% schema description coverage, the description adequately covers the main action and a key side-effect. However, it lacks details on error conditions, response format, or implications of the x-* parameters, leaving gaps in full contextual understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so parameters are undocumented in the schema. The description mentions 'by id' which corresponds to 'privateNetworkId', but doesn't explain the other two parameters (x-request-id and x-trace-id) or their purposes. It adds minimal semantic value beyond what's inferable from parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Delete'), the resource ('existing Private Network/Virtual Private Cloud'), and the identifier ('by id'). It distinguishes from siblings like 'deleteDnsZone' or 'deleteSnapshot' by specifying the exact resource type, and from 'unassignInstancePrivateNetwork' by indicating it's a full deletion with automatic unassignment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing to delete a private network and unassign instances, but doesn't explicitly state when to use this versus alternatives like 'patchPrivateNetwork' for modifications or 'unassignInstancePrivateNetwork' for partial removal. No prerequisites or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, which already tell the agent this is a destructive write operation. The description adds that it's for deleting PTR records and specifies 'Only IPv6 can be deleted', which provides useful behavioral context beyond annotations. However, it doesn't mention side effects, permissions needed, or error conditions, leaving gaps in transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is poorly structured and repetitive: 'Delete a PTR Record using ip address - Delete a PTR Record using ip address. Only IPv6 can be deleted'. The first part is duplicated, wasting space. While short, it's not front-loaded with critical info and includes redundancy instead of adding value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with 3 parameters (0% schema coverage) and no output schema, the description is inadequate. It mentions the IPv6 constraint but doesn't explain parameters, error handling, or what happens on success. Annotations cover safety profile, but the description doesn't add enough context to make this tool fully understandable to an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 (ipAddress, x-request-id, x-trace-id) are documented in the schema. The description only mentions 'ip address' generically, without explaining what format it expects, what the x-* parameters are for, or any constraints. This fails to compensate for the complete lack of schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool deletes a PTR record using an IP address, which is a clear verb+resource combination. However, it repeats the same phrase twice ('Delete a PTR Record using ip address' appears verbatim twice), making it somewhat redundant. It distinguishes from siblings like 'createPtrRecord' and 'updatePtrRecord' by specifying deletion, but doesn't clearly differentiate from other deletion tools like 'deleteDnsZoneRecord' 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.

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 mentions 'Only IPv6 can be deleted', which is a constraint but not usage guidance. There's no mention of prerequisites, when to choose this over other deletion tools, or what happens after deletion. Siblings include 'deleteDnsZoneRecord' and 'unassignIp', but no comparison is made.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, covering safety. The description adds valuable behavioral context: the prerequisite condition (role must not be assigned) and the consequence (deletion fails if assigned). This goes beyond annotations by explaining failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste: the first states the purpose, the second provides critical usage constraint. It's front-loaded and efficiently structured, with every word earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema and 0% schema coverage, the description is reasonably complete. It covers purpose, key constraint, and alternative action. However, it lacks details on response format or error handling, which could be helpful given the complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 mentions 'by id', implying the roleId parameter, but doesn't explain x-request-id or x-trace-id. It adds minimal semantics, compensating slightly but not fully for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 resource ('existing role by id'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'deleteUser' or 'deleteAssignment' beyond the resource type, missing explicit distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context on when NOT to use this tool ('You can't delete a role if it is still assigned to a user') and suggests an alternative action ('remove the role from the users'). This helps the agent avoid errors, though it doesn't explicitly name sibling alternatives like 'updateRole' for reassignment.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this is a destructive write operation. The description adds some context by confirming it's a deletion action and specifying 'from your account,' but doesn't provide additional behavioral details like whether deletion is permanent/reversible, authentication requirements, or rate limits. With annotations covering the safety profile, this earns a baseline 3.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately brief with two concise sentences that get straight to the point. However, the second sentence ('You can remove a specific secret from your account') is somewhat redundant with the first, slightly reducing efficiency. Overall, it's well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive operation with 3 parameters (2 required), 0% schema description coverage, and no output schema, the description is insufficient. It doesn't explain what happens after deletion (success response, error conditions), doesn't clarify the purpose of the x-* headers, and provides minimal behavioral context beyond what annotations already indicate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 have descriptions in the schema. The description only mentions 'by id' which corresponds to the secretId parameter, leaving x-request-id and x-trace-id completely unexplained. For a tool with 3 parameters and 0% schema coverage, the description should do more to explain parameter purposes and relationships.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 ('existing secret by id'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from other deletion tools in the sibling list (like deleteAssignment, deleteDnsZone, deleteUser, etc.), missing an opportunity to specify what makes secret deletion unique.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance - it only states you can remove a specific secret from your account. It doesn't indicate when to use this versus alternatives (like updateSecret for modification or createSecret for creation), nor does it mention prerequisites (e.g., needing the secret ID from retrieveSecretList). No explicit when/when-not guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, which already signal this is a destructive write operation. The description adds minimal behavioral context by repeating 'delete', but doesn't disclose additional traits like whether deletion is irreversible, requires specific permissions, affects associated resources, or has side effects. It doesn't contradict annotations, but adds little value beyond them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise but inefficiently structured—it repeats 'Delete existing snapshot by id' with slight variation, wasting words without adding clarity. It's front-loaded with the core action but fails to use its brevity to convey useful information. The repetition suggests under-specification rather than purposeful conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's destructive nature (per annotations), 4 parameters with 0% schema coverage, and no output schema, the description is highly incomplete. It doesn't explain what a snapshot is, the implications of deletion, parameter meanings, or expected outcomes. For a mutation tool with significant complexity, this description leaves critical gaps for an agent to operate safely and correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description provides no information about parameters—it doesn't explain what instanceId or snapshotId refer to, or the purpose of x-request-id and x-trace-id. For a tool with 4 parameters (3 required), this leaves the agent with no semantic guidance beyond raw schema types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description is tautological, essentially restating the name/title ('Delete existing snapshot by id') with minor repetition. It doesn't specify what a 'snapshot' is in this context or what resource it operates on, beyond what's already implied by the name. While it includes the verb 'delete' and resource 'snapshot', it lacks specificity and doesn't distinguish this tool from sibling deletion tools like deleteImage or deleteDnsZone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 snapshot), exclusions, or related tools like retrieveSnapshot or rollbackSnapshot from the sibling list. There's no context about when deletion is appropriate or what happens after deletion.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already indicate this is a destructive, non-read-only operation, which the description aligns with by using 'Delete.' The description adds valuable behavioral context beyond annotations by specifying the precondition for successful deletion (tag must not be assigned to any resource) and suggesting a prerequisite action (check assignments). This helps the agent understand failure conditions and proper workflow.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise and front-loaded with the core purpose. Both sentences earn their place: the first states what the tool does, and the second provides crucial behavioral guidance. There's zero wasted verbiage or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema and poor parameter documentation, the description does an adequate job covering the core operation and important behavioral constraints. However, it doesn't address what happens after deletion (success response, error formats), and leaves two parameters completely unexplained, which creates gaps for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for 3 parameters, the description carries full burden for parameter documentation. It only mentions 'tagId' (one of the three parameters) without explaining its format or purpose. The other two parameters (x-request-id and x-trace-id) are completely undocumented in both schema and description, leaving significant gaps in understanding required inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 ('existing tag by id'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other delete operations in the sibling list (like deleteAssignment, deleteDnsZone, etc.) beyond specifying it's for tags.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage guidance by stating 'Your tag can be deleted if it is not assigned to any resource on your account' and advising to 'Check tag assignments before deleting tag.' This gives important context about when the operation will succeed versus fail. However, it doesn't explicitly mention alternatives or when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond annotations by explaining the consequence of deletion ('he will not be able to access any endpoints or resources any longer'), which clarifies the permanence and impact of the operation. While annotations already indicate destructiveHint=true, the description provides specific user impact details that annotations don't cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly concise with two sentences that each serve distinct purposes: the first states the core functionality, the second provides crucial usage guidance. There's no wasted language or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive operation with no output schema, the description provides essential context about the permanent consequences and alternative approaches. While it doesn't detail return values or error conditions, it addresses the most critical aspects for safe tool invocation given the destructive nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for 3 parameters, the description mentions 'by id' which hints at the userId parameter but doesn't explain x-request-id or x-trace-id. It provides minimal semantic value beyond what's implied by the tool name, meeting the baseline expectation when schema coverage is low.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Delete'), target resource ('existing user'), and method ('by id'), distinguishing it from sibling tools like 'updateUser' or 'createUser'. It precisely defines what the tool does without being tautological.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides when-not-to-use guidance by stating 'In order to temporarily disable a user please update its `enabled` attribute', offering a clear alternative to this permanent deletion tool. This helps the agent choose between delete and update operations appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, which already inform the agent that this is a mutation with destructive effects. The description does not add any behavioral context beyond this—it doesn't explain what 'destructive' means here (e.g., invalidates previous secrets, requires re-authentication), nor does it mention rate limits, authentication needs, or side effects. However, it does not contradict the annotations, so it meets the lower bar with annotations present but adds minimal value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise but under-specified—it consists of a redundant phrase that doesn't add value. While it avoids verbosity, it wastes its limited space on repetition rather than informative content. It is not front-loaded with useful information, making it inefficient despite its brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (a destructive mutation with 2 parameters), lack of output schema, and minimal annotations, the description is incomplete. It does not explain what a client secret is, what the output includes (e.g., the new secret value), error conditions, or security implications. For a tool with destructive hints and no output schema, more context is needed to guide proper use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 2 parameters (x-trace-id and x-request-id) with 0% description coverage, meaning the schema provides no semantic information about them. The description does not mention any parameters, their purposes (e.g., for tracing or request identification), or how they affect the operation. With low schema coverage, the description fails to compensate, leaving parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description is tautological, essentially restating the tool name and title ('Generate new client secret - Generate and get new client secret'). It does not provide any additional specificity about what a 'client secret' is, what system it belongs to, or how it differs from sibling tools like 'createSecret' or 'regenerateObjectStorageCredentials'. The purpose is implied but not clearly articulated beyond repetition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., existing client), exclusions, or compare it to sibling tools like 'createSecret' (which might create a secret initially) or 'regenerateObjectStorageCredentials' (which handles a different resource). The description offers zero contextual usage information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, suggesting this is a write operation with destructive effects. The description doesn't explain what 'destructive' means in this context (e.g., does it invalidate previous auth codes, trigger security changes, or have side effects?). It adds no behavioral context beyond the annotations, which is problematic since annotations alone don't clarify the nature of the destruction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

While technically concise (one repetitive sentence), the description is under-specified rather than efficiently informative. It wastes space repeating itself ('Get auth code for a domain - Get auth code for a domain by id') instead of providing meaningful content. The structure doesn't front-load useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a destructive operation (per annotations) with 3 undocumented parameters and no output schema. The description fails to explain what an auth code is, why it's needed, what the destructive effect entails, what the parameters mean, or what the tool returns. Given the complexity and lack of structured documentation, the description is completely inadequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 have descriptions in the schema. The tool description provides zero information about what 'domain', 'x-request-id', or 'x-trace-id' parameters represent, their expected formats, or their purposes. This leaves all parameters completely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description is a tautology that essentially repeats the tool name and title ('Get auth code for a domain - Get auth code for a domain by id'). It specifies the verb (get) and resource (auth code for a domain), but provides no additional clarity about what an 'auth code' is used for or what domain context this applies to. It doesn't distinguish from siblings like 'retrieveDomain' or 'listDomains'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is absolutely no guidance on when to use this tool versus alternatives. The description doesn't mention prerequisites, when this operation is needed, or what distinguishes it from other domain-related tools like 'retrieveDomain', 'orderDomain', or 'cancelDomain'. The agent receives no contextual usage information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context about S3 compatibility and tool usage, but does not disclose behavioral traits like authentication requirements, rate limits, or what data is returned. It does not contradict annotations, as 'Get' aligns with read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise but inefficiently structured: it repeats the same phrase and includes a dash that adds little value. It is front-loaded with the purpose, but the second part is redundant. It could be more streamlined without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters with 0% schema coverage, no output schema, and annotations only covering safety, the description is incomplete. It lacks details on parameter usage, return values (e.g., credential format), error conditions, or operational context. For a credential retrieval tool, this leaves significant gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so parameters are undocumented in the schema. The description does not explain any parameters (e.g., userId, objectStorageId, credentialId), their meanings, or relationships. It fails to compensate for the schema gap, leaving all 5 parameters without semantic clarification.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's purpose ('Get S3 compatible object storage credentials'), which is clear but vague. It repeats the same phrase twice without specifying what credentials are obtained (e.g., access keys, temporary tokens) or their scope. It distinguishes from siblings like 'createObjectStorage' or 'regenerateObjectStorageCredentials' by being a retrieval operation, but lacks specificity about the resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance: it mentions accessing via 'S3 compatible tools like `aws` cli', implying usage for integration. However, it lacks explicit when-to-use rules, prerequisites (e.g., needing existing credentials), or alternatives (e.g., vs. 'listObjectStorageCredentials' for listing vs. getting details). No exclusions or comparisons are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds minimal behavioral context by mentioning filtering, but it doesn't disclose pagination behavior (implied by 'page' and 'size' parameters), rate limits, or authentication needs. With annotations covering safety, it adds some value but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two short phrases, but it's slightly repetitive ('List all domains - List and filter all your domains'). It front-loads the core action but could be more structured by separating listing from filtering details. Overall, it's efficient with minimal waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (8 parameters, 0% schema coverage, no output schema), the description is inadequate. It doesn't explain the filtering parameters, pagination behavior, or return format, leaving significant gaps. With annotations providing only safety hints, more context is needed for effective tool use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so parameters like 'sld', 'tld', 'status', 'orderBy', etc., are undocumented in the schema. The description only vaguely mentions 'filter all your domains', which doesn't explain what parameters are available or their purposes. It fails to compensate for the low schema coverage, leaving most parameters semantically unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'List all domains - List and filter all your domains', which clarifies the verb (list) and resource (domains). However, it's vague about the filtering capability ('filter all your domains') without specifying what filters are available, and it doesn't distinguish this tool from potential siblings like 'retrieveDomain' or 'retrieveDomainsAuditsList' in the provided list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 mentions filtering but doesn't specify scenarios or prerequisites, and it doesn't reference sibling tools like 'retrieveDomain' for single-domain retrieval or 'retrieveDomainsAuditsList' for audit logs, leaving the agent without context for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate read-only and non-destructive, which the description doesn't contradict. However, it adds minimal behavioral context beyond listing and filtering—no details on pagination, rate limits, or authentication needs. With annotations covering safety, this is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded, with no wasted words. However, it's slightly repetitive ('List all handles - List and filter all your handles'), which reduces efficiency but maintains clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 12 parameters with 0% schema coverage, no output schema, and annotations only covering safety, the description is incomplete. It doesn't explain return values, filtering logic, or handle types, leaving significant gaps for a complex list/filter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 filtering but doesn't explain any of the 12 parameters (e.g., 'name', 'page', 'handleType'). This leaves most semantics undocumented, failing to add meaningful value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool lists and filters handles, which is a clear purpose. However, it doesn't specify what 'handles' are (e.g., user accounts, identifiers) or differentiate from sibling tools like 'retrieveHandle' (singular) or 'createHandle', making it somewhat vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 'retrieveHandle' (for a single handle) or 'createHandle'. The description only repeats the action without context or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true and destructiveHint=false, covering safety. The description adds context about S3 compatibility and usage with tools like 'aws' cli, which is useful but doesn't detail behavioral traits like pagination (implied by 'page' and 'size' parameters), rate limits, or authentication requirements beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with some repetition ('Get list' appears twice). It's front-loaded but includes redundant phrasing; the second sentence adds value by explaining compatibility, but could be more streamlined.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 9 parameters (0% schema coverage), no output schema, and annotations only covering read/destructive hints, the description is insufficient. It lacks details on parameter meanings, return values, pagination behavior, and error handling, making it incomplete for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 'for user' and 'S3 compatible', which loosely relates to 'userId' and 'objectStorageId', but doesn't explain the purpose of any parameters (e.g., 'page', 'size', 'orderBy', 'regionName', 'displayName', 'x-request-id', 'x-trace-id'), leaving them undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get list') and resource ('S3 compatible object storage credentials for user'), making the purpose specific. It distinguishes from some siblings like 'getObjectStorageCredentials' (singular) by emphasizing 'list', but doesn't explicitly contrast with other list/retrieve tools for object storage or credentials.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 'getObjectStorageCredentials' (singular) or other list tools. The description mentions accessing via S3 compatible tools like 'aws' cli, which hints at a use case but doesn't provide clear when/when-not instructions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate this is a destructive (destructiveHint: true) and non-read-only (readOnlyHint: false) operation, which the description doesn't explicitly state. However, the description doesn't contradict these annotations - 'create or transfer' implies mutation. The description adds no behavioral context beyond what annotations provide (no rate limits, auth requirements, or specific destructive consequences mentioned).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

While technically concise, the description is under-specified rather than efficiently informative. The repetition 'Create or transfer a domain - Create or transfer a domain' wastes space without adding value. It's not front-loaded with useful information - it's essentially empty content masquerading as conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation tool with 3 parameters (including complex nested objects), 0% schema coverage, no output schema, and no annotations beyond basic hints, this description is completely inadequate. It provides no information about what the tool actually does, when to use it, what parameters mean, or what to expect as output. The description fails to provide any meaningful context for the agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for the 3 parameters, the description carries full burden for explaining parameter meaning but provides zero information about any parameters. It doesn't mention 'x-request-id', 'orderDomainBody', or any of their sub-properties like 'domain', 'handles', 'authCode', etc. The description fails completely 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create or transfer a domain - Create or transfer a domain' is essentially a tautology that restates the title with minimal variation. It doesn't provide any meaningful elaboration on what the tool actually does beyond the obvious from the name/title. No specific details about the domain creation or transfer process are mentioned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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. It doesn't mention any prerequisites, conditions for choosing between creation and transfer, or how it differs from sibling tools like 'cancelDomain', 'confirmDomainTransferOut', or 'validateDomainAvailability'. The agent receives zero usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, which the description doesn't contradict. However, it adds minimal context beyond this, failing to elaborate on what 'destructive' entails (e.g., irreversible changes) or other behavioral traits like authentication needs or rate limits. With annotations covering safety, the description provides some value 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is overly concise to the point of under-specification, consisting of a repetitive phrase that doesn't front-load useful information. It wastes space on redundancy ('Update specific instance' repeated) instead of providing actionable details, making it inefficient rather than appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation tool with 4 parameters, 0% schema coverage, no output schema, and rich sibling tools, the description is incomplete. It lacks details on what 'instance' refers to, the scope of updates, error conditions, or return values, leaving significant gaps for an AI agent to infer correct usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 mentions 'instanceId' without explaining its role or other parameters like 'x-request-id' and 'patchInstanceBody'. It doesn't clarify what fields can be updated in 'patchInstanceBody' (e.g., 'displayName'), leaving parameters largely undocumented and adding little meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Update specific instance - Update specific instance by instanceId' is tautological, essentially restating the name and title without adding meaningful detail. It mentions the 'instanceId' parameter but doesn't specify what an 'instance' is or what aspects can be updated, making the purpose vague despite the verb 'Update'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 'updateInstance' or other sibling tools. The description lacks context about prerequisites, such as needing an existing instance, and doesn't mention any exclusions or specific scenarios for its use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, which the description does not contradict (it implies mutation with 'Update'). However, the description adds no behavioral context beyond this—it does not explain what 'destructive' entails (e.g., irreversible changes, impact on connected instances), rate limits, authentication needs, or error handling. With annotations covering safety, it meets a baseline but lacks enrichment.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded, consisting of a single sentence that states the core action. However, it is repetitive ('Update a Private Network by id' appears twice), which slightly reduces efficiency. Overall, it avoids unnecessary verbosity but under-specifies.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (4 parameters, nested objects, destructive hint) and lack of output schema, the description is incomplete. It does not explain what the tool updates, the required parameters, potential side effects, or return values. With annotations providing some safety context but no parameter or output details, it falls short of being adequately informative.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description provides no information about parameters—it does not mention 'x-request-id', 'privateNetworkId', or 'patchPrivateNetworkBody', nor does it explain what fields can be updated (e.g., name, description). This fails to compensate for the schema gap, leaving parameters largely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description is tautological, essentially restating the title ('Update a Private Network by id') with minimal variation. It does not specify what aspects can be updated (e.g., name, description) or how it differs from sibling tools like 'updatePrivateNetwork' (if present, though not listed) or 'createPrivateNetwork'. The verb 'Update' is clear, but the resource scope and differentiation are lacking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an existing private network ID), exclusions, or comparisons to similar tools like 'updatePrivateNetwork' (not in siblings) or 'patchInstance'. The description provides no context for usage decisions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate this is a destructive (destructiveHint: true) and non-read-only (readOnlyHint: false) operation, which the description doesn't explicitly state. However, 'regenerates' implies mutation and potential disruption, adding some context. No additional behavioral details like rate limits or auth needs are provided, but annotations cover the core safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is repetitive, stating the same phrase twice with minor variations ('the S3' vs 'the a specific S3'), which adds no value. It's front-loaded but wastes space on redundancy, reducing clarity and efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with 5 parameters, 0% schema coverage, and no output schema, the description is inadequate. It lacks parameter explanations, behavioral details beyond annotations, and output information, making it incomplete for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage and 5 parameters (4 required), the description fails to explain any parameters, such as 'userId', 'objectStorageId', or 'credentialId'. This leaves critical input semantics undocumented, significantly hindering tool invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('regenerates') and resource ('secret key of specified user for the S3 compatible object storages'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'getObjectStorageCredentials' or 'createSecret', which handle related but different operations, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, such as 'getObjectStorageCredentials' for viewing credentials or 'createSecret' for initial creation. It lacks context on prerequisites, exclusions, or typical scenarios, leaving usage unclear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=false and destructiveHint=true, indicating this is a destructive mutation. The description adds context about what gets reconfigured (image, ssh keys, password, cloud-init), which aligns with the destructive nature. However, it doesn't mention potential downtime, data loss, or authentication requirements beyond what annotations imply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the core action. The second sentence efficiently lists optional configurations. However, the first part repeats the title ('Reinstall specific instance'), which is slightly redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with 4 parameters, 0% schema coverage, and no output schema, the description is inadequate. It doesn't explain the return value, error conditions, or important behavioral details like whether the instance must be stopped first. The annotations help but don't replace needed operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description carries full burden for parameter meaning. It mentions 'new image', 'ssh keys', 'root password', and 'cloud-init', which correspond to some parameters, but doesn't cover all 4 parameters (e.g., x-request-id, x-trace-id) or explain the structure of reinstallInstanceBody. The description adds some value but doesn't fully compensate for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('reinstall') and resource ('specific instance'), and specifies what can be configured during reinstallation (new image, ssh keys, root password, cloud-init). However, it doesn't explicitly differentiate from siblings like 'createInstance' or 'patchInstance' beyond the reinstall focus.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'createInstance' (for new instances) or 'patchInstance' (for updates without reinstallation). The description only states what the tool does, not when it's appropriate or what prerequisites might exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, which already convey that this is a destructive write operation. The description doesn't add behavioral details beyond this, such as irreversible effects, authentication needs, or error conditions. However, it doesn't contradict the annotations, so it meets the lower bar with annotations present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is overly concise to the point of being redundant ('Remove specific handle - Remove specific handle'), which doesn't add value. It lacks structure and wastes space with repetition instead of providing useful information, making it inefficient rather than appropriately brief.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a destructive tool with 3 parameters, 0% schema coverage, no output schema, and no annotations beyond basic hints, the description is incomplete. It doesn't explain what a handle is, the consequences of removal, parameter usage, or expected outcomes, leaving significant gaps for the agent to operate effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so parameters are undocumented in the schema. The description provides no information about the parameters (handleId, x-request-id, x-trace-id), their meanings, or formats. It fails to compensate for the lack of schema documentation, leaving the agent guessing about required inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Remove specific handle - Remove specific handle' is tautological, essentially restating the name/title without adding meaningful clarification. It doesn't specify what a 'handle' represents in this context or what the removal entails, making the purpose vague despite the verb+resource structure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing an existing handle, or differentiate from sibling tools like 'deleteHandle' (not listed but implied by context) or 'updateHandle'. This leaves the agent without context for proper tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, which the description aligns with by describing a reboot that modifies system state. The description adds valuable context beyond annotations: it explains the rescue mode behavior (Linux-based, mounts OS disk, allows file repair, automatic reboot back to regular OS), which helps the agent understand the operational impact. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose. It uses clear sentences to explain rescue mode mechanics and warnings. While slightly verbose, each sentence adds useful information (e.g., Linux-based system, disk mounting, reboot behavior, advanced user note).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive tool with no output schema and 0% schema description coverage, the description adequately covers the behavioral aspects (what rescue mode does, its effects). However, it lacks critical details: no parameter explanations, no error handling or return values, and minimal guidance on usage versus siblings. This leaves gaps for safe agent invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning parameter descriptions are missing in the schema. The tool description does not mention any parameters (instanceId, rescueBody with sshKeys, userData, rootPassword, x-request-id, x-trace-id), leaving their purpose and usage completely undocumented. This fails to compensate for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('rescue'), target ('compute instance / resource'), and mechanism ('reboot your instance in rescue mode to resolve system issues'). It explains what rescue mode does (Linux-based system, mounts OS disk for repair, reboots back to regular OS). However, it doesn't explicitly differentiate from siblings like 'restart' or 'reinstallInstance' beyond mentioning it's for 'advanced users'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context ('to resolve system issues') and notes it's 'for advanced users,' which provides some guidance. However, it doesn't explicitly state when to use this versus alternatives like 'restart' (normal reboot) or 'reinstallInstance' (full OS reinstall), nor does it mention prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, suggesting a non-read operation with potential side effects. The description adds that it's for 'resending' verification, implying it triggers an email send, which aligns with the destructive hint. However, it doesn't disclose additional behaviors like rate limits, auth requirements, or what happens if the user is already verified, leaving gaps beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded, with no redundant sentences. However, it's slightly repetitive ('Resend email verification' appears twice), and the lack of detail makes it feel under-specified rather than optimally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (mutative action with 4 parameters, no output schema, and 0% schema coverage), the description is incomplete. It doesn't explain the outcome (e.g., success/failure response, email content), parameter usage, or error conditions. With annotations providing only basic hints, more context is needed for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so parameters are undocumented in the schema. The description mentions 'for a specific user', hinting at the 'userId' parameter, but doesn't explain the other three parameters (x-request-id, x-trace-id, redirectUrl) or their purposes. It adds minimal semantic value beyond the schema's structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action ('Resend email verification') and target ('for a specific user'), which clarifies the purpose. However, it's somewhat vague about what 'email verification' entails (e.g., verification link, code) and doesn't distinguish from siblings like 'resetPassword' or 'generateClientSecret', which could involve similar user-communication actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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., user must exist, email must be unverified), exclusions, or related tools like 'createUser' or 'updateUser' that might handle verification differently. The description alone offers no usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=true, which the description doesn't explicitly address. However, 'send reset password email' implies a mutation (changing state by triggering an email) and potential disruption (resetting passwords is destructive), so it aligns with annotations. The description adds minimal behavioral context beyond annotations, such as specifying it's for a 'specific user', but doesn't detail rate limits, auth needs, or email content.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief but redundant, repeating 'Send reset password email' twice. It's front-loaded with the core action but wastes words on repetition. While concise, it lacks efficiency as the second phrase adds no new information, failing to earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (destructive mutation with 4 parameters, no output schema, and 0% schema coverage), the description is inadequate. It doesn't explain what the tool returns, error conditions, or side effects. With annotations covering safety but no output schema, more detail on behavior and parameters is needed for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 'for a specific user', which hints at the 'userId' parameter, but doesn't explain the other three parameters (x-request-id, x-trace-id, redirectUrl). No details are provided on parameter formats, purposes, or usage, leaving significant gaps in understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description restates the tool name and title without adding specificity. It says 'Send reset password email for a specific user', which is essentially a tautology of the title 'Send reset password email'. It doesn't clarify what the email contains, how it's delivered, or what happens after sending. Compared to sibling tools like 'resetPasswordAction' (which might handle the actual password change), it lacks differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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., user must exist), when it's appropriate (e.g., for forgotten passwords), or what to do after sending (e.g., follow up with 'resetPasswordAction'). The description offers no context for usage relative to other tools in the list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, which the description aligns with by describing a password reset action. The description adds useful context by specifying that it 'will reset the current password to the password that you provided in the body,' clarifying the mutation behavior. However, it doesn't mention potential side effects like instance downtime or authentication requirements beyond what annotations imply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is repetitive, restating the same phrase twice, which adds no value. While it's brief, the redundancy reduces efficiency. The information is front-loaded but could be more streamlined by eliminating the repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 output schema and 0% parameter coverage in the schema, the description is insufficient. It lacks details on return values, error conditions, authentication needs, or system-specific behaviors (e.g., OS differences), making it incomplete for safe and effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for the input schema, the description fails to explain any parameters. It mentions providing a password 'in the body' but doesn't detail the required fields (instanceId, x-request-id, resetPasswordActionBody) or their purposes, leaving significant gaps in parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('reset password') and target ('compute instance / resource referenced by an id'), which is specific and actionable. However, it doesn't explicitly differentiate from the sibling tool 'resetPassword' (without 'Action'), leaving some ambiguity about when to use one versus the other.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 'resetPassword' or other instance management tools. It lacks context about prerequisites, timing, or exclusions, offering only a basic functional statement without operational guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate destructiveHint=true and readOnlyHint=false, covering safety and mutation. The description adds minimal context by implying the tool acts on an existing instance, but doesn't detail side effects like downtime, state changes, or error conditions. It doesn't contradict annotations, but offers little beyond them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences that are nearly identical, wasting space without adding value. It's front-loaded but repetitive, lacking efficiency. Each sentence doesn't earn its place, as the second merely rephrases the first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation tool with 3 parameters (0% schema coverage), no output schema, and many siblings, the description is inadequate. It lacks details on parameters, behavior, outcomes, or differentiation, 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.

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 'id' but doesn't explain parameters like 'instanceId', 'x-request-id', or 'x-trace-id', leaving their purposes and formats undocumented. This fails to add meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action ('restart') and resource ('compute instance/resource'), but is repetitive and vague about scope. It doesn't distinguish from siblings like 'shutdown', 'start', or 'stop' beyond the basic verb, and the second sentence merely restates the first without adding clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'shutdown', 'start', or 'stop' is provided. The description only repeats the basic action without context, prerequisites, or exclusions, leaving the agent to infer usage from tool names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds that this is a 'list' and a 'reference,' but doesn't disclose additional behavioral traits like pagination behavior (implied by page/size parameters), rate limits, or authentication needs. It provides some context but minimal beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences that directly state the tool's function and context. It's front-loaded with the core purpose and avoids unnecessary details, though it could be slightly more structured by separating usage notes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters with 0% schema coverage, no output schema, and annotations only covering safety, the description is incomplete. It doesn't explain parameter usage, return values, or behavioral details like pagination, making it inadequate for a tool with this complexity and lack of structured documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries full burden for parameter meaning. It mentions no parameters explicitly, failing to explain the purpose of 'page', 'size', 'apiName', 'orderBy', 'x-trace-id', or 'x-request-id'. This leaves key filtering and pagination semantics undocumented, not compensating for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List all available API permissions' with the context that it 'serves as a reference for specifying roles.' It specifies the verb ('List') and resource ('API permissions'), but doesn't explicitly differentiate from sibling tools like 'retrieveRoleList' or 'retrieveAssignmentList' beyond mentioning its unique role reference purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by stating it 'serves as a reference for specifying roles' and notes that 'not all actions are available for each endpoint,' which suggests when this reference might be needed. However, it doesn't provide explicit when-to-use guidance, alternatives, or exclusions compared to other list tools in the sibling set.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true and destructiveHint=false, which already inform the agent this is a safe read operation. The description adds context by specifying it retrieves 'attributes' for a 'specific tag assignment,' but does not disclose additional behavioral traits such as error conditions, authentication needs, or rate limits. It does not contradict annotations, so it earns a baseline score for adding some value beyond the structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the core purpose, but it is somewhat redundant (repeating 'Get specific assignment for the tag') and could be more structured. It uses two sentences efficiently, but the repetition slightly reduces its conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema, 0% schema description coverage, and annotations only cover safety, the description is incomplete. It does not explain return values, error handling, or the semantics of undocumented parameters like x-request-id. For a tool with multiple parameters and no structured output information, more detail is needed to be fully helpful.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning no parameters are documented in the schema. The description mentions 'resource type and resource id is required,' which partially explains two of the five parameters (resourceType and resourceId) but ignores tagId, x-request-id, and x-trace-id. It fails to fully compensate for the lack of schema documentation, leaving most parameters unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 attributes for a specific tag assignment in your account.' It specifies the verb ('Get'), resource ('tag assignment'), and scope ('specific'), but does not explicitly differentiate it from sibling tools like 'retrieveAssignmentList' or 'retrieveTag', which reduces clarity in distinguishing exact use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance by stating 'For this the resource type and resource id is required,' which hints at prerequisites but does not explain when to use this tool versus alternatives like 'retrieveAssignmentList' or 'retrieveTag'. No explicit when/when-not scenarios or comparisons to siblings are included.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it lists 'all existing assignments for a tag in your account', which provides scope context. However, it doesn't mention pagination behavior (implied by page/size parameters), rate limits, or authentication requirements beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the core purpose. The repetition of 'List tag assignments' is slightly redundant but not excessive. Every phrase adds some value, though it could be more structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 7 parameters (0% documented in schema), no output schema, and no behavioral annotations beyond read-only, the description is insufficient. It doesn't explain parameter meanings, return format, pagination, or error conditions. The annotations help with safety but don't compensate for missing operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage for 7 parameters, the description carries full burden but only mentions 'filter' generically. It doesn't explain what tagId represents, what page/size do, what resourceType filters, or what orderBy controls. The description fails to compensate for the complete lack of schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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 ('tag assignments'), and specifies filtering capability. It distinguishes from siblings like 'retrieveAssignment' (singular) and 'createAssignment' (write operation), though it doesn't explicitly contrast with other list tools like 'retrieveTagList'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions filtering but provides no guidance on when to use this tool versus alternatives like 'retrieveAssignment' (singular retrieval) or other list tools. No context about prerequisites, typical use cases, or exclusion criteria is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds minimal behavioral context by implying filtering capabilities ('filters the history'), but doesn't elaborate on what filtering entails, rate limits, authentication needs, or output format. With annotations covering safety, the description provides some value but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief but inefficient—it repeats 'List history about your assignments' and uses a redundant phrase ('List and filters'). While front-loaded, it wastes space on tautology rather than adding value. It could be more concise by eliminating repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (11 parameters, 0% schema coverage, no output schema), the description is inadequate. It doesn't explain parameter meanings, filtering behavior, pagination (via page/size), or what the audit history entails. With annotations covering safety, it partially helps, but gaps in parameter and behavioral details make it incomplete for effective tool use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning none of the 11 parameters are documented in the schema. The description mentions 'filters' but doesn't specify which parameters correspond to filtering (e.g., tagId, startDate, endDate) or explain their purposes. This fails to compensate for the lack of schema documentation, leaving parameters largely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description restates the title ('List history about your assignments') and adds a tautological phrase ('List and filters the history about your assignments'), which essentially repeats the name/title without providing specific differentiation from sibling tools. It doesn't clearly distinguish this audit-list tool from other list/retrieve tools in the sibling set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 any context, prerequisites, or exclusions, nor does it reference sibling tools like 'retrieveAssignment' or 'retrieveAssignmentList' that might be related. This leaves the agent with no usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds context by specifying the types of statistics returned (count, disk space metrics), which isn't covered by annotations. However, it doesn't disclose other behavioral traits like rate limits, authentication needs, pagination, or error conditions. With annotations covering safety, the description provides moderate additional value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is repetitive and inefficient: it repeats 'List statistics regarding the customer's custom images' twice in a single sentence. The second part adds useful detail (specific metrics), but the redundancy wastes space. It could be restructured as a single concise sentence (e.g., 'List statistics for custom images, including count, used disk space, free space, and total space').

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (read-only stats retrieval), annotations cover safety, and no output schema exists, the description is moderately complete. It specifies the statistics returned, which helps the agent understand the output. However, it lacks parameter explanations (schema coverage 0%) and doesn't mention behavioral aspects like response format or error handling, leaving gaps for a tool with required parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 mentions no parameters at all, failing to explain the purpose of 'x-request-id' (required) or 'x-trace-id'. However, since there are only 2 parameters (both likely for request tracing/identification), the baseline is 3 as the description doesn't add semantic value but the parameter count is low and straightforward.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List statistics regarding the customer's custom images' with specific metrics listed (number uploaded, disk space usage, free/total disk space). It distinguishes from siblings like 'retrieveImageList' or 'retrieveImage' by focusing on aggregated statistics rather than listing or retrieving individual images. However, it doesn't explicitly contrast with 'retrieveObjectStoragesStats' which handles similar statistics for a different resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 custom images to exist), exclusions (e.g., not for instance statistics), or direct comparisons to sibling tools like 'retrieveImageList' (which lists images) or 'retrieveObjectStoragesStats' (which provides stats for object storage). Usage is implied only by the title and description repetition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it lists 'all' data centers, implying completeness, but doesn't mention pagination behavior, rate limits, or authentication requirements. With annotations covering safety, the description provides minimal additional 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose. It avoids redundancy with the title and name. However, it could be slightly more structured by separating scope from output details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 9 parameters (0% schema coverage), no output schema, and no annotations beyond read/destructive hints, the description is inadequate. It doesn't explain parameter usage, return format, pagination, or filtering capabilities, leaving significant gaps for the agent to operate effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning none of the 9 parameters are documented in the schema. The description provides no information about parameters, not even hinting at filtering (e.g., by name or region) or pagination (page/size). This leaves the agent with no semantic understanding of what the parameters do.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List all data centers and their corresponding regions.' It specifies the verb ('List') and resource ('data centers'), and adds useful detail about including regions. However, it doesn't explicitly differentiate from sibling tools like 'retrieveInstanceList' or 'retrievePrivateNetworkList' that also list resources, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, constraints, or sibling tools that might be relevant for similar queries. The agent must infer usage from the tool name and context alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds minimal behavioral context by implying it fetches 'all attributes', but doesn't detail aspects like error handling, rate limits, or authentication needs. With annotations covering safety, it adds some value but not rich behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two short sentences that directly state the tool's function. It's front-loaded with the core action and avoids unnecessary details. However, the repetition ('Retrieve a DNS Zone by zone name - Get all attributes...') slightly reduces efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters with 0% schema coverage, no output schema, and annotations only cover read/destructive hints, the description is incomplete. It doesn't explain parameter usage, return values, error cases, or how it differs from siblings. For a retrieval tool with undocumented inputs, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning parameters lack documentation in the schema. The description mentions 'zoneName' but doesn't explain its format or purpose, and ignores 'x-request-id' and 'x-trace-id'. It adds minimal semantics beyond naming one parameter, failing to compensate for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Retrieve a DNS Zone by zone name - Get all attributes for a specific DNS Zone'. It specifies the verb ('retrieve'), resource ('DNS Zone'), and scope ('by zone name', 'all attributes'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'retrieveDnsZonesList' (which likely lists multiple zones) or 'retrieveDnsZoneRecordsList' (which focuses on records within a zone), missing full sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 'retrieveDnsZonesList' for listing zones or 'retrieveDnsZoneRecordsList' for zone records, nor does it specify prerequisites or exclusions. Usage is implied by the action but lacks explicit context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate read-only and non-destructive behavior, which the description aligns with by using 'List' and 'Get'. However, the description adds minimal context beyond annotations—it doesn't mention pagination (implied by 'page' and 'size' parameters), search capabilities, or rate limits. With annotations covering safety, it meets a baseline but lacks rich behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded, with two sentences that directly state the tool's function. However, the second sentence is redundant ('Get all the records of a DNS Zone' repeats the first), slightly reducing efficiency. Overall, it's concise but could be more structured by eliminating repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters with 0% schema coverage, no output schema, and annotations only covering safety, the description is incomplete. It doesn't explain parameter usage, return values, pagination, or filtering options, leaving significant gaps for a list operation with multiple optional parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so parameters like 'page', 'size', 'search', and 'orderBy' are undocumented in both schema and description. The description only mentions 'DNS Zone' (hinting at 'zoneName') but doesn't explain any parameters' purposes, formats, or interactions, failing to compensate for the low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's purpose ('List a DNS Zone's records') but is somewhat vague and repetitive. It specifies the verb ('List') and resource ('DNS Zone's records'), but doesn't differentiate from sibling tools like 'retrieveDnsZonesList' or 'retrieveDnsZone' beyond the obvious scope of records. The second sentence ('Get all the records of a DNS Zone') essentially restates the first without adding clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 sibling tools like 'retrieveDnsZone' (which might retrieve zone metadata) or 'bulkDeleteDnsZoneRecords' (for deletion), nor does it specify prerequisites such as needing an existing DNS zone. Usage is implied by the name and description alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.