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

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true and destructiveHint=false, so the mutation profile is covered. The description adds nothing beyond the endpoint path: no statement of what happens if the instance is already assigned, no error behavior, and no note that the call is non-idempotent.

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?

Very short and front-loaded, but the second line repeats the first almost verbatim ('Add instance to a firewall' vs 'Add a specific instance to a firewall'), so one sentence is wasted.

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?

Adequate minimum for a simple 2-required-param mutation with full schema coverage and annotations, and no output schema to explain. It falls short on lifecycle questions an agent would care about — idempotency on repeat calls and error conditions — that neither the schema nor annotations cover.

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 100%, so both firewallId and instanceId are documented in the schema, including the int64 type of instanceId. The description adds no meaning beyond the endpoint template, so the baseline of 3 applies.

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?

Clearly states the verb and resource: add a specific instance to a firewall, plus the REST endpoint POST /v1/firewalls/{firewallId}/instances/{instanceId}. The pairing with the sibling unassign_instance_firewall is inferable from the name, though the description never names it.

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 versus alternatives such as unassign_instance_firewall or the private-network equivalent assign_instance_private_network, and no stated prerequisites (e.g., firewall and instance must already exist). Usage is only implied by the name.

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, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the description need only add operational context — but it adds essentially nothing beyond restating the endpoint path. It does not say what happens if the instance is already a member, whether the action is reversible, what errors can occur, or what is returned.

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?

It is short, but the first line duplicates the title and the second line restates the first, so roughly half the text is redundant. The endpoint is front-loaded, which is good, but the space is spent on repetition rather than new 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 simple two-parameter assignment operation with full schema documentation and annotations, the definition is adequate to invoke the tool correctly. However, with no output schema, the description should indicate what comes back (the private network, the instance, or nothing) and whether repeated calls are meaningful, given idempotentHint=false.

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 100%, so both required parameters (privateNetworkId, instanceId) plus x-trace-id are already fully documented in the input schema. The description only echoes them via the URL template; baseline 3 applies since the schema does the work.

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 gives a specific verb and resource ("Add instance to a Private Network") and includes the concrete HTTP endpoint, so the agent knows exactly which API operation it wraps. The one clear sibling, unassign_instance_private_network, is implicitly distinguished by the verb, though it's never named.

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?

Usage is only implied by the operation name: assign an instance when it needs to join a private network. There is no explicit when-to-use guidance, no prerequisites (e.g. instance must exist, be in the same region), and no reference to the unassign sibling as the inverse operation.

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 readOnly=false, idempotent=false, destructive=false, and openWorld=true, so the safety profile is largely covered. The description adds the HTTP POST route and target resource types, but it does not explain preconditions, whether an IP can be reassigned, or what happens if the VIP is already assigned.

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 short and front-loads the operation, but the first sentence is nearly repeated by the second. The bracketed endpoint adds useful detail, but the duplication prevents it from being 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 mutation tool with full schema coverage and annotations, the description is adequate but incomplete. It lacks important operational context such as preconditions, response expectations, and behavior when the VIP is already assigned or the resource is unavailable.

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 100%, so the schema already documents all parameters, including the `resourceType` enum. The description adds a small amount of meaning by clarifying that resourceId is the machine id, but otherwise it does not go meaningfully 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 a specific verb and resource: assigning a VIP to a VPS/VDS/Bare Metal resource. It also exposes the endpoint path, making the operation concrete. However, it does not explicitly distinguish this from the sibling `unassign_ip` alternative.

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 gives no explicit when-to-use guidance beyond restating the operation. It does not mention prerequisites, duplicate-assignment behavior, or when to use `unassign_ip` instead. The only contextual hint is that assignment is done using the machine id.

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 destructiveHint=true, idempotentHint=true and openWorldHint=true, so the description adds nothing about safety. For a bulk destructive operation it omits whether the delete is atomic, what happens on partial/invalid record IDs, or whether deletion is recoverable.

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 short sentences, front-loaded with the action. The bracketed HTTP path is mildly redundant with the tool name but harmless.

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?

A destructive, nested-body bulk mutation with no output schema needs more than an endpoint echo: no note on irreversibility, batch limits, or error semantics. Adequate to identify the tool, insufficient to call it confidently.

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 100% and both required parameters plus the trace header are documented inline, so the schema carries the burden. The description adds no meaning beyond the schema, which is baseline 3.

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?

States a specific verb and resource ('bulk delete DNS zone records') and the 'bulk' qualifier implicitly contrasts with the single-record sibling delete_dns_zone_record. Clear, though it never names the single-record alternative explicitly.

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?

Usage is only implied by the word 'bulk' and the endpoint path. There is no explicit guidance on when to choose this over repeated calls to delete_dns_zone_record, nor any prerequisite or limit 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 already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description contributes nothing beyond that: it does not explain what happens to the domain after cancellation, whether the cancellation is scheduled at cancelDate, or that a cancellation can later be reversed via revoke_cancel_domain.

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?

It is short and front-loaded, but the sentence 'Cancel a specific domain' appears twice — once as prose and once as the endpoint label — which is pure redundancy rather than earned 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 mutation tool with a required nested request body, no output schema, and a closely related undo tool in the sibling list, the description should at minimum explain the cancellation lifecycle and point to revoke_cancel_domain. None of that is present, leaving the agent under-informed about consequences.

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 100%, including the nested body with the reason enum, cancelDate, reasonText and x-trace-id, so the baseline of 3 applies. The description mentions no parameters at all and therefore adds zero 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 merely restates the tool name ('Cancel a specific domain') and appends the raw endpoint path. It names a verb and resource but adds no differentiation from neighbors like revoke_cancel_domain or update_domain, so an agent learns nothing beyond 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?

There is no statement of when this tool should be used instead of revoke_cancel_domain, cancel_instance, or cancel_object_storage, nor any prerequisites such as domain ownership or pending-transfer state. Usage is only implied by the verb 'cancel'.

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 the mutation and safety profile: readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false. The description adds no behavioral context beyond the HTTP endpoint—it does not say what happens on cancellation, whether a completed check can be cancelled, or what the body must contain.

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 short but redundant: “Cancel check” appears twice, and the endpoint line is the only extra information. The repetition does not earn its place, and the overall brevity comes at the cost of under-specification rather than efficient 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 that this is a mutation tool with annotations, a nested request body, and no output schema, the description is too thin. It omits what a check is, the effect of cancellation, prerequisite states, and any indication of return behavior 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?

Schema description coverage is 100%, so the schema already documents checkId, body, and x-trace-id. The description only exposes checkId through the endpoint path and adds no meaning beyond that baseline.

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 and resource with the endpoint path, but the visible text is essentially the same as the tool name/title repeated twice. It identifies that this cancels a check, yet gives no scope or qualitative detail about what kind of check or what cancellation means.

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 siblings such as get_ext_check, start_ext_check, or cancel_ext_check_collection. The description only restates the action and does not mention prerequisites, valid states, or alternatives.

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, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered, but the description adds nothing beyond it. It never says what cancelling does to in-flight checks, whether the collection's status becomes terminal, or whether the operation can be reversed — meaningful gaps for a state-changing cancel.

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 same phrase appears twice and the bracketed HTTP route is embedded in prose, so the text is redundant rather than efficient. Nothing is front-loaded beyond the tool name, and no sentence earns extra place by conveying new 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 mutating, non-idempotent cancel operation with no output schema, the description omits the essential semantics: what state the collection ends in, what happens to checks inside it, and whether a re-cancel is an error. Annotations and schema cover the request shape but not the effect.

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 100%: checkCollectionId, body.status (enum restricted to 'cancelled') and x-trace-id are all documented in the schema itself. The description adds no meaning beyond that, so the baseline 3 applies.

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 text restates the tool name and annotation title verbatim ('Cancel check collection') twice, adding only the raw HTTP path. It gives no indication of what a 'check collection' is or how cancelling a collection differs from cancelling a single check, despite siblings like cancel_ext_check, start_ext_check_collection and get_ext_check_collection.

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 when-to-use guidance and no mention of alternatives, even though cancel_ext_check is an obvious adjacent choice the agent must discriminate against. The agent is left to infer the relationship purely from the tool name.

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 declare this is a mutating (readOnlyHint=false), non-idempotent, open-world operation, but the description adds nothing beyond the HTTP path. It does not say that cancelling is effectively final, what happens to in-flight remediation steps, or that the only permitted transition is to status 'cancelled'.

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?

It is short, but 'Cancel remedy' is printed twice (once before and once after the endpoint), which is pure redundancy. Front-loaded verb is fine, but the payload carries no extra 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 state-changing cancellation endpoint with no output schema, an agent needs to know preconditions (remedy must be running/pending) and post-effects. Neither is provided, leaving the definition thin.

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 coverage is 100% – remedyId, the x-trace-id header, and the body.status enum are all documented in the schema. The description adds no parameter meaning, so baseline 3 applies.

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 verb and resource ('Cancel remedy') and gives the endpoint path, so the basic action is identifiable. But it merely restates the name/title twice and does nothing to distinguish it from siblings such as get_ext_remedy, list_ext_remedies, start_ext_remedy, or cancel_ext_check.

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 cancel a remedy versus retrieving it or starting a new one, no prerequisites, and no mention of which remedy states can be cancelled. The agent is left to infer this from the sibling names.

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 the safety profile: readOnly false, openWorld true, idempotent false, and destructive false. The description adds only that cancellation can happen at any time for a previously created instance, without explaining the resulting state, reversibility, or how cancellation differs behaviorally from stopping or shutting down.

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 action is front-loaded and the description is short. There is a typo in 'Your are' and the second sentence adds limited value, but it remains concise and structurally easy to parse.

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?

The parameter schema is fully documented and annotations provide a safety profile, but the description does not resolve the important ambiguity between canceling, stopping, and shutting down an instance. For a lifecycle mutation with a nested request body and no output schema, that gap leaves the definition only minimally complete.

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 100%, so parameter meanings are already documented, including instanceId and the nested body with cancelDate. The description adds no syntax or semantic detail beyond the schema's coverage, so the baseline of 3 is appropriate.

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 a specific verb and resource: cancel a specific instance by id, and includes the endpoint. It is clear what the tool does, but it does not differentiate cancellation from nearby instance lifecycle actions such as instance_stop or instance_shutdown.

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 phrase 'previously created instance' and 'at any time' gives some implied usage context. However, it does not explicitly say when to use this instead of instance_stop, instance_shutdown, or other lifecycle alternatives, nor does it state exclusions or preconditions.

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, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is partly covered. The description adds genuinely non-annotated behavior: the cancellation is scheduled for the next possible date rather than immediate, and timing depends on contract periods. It still doesn't say whether data is retained until the cancellation date, whether the action is reversible, or what state the storage enters.

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 core sentence is efficient and front-loaded, but it is immediately restated verbatim after the endpoint line, and the redundant 'Cancels the specified object storage at the next possible date' phrasing appears three times across description and annotation title. The PATCH endpoint reference is useful; the duplication is dead weight.

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 single-action mutation tool with full schema coverage and no output schema, the description covers what it does, the scheduling semantics, and the contract-related caveat. What remains missing is the resulting resource state and reversibility, which are secondary but relevant for a cancellation operation.

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 100%, so the schema already documents objectStorageId, the nested body.cancelDate, and x-trace-id; baseline 3 applies. The description could clarify that cancelDate is a requested date constrained by contract terms, but it adds nothing about parameters 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?

States a specific verb and resource ('Cancels the specified object storage') plus the timing scope ('at the next possible date'), which distinguishes it from sibling cancellation tools like cancel_instance, cancel_domain, and cancel_ext_check. It stops short of naming those siblings or contrasting their effects, so an agent must infer the distinction from the resource name.

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

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

The warning 'Please be aware of your contract periods' implies that contract term affects when cancellation takes effect, which is useful context. However, there is no explicit when-to-use guidance, no mention of prerequisites such as permissions or whether a scheduled cancellation can be revoked (compare revoke_cancel_domain), leaving the agent to infer the workflow.

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 read-only, idempotent, open-world, and non-destructive behavior. The description adds meaningful behavioral detail beyond annotations: it returns no content on success and mirrors CMS error payloads with the CMS HTTP status when preconditions fail.

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 short and front-loaded, with the purpose stated first and return behavior immediately after. The inline endpoint is slightly redundant but not harmful, and every sentence contributes useful context.

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?

With annotations covering safety and idempotency and no output schema, the description appropriately explains the success and error return behavior. It is nearly complete for an agent, though it could explicitly name the related relocation operation for clearer workflow 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 100%, and both parameters are documented directly in the schema. The description mentions the instance context through the endpoint path but adds no additional parameter semantics beyond what the schema already 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 states a specific verb and resource: checking whether an instance can be moved to another host, with the exact GET endpoint. It clearly frames this as a precondition check before relocation, though it does not explicitly name the sibling relocation action (e.g., request_region_change) it pairs with.

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 phrase 'before relocating the instance from its current host' implies the intended usage context: run this check prior to a relocation operation. However, it does not explicitly say when not to use it or name the sibling action to use afterward, so guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds only the POST path and otherwise does not disclose permissions required, what confirmation actually does, whether the action is reversible, or what response to expect, so it adds little beyond the structured 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 short and front-loaded, but it repeats the same phrase 'Confirm transfer out for a domain' twice, with the second sentence adding no new information. The endpoint line is useful but does not compensate for the duplication.

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 mutating confirmation action with no output schema, the description should explain what confirmation means and any important lifecycle effects. Although annotations and full schema coverage reduce the burden, the description omits essential usage and consequence context that an agent needs before invoking a non-idempotent POST operation.

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 100%, so both the required domain and optional x-trace-id parameters are already documented in the schema. The description only repeats 'domain' through the path template and adds no extra meaning such as format, constraints, or trace-id purpose, making the baseline 3 appropriate.

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 a specific verb, 'Confirm transfer out', and resource, 'a domain', and includes the POST endpoint path. However, it does not distinguish this action from the sibling revoke_domain_transfer_out or explain what 'confirm' means in the transfer lifecycle, so sibling differentiation is left to inference.

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, when not to use it, or how it relates to alternatives such as revoke_domain_transfer_out or cancel_domain. The only context is the HTTP endpoint, which does not tell an agent when this confirmation is appropriate.

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, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the POST endpoint and the persistence effect of the marking, but says nothing about what happens if the assignment already exists (a real concern given idempotentHint=false) or about permission requirements for the access-restriction use case.

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?

Front-loaded with the action and resource, and the trailing sentence adds genuine explanatory value. There is mild redundancy between the title line, the bracketed endpoint, and 'Create a new tag assignment', but nothing harmful.

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 mutation tool with full parameter documentation, no output schema, and complete annotations, the core is present. Still missing are the duplicate-assignment behavior, any precondition that the tag/resource must exist, and whether the call returns the created assignment — reasonable gaps for an agent forming its first call.

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 coverage is 100% — tagId, resourceId, resourceType, and x-trace-id are each documented, including the resourceType enum values in the description ('instance|image|object-storage'). The prose adds nothing beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ('Create a new assignment for the tag') and then explains what an assignment semantically does — marks a resource with a tag for organization or access restriction. That explanation meaningfully distinguishes it from create_tag and delete_assignment, though no sibling is named explicitly.

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 phrase 'for organizing purposes or to restrict access to that resource' hints at two use cases, but there is no explicit when-to-use guidance, no prerequisites (the tag presumably must already exist), and no routing toward create_tag vs. create_assignment for an agent unsure which to call.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) the description discloses that the operation is asynchronous and slow, that unsupported formats are rejected, and that downloads fail when quota limits are exceeded. Those are genuine behavioral traits an agent needs. It stops short of describing what is returned or whether re-submitting the same URL duplicates the image, which matters given idempotentHint=false.

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 purpose and endpoint are front-loaded, and each subsequent sentence contributes new information (formats, async duration, status polling, quota rejection). There is minor padding: the bracketed endpoint tag and the restatement in 'In order to provide a custom image please specify...' duplicate 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 create tool with no output schema, the description covers format validation, async timing, limit-based rejection and the follow-up status check — enough to call it correctly. The one remaining gap is that it does not say the response yields an image identifier the agent can then poll with retrieve_image.

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 coverage is 100%, so baseline is 3, but the description adds real meaning to the `url` parameter — it must be a direct-download link and must resolve to .iso or .qcow2 content, with other formats rejected. That constraint is not stated in the schema's 'URL from where the image has been downloaded / 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 states a specific verb and resource — providing a custom image via a downloadable URL — with the endpoint noted. It is clearly distinct from the retrieval/mutation siblings such as retrieve_image_list, update_image and delete_image, though it never names an alternative explicitly.

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 gives preconditions (URL must be a direct download link, format must be .iso or .qcow2) and points to a GET/retrieve_image step for checking status, which is useful implied routing. But it does not say when to use this versus creating an instance with an existing image, or when a custom image is the wrong choice.

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 declare readOnlyHint=false, idempotentHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description is consistent with those annotations and adds the endpoint and customer scope, but it does not disclose behavior such as duplicate-zone handling, permissions, or side effects.

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

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

The description is short and front-loaded with the action and endpoint. It is efficient overall, though the second sentence largely restates the first without adding substantive detail.

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 simple create operation with two parameters and full schema coverage, plus annotations covering mutability and safety, the description is minimally adequate. It could do more to explain uniqueness expectations, customer scoping, or what the response will contain.

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 100%, and both parameters are documented in the schema, including the nested body.zoneName field. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

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 a specific verb and resource: creating a DNS zone, and adds the HTTP endpoint POST /v1/dns/zones. It is clear enough to distinguish this from retrieve_dns_zone or delete_dns_zone, though it does not explicitly differentiate from create_dns_zone_record.

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 such as create_dns_zone_record, nor any prerequisites or constraints. The description only establishes that it creates a zone, leaving usage decisions to the agent.

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 that this is a non-read-only, non-idempotent, open-world, non-destructive operation, so the safety profile is covered. The description adds almost no behavioral context beyond the endpoint path—nothing about duplicate handling, permission requirements, or what happens when a record with the same name already 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 very short and front-loads the operation name and endpoint. The second sentence is redundant with the first, but there is no padding or wandering 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?

This is a mutation tool with a nested request body and no output schema, yet the description only restates the name and endpoint. It leaves out operational context such as whether the call fails on duplicate records, permission expectations, and how this differs from update_dns_zone_record, which is important for correct 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 100%, so the schema already documents zoneName and all nested body fields including record type, TTL, priority, and data. The description only implicitly indicates that zoneName is a path parameter and otherwise adds no meaning beyond the schema, matching the baseline for high-coverage schemas.

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?

It clearly states a specific verb and resource ('Create DNS zone record') and includes the POST endpoint, which distinguishes it from sibling operations like update_dns_zone_record or create_dns_zone. The second sentence is largely repetitive, but the core purpose is unambiguous.

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 gives no guidance on when to use this tool versus alternatives such as update_dns_zone_record or create_dns_zone, and it does not mention prerequisites such as existing zone requirements or duplicate-record behavior. It assumes the agent already knows the DNS API 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 already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds modest value by explaining that firewall status gates whether rules are active, but says nothing about what is returned, whether creation fails on duplicate names, or what permissions are required.

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?

Front-loaded and short, but the second sentence largely duplicates the schema's own 'status' description, and the bracketed endpoint repeats the title. Two of three sentences carry real 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?

No output schema exists, so the description would ideally indicate what a successful creation returns (e.g., an identifier) and any duplicate-name behavior. For a nested-object create operation, the description covers the shape but not the outcome.

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 coverage is 100% and deeply documented (nested rule objects, CIDR, protocol enums, port lists). The description's mention of name, rules, and status merely restates what the schema already explains verbatim, adding no new semantics.

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?

States a specific verb and resource ('Create a new firewall definition') plus the endpoint POST /v1/firewalls, and notes the inputs (name, rules). It doesn't differentiate from sibling write tools like put_firewall or patch_firewall, so an agent must infer create-vs-replace from the name alone.

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?

Usage is only implied by the verb 'create'; there is no explicit statement of when to use this instead of put_firewall (full replacement) or patch_firewall (partial update). No prerequisites, limits, or exclusions are given.

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, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the description needs only to add context beyond that — and it adds none. It doesn't mention that re-posting creates a duplicate handle (non-idempotent), that .it/.fr/.nl contacts have jurisdiction-specific required fields, or what the response contains. No contradiction, but pure restatement of the title.

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?

It's short, but not concise: the sentence 'Create specific handle' is repeated verbatim after the endpoint annotation, so half the text is pure duplication. Front-loading is fine only because there is almost no 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?

This is a create tool with a deeply nested 20+ field body, no output schema, and jurisdiction-dependent required fields — a case where the description should carry real weight. It says nothing about what a successful response returns (handle ID, validation state) or which fields matter for which TLD, leaving the agent to reverse-engineer the schema.

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 100%, so the nested body fields (handleType, pin, legalStatus, nicItEntityType, etc.) are already documented in-schema, making 3 the baseline. The description contributes nothing about the body — no example payload, no conditional requirements, and no explanation of the x-trace-id header.

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 has a verb (Create) and a resource (handle), and the HTTP endpoint POST /v1/domains/handles confirms it's a registrant-handle creation call. But 'specific' is filler and the sentence is duplicated, so there's no differentiation from siblings like update_handle or create_user beyond the noun 'handle'.

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 when-to-use guidance, no preconditions, and no mention of alternatives (e.g. update_handle for existing handles, list_handles to check for duplicates). The agent must infer from the name alone that this is the creation path.

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, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. Beyond that the description adds almost nothing behavioral: it does not mention that the chosen `period` commits to a 1/12/24-month billing contract, that the call provisions a billable resource, or whether retrying creates duplicates (relevant given idempotentHint=false). The one addition, a product/disk-size table, is selection data rather than behavior.

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 first sentence is duplicated almost verbatim by the second, and raw HTML <table> markup is pasted into the description. Worst of all it is cut off mid-cell ("<td>400 GB SSD</td><tr><td>V157</td>..."), so space is consumed without delivering the complete information it starts to.

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 heavy creation tool with a nested body object, ~12 properties, and no output schema, so the description should carry more weight. Key omissions remain: what the response contains (instance id? status?), whether provisioning is asynchronous, and the billing/permission implications. The product table partially compensates for productId, but nowhere near enough for the overall 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 100%, so the schema already documents every parameter, making 3 the baseline. The product table does add meaning the schema lacks for productId (which is described only as "Default is V153") by mapping V153–V157 to Cloud VPS tiers and disk sizes. However the table is truncated mid-row, so it stops short of being a reliable reference.

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 names a specific verb and resource ("Create a new instance") and includes the exact endpoint POST /v1/compute/instances, plus account scoping ("for your account"). It is clearly distinguishable from siblings like retrieve_instance, patch_instance, or upgrade_instance, though it does not state those distinctions explicitly.

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 reinstall_instance, upgrade_instance, or create_object_storage, nor any stated prerequisites (e.g. that sshKeys/rootPassword reference pre-existing secretIds from Secrets Management). The embedded product table implies product selection but never says how to choose a product or what happens after 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 already state readOnly=false, openWorld=true, idempotent=false, and destructive=false. The description adds useful behavioral context beyond annotations: creation is a purchase that may incur cost, only one object storage per location is allowed, and space increases should use the resize endpoint rather than this 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 short and front-loaded with the core action and endpoint. The repeated "Create a new object storage" phrasing is slightly redundant, but the one-per-location note and resize path are relevant and efficiently stated.

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 create/purchase mutation with rich schema descriptions and annotations, the description covers the key agent-facing concerns: what it creates, that it is a purchase, the one-per-location limit, and where to go for resizing. It does not describe the response shape, but the schema and annotations carry enough support that this is a minor gap.

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 coverage is 100%, so the schema already documents all parameters in detail. The description lightly reinforces that region/location and purchased space matter, especially via the one-per-location rule, but it does not add syntax or constraints beyond what the schema 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 gives a specific verb and resource: "Create / purchase a new object storage." It also adds the important constraint that only one object storage can be bought per location, though it does not explicitly name sibling tools such as retrieve_object_storage or upgrade_object_storage for 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?

Usage is implied by "Create / purchase a new object storage in your account" and clarified by the one-per-location constraint. It also points to a resize endpoint for increasing space, but it does not explicitly compare this tool with alternatives like upgrade_object_storage or update_object_storage.

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, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the mutation profile is covered structurally. The description adds nothing beyond that: it does not say what happens on duplicate names, whether creation is asynchronous, what permissions are required, or what identifier is returned.

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 that restate the same fact: the title line ('Create a new Private Network') is repeated verbatim as the body sentence. Short and front-loaded, but redundant rather than efficient.

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?

There is no output schema, and the description never indicates what a successful call returns (e.g. the new network's ID or region) or whether the operation is immediate. For a creation tool with a nested request body and no output contract, the description leaves a real gap.

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 100%, including the nested body fields (name, region with an EU default, description), so the baseline is 3. The description contributes no additional parameter meaning whatsoever, so it cannot exceed the baseline.

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 names a specific verb ('Create') and resource ('Private Network') and even cites the REST endpoint POST /v1/private-networks, so an agent can distinguish it from siblings like retrieve_private_network or patch_private_network. It stops short of explicitly differentiating scope from other create_* tools, but the resource noun does that work implicitly.

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 never says when to use this versus alternatives (e.g. versus create_firewall or patch_private_network), nor does it state prerequisites such as required account permissions or quotas. The only usage context is 'in your account', which is not real 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 already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds the IPv6-only constraint, which is genuine behavioral value not present in the annotations, but it says nothing about failure behavior for IPv4 input, conflicts, or 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 opening clause and endpoint are front-loaded and useful, but the body is restated almost verbatim ('Create a new PTR Record using ip address' appears twice), wasting the one additional sentence slot that could have carried guidance or return-value context.

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 creation tool with no output schema, the definition covers what to send (via a fully described schema) and the key IPv6 restriction. It does not indicate what the call returns (the created record), whether creation is idempotent on retry, or how duplicate PTR entries are handled, leaving modest gaps.

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 100%, so ip, ptr, ttl and x-trace-id are all documented in the schema itself. The description only echoes the ip parameter ('using ip address') and adds no format, range, or relationship detail beyond what the schema provides; baseline 3 applies.

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 a specific verb and resource ('Create a new PTR Record') and gives the endpoint (POST /v1/dns/ptrs), which cleanly separates it from update_ptr_record, delete_ptr_record and retrieve_ptr_record. It does not explicitly name those siblings, but the create verb plus the IPv6 constraint makes the intent unambiguous.

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?

'Only IPv6 can be created' is a real eligibility rule that tells an agent when this tool applies, which is more than most create tools offer. However there is no explicit routing guidance versus alternatives such as create_dns_zone_record, and no mention of prerequisites or what to do when the address is IPv4.

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 a non-read-only, non-idempotent, open-world create operation. The description adds meaningful caveats: apiName/actions should come from the api-permissions endpoint, and resource tag ids only take effect after tag assignment.

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 and appropriately short for the tool. There is minor repetition of 'Create a new role' and a few typos, but no major structural issue.

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 richly described nested schema and clear annotations, the description covers the non-obvious permission and resource setup dependencies. It does not discuss response format or auth requirements, but the schema carries most of the remaining burden.

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 coverage is 100%, so the schema already documents parameters well. The description still adds value by pointing to the api-permissions endpoint for apiName/actions and clarifying that `resources` are tag ids with a tag-management dependency.

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 and resource: create a new role, with the HTTP endpoint. It distinguishes creation from sibling retrieval/update/delete role tools only by implication, not by naming alternatives.

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 explains prerequisites for filling permissions and resources, including consulting GET api-permissions and using tag ids that must be assigned in tag management. It does not explicitly state when not to use this tool or name sibling alternatives.

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 readOnly=false, idempotent=false, destructive=false and openWorld=true, so the safety profile is covered. The description adds the endpoint and the password/ssh type distinction, but says nothing about sensitivity of the stored value, whether it can be read back, required permissions, or that a repeat call creates a duplicate (non-idempotent).

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 short sentences, front-loaded with the action and endpoint. Slight redundancy: 'Create a new secret' is repeated verbatim as the opening of both sentences, and the title annotation duplicates it again.

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 mutation tool with a nested body object and no output schema, the description covers what is created but omits what the response contains and any note about the sensitivity or irreversibility of the stored secret. Adequate but with clear gaps for a credentials-related write operation.

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 100%, so the schema already documents name, type enum, and the value pattern rules. The description paraphrases the same fields ('attributes name, type and value... type can be password or ssh') without adding format or constraint detail beyond the schema, which is the baseline-3 case.

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?

States a specific verb and resource ('Create a new secret') plus the endpoint POST /v1/secrets, and names the three attributes it accepts. The create/retrieve/update/delete siblings are trivially distinguishable from the verb, though it never explicitly contrasts with them.

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 versus related tools in a large sibling set (generate_client_secret, reset_password, create_user) and no prerequisites or when-not conditions. The agent must infer usage entirely from the name.

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 disclose that this is a non-read-only, non-idempotent, non-destructive, open-world operation. The description adds the HTTP endpoint, which is useful context, but does not explain snapshot creation side effects, permissions, or response behavior beyond what annotations and schema 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 short and front-loads the core action and endpoint. The second sentence largely repeats the first and lists attributes already covered by the schema, so not every sentence adds new 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?

The schema and annotations are rich enough to support invocation, but the description is minimal for a mutation tool with no output schema. It does not clarify return behavior or any operational constraints around creating a snapshot.

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 100%, so the nested body, name, description, instanceId, and trace header are already well documented. The description only repeats that name and description attributes are used, adding no format or constraint details 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 a specific verb and resource: create a new instance snapshot. It also includes the POST endpoint, making the operation clear. However, it does not explicitly differentiate this tool from adjacent snapshot/image tools such as rollback_snapshot or create_custom_image.

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 explains what the tool does but gives no guidance on when to use it versus alternatives like rollback_snapshot, update_snapshot, or create_custom_image. There are also no stated 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 already declare non-readonly, openWorld, non-idempotent, and non-destructive behavior. The description adds the POST endpoint and account scope, but omits duplicate-name behavior, permission requirements, and rate limits, and it mislabels color as optional despite the schema requiring it.

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 short and front-loads the endpoint, with no extraneous detail. However, 'Create a new tag' is repeated in both sentences, which is a minor 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 simple create operation with full schema coverage and annotations covering safety, the description gives endpoint and account context. It still lacks duplicate/uniqueness semantics and misstates color optionality, so it is adequate but not complete.

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

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

Schema coverage is 100%, so the schema already documents name, color, description, and x-trace-id in detail. The description adds only a high-level mention of name and color and incorrectly calls color optional when the schema marks it required, which makes it less reliable than the baseline schema-only case.

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?

States a specific verb and resource ('Create a new tag') plus the POST endpoint, so the operation is unambiguous. It does not explicitly differentiate from siblings such as update_tag or delete_tag, but the creation verb itself distinguishes it.

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 update_tag, retrieve_tag, or retrieve_tag_list, and no prerequisites or alternatives are mentioned. Usage is only implied by the verb.

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, idempotentHint=false, destructiveHint=false, and openWorldHint=true. The description adds important security behavior beyond annotations: no password/secrets can be supplied, and the user must set secrets personally. It does not state required auth/role, but it adds substantive 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 front-loaded and compact, providing the endpoint and key constraints early. There is minor redundancy in repeating 'Create a new user' and a long required-attributes sentence, but it remains readable.

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 create mutation with a rich schema and annotations, it covers the important password/secret restriction. However, the required-attribute prose is misaligned with the schema by omitting locale and adding admin/accessAllResources, so an agent relying on the description could form an invalid request body.

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 coverage is 100%, so the baseline is 3, but the description's required-attribute list conflicts with the schema. It says admin and accessAllResources are required although they are absent from the schema, says roles is required although schema marks it optional, and omits the required locale field, making the prose misleading.

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 uses the explicit verb 'Create' with the resource 'user' and even includes the endpoint POST /v1/users. It clearly distinguishes this tool from sibling operations like retrieve_user, update_user, and delete_user.

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 implies use when provisioning a new user and gives a negative constraint: you cannot specify password/secrets. However, it does not explicitly compare with update_user or state prerequisites such as admin permissions, so guidance is only partial.

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 destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description still adds real behavioral context: the assignment is removed from the resource and, for access-restricting tags, affected users immediately lose access. It stops short of stating error behavior for a nonexistent assignment or whether the tag itself survives (it does, implicitly).

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 short sentences preceded by the endpoint, with the consequence front-loaded right after the core action. No filler, though the bracketed URI is partly redundant with the parameter set and costs a line.

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 delete with no output schema and full-schema parameter docs, the description supplies what structured fields cannot: the downstream access impact. Minor gaps remain — whether missing assignments error versus no-op, and confirmation that the tag record itself is untouched.

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 coverage is 100% and the resourceType enum values are documented in the schema, so the schema already carries the parameter burden. The description adds only the path template, which mirrors the same three required identifiers without new semantics; baseline 3 applies.

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?

States a specific verb (Delete) plus a precise resource (tag assignment) scoped to a tag/resource pair, and the endpoint template disambiguates it from siblings like delete_tag and create_assignment. An agent can tell exactly which object this removes without opening the schema.

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?

Usage is only implied by the verb — nothing states when to prefer this over delete_tag, or that retrieve_assignment_list should be used to find the resourceId first. No exclusions or prerequisites are given, though the sentence about access restrictions hints at when the call matters operationally.

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 declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds only the REST path and restates 'using zone name'; it says nothing about whether deleting a zone cascades to its records, whether that is recoverable, or what happens to dependent resources.

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

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

The description is short, but the purpose is stated twice ('Delete a DNS zone' / 'Delete a DNS Zone using zone name') and the second sentence adds nothing. It is front-loaded but contains redundancy rather than useful detail.

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 simple, single-parameter destructive operation with full annotation coverage and full schema coverage, the definition is minimally sufficient. It is nonetheless incomplete because it omits the consequences of deletion, particularly the fate of records within the zone and any dependencies.

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 100%, so the schema already documents zoneName and x-trace-id. The phrase 'using zone name' adds only marginal confirmation of the required identifier, and no syntax or format details 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 a clear verb and resource ('Delete a DNS zone') and the REST endpoint reinforces the target. It is distinguishable from sibling operations such as delete_dns_zone_record or retrieve_dns_zone, though it does not explicitly call out the difference.

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, no prerequisite checks (such as whether the zone must be empty), and no warning about confirmation or the effect on dependent records. The agent is left to infer everything beyond the operation name.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds only the HTTP path and a redundant restatement with a typo ('DNZ Zone'), without disclosing side effects, confirmation behavior, or DNS propagation implications.

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 definition is short and front-loaded, but the second sentence repeats the operation and contains a typo ('DNZ'), reducing precision. It is not verbose, but it also wastes the few words it has.

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 single-record delete, the description gives the endpoint but omits practical context such as whether the deletion is immediate, whether it returns anything, and how it differs from bulk deletion. Annotations and the complete input schema cover much of the safety and parameter burden, making this minimally adequate but not rich.

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 100%, so recordId, zoneName, and x-trace-id are already documented in the schema. The description adds no parameter semantics beyond that baseline, which is appropriate given complete 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 names a specific verb and resource ('Delete a DNS zone record') and includes the endpoint path, so the operation is unambiguous. It does not distinguish itself from the sibling bulk_delete_dns_zone_records or delete_dns_zone, which limits 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?

There is no explicit when-to-use guidance, no mention of alternatives such as bulk_delete_dns_zone_records for multiple records, and no stated prerequisites or exclusions. The operation name implies deletion, but the routing decision is left entirely to inference.

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 destructiveHint=true, idempotentHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is clear. The description adds meaningful behavioral context by disclosing the attached-instance precondition that can block 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 precondition is useful and front-loaded, but the description repeats 'Delete existing firewall by id' in both the first and second sentence. That duplication costs conciseness without adding 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 delete tool with full annotation coverage and full schema parameter descriptions, the definition is mostly complete: it names the operation, endpoint, required id, and blocking precondition. The main missing element is explicit remediation guidance when attached instances prevent deletion.

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 100%, so both parameters are already documented in the input schema. The description only reiterates that deletion is by id and does not add format or handling details beyond what the schema 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 states a specific verb and resource: delete an existing firewall by id. The HTTP endpoint reinforces the exact operation. An agent can distinguish this from create_firewall, retrieve_firewall, patch_firewall, and put_firewall without opening the schema.

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 gives one important precondition: a firewall cannot be deleted while instances are attached. However, it does not explicitly tell the agent what to do instead, such as unassigning instances first via unassign_instance_firewall, nor does it compare this tool against update alternatives.

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 declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds the DELETE endpoint and a vague statement that deletion is allowed at any time, but does not explain consequences such as whether the image is irrecoverable or whether in-use images can be deleted.

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 short and front-loads the core action and endpoint. The second sentence is somewhat awkward and contains a typo, but it does not significantly detract from an otherwise efficient structure.

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 simple destructive delete operation whose annotations already communicate destructiveness and idempotency, the description is mostly complete: it identifies the action, resource, identifier, and endpoint. It could add a note about irreversibility or constraints, but nothing critical is missing for an agent that also inspects the annotations and schema.

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 100%, so the schema already documents imageId and x-trace-id clearly. The description only adds the phrase 'by its id', which maps to the required imageId parameter but does not provide additional semantics 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 a specific verb and resource: delete an uploaded custom image by its id, and even includes the HTTP endpoint. It is clear what the tool does, but it does not explicitly differentiate this operation from sibling image tools such as retrieve_image or update_image.

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 only usage-like statement is that you are free to delete a previously uploaded image at any time, which is not guidance about when to use this tool versus alternatives. It does not mention preconditions, exclusions, or sibling tools, leaving the agent to infer usage entirely.

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 destructive=true, idempotent=true, and openWorld=true, so the safety profile is covered. The description adds important non-annotation context: deleting the network automatically unassigns all instances from it.

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 operation is front-loaded and appropriately short. There is mild redundancy in repeating 'Delete existing ... by id' for both Private Network and Virtual Private Cloud, but the second sentence contributes the key side effect.

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 delete tool with rich annotations and fully described parameters, this is mostly complete: it names the resource, id-based targeting, and the automatic instance unassignment. It could still mention prerequisites or irreversibility, but annotations cover much of that ground.

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 100%, and the schema already documents privateNetworkId and x-trace-id. The description only repeats that deletion is by id, adding no format, constraints, or parameter behavior 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 a specific verb and resource: delete a Private Network by id, and includes the underlying DELETE endpoint. It is clearly distinguishable from sibling retrieve/create/patch private-network 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?

It says to delete an existing Private Network by id but gives no explicit when-to-use guidance, no alternatives, and no prerequisites such as verifying the network before 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?

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so safety framing is covered. The description adds the non-obvious IPv6-only restriction, which is exactly the kind of behavioral constraint structured fields cannot express; it stops short of saying whether deletion is reversible or what happens to in-flight DNS resolution.

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 core statement is short, but the title sentence is duplicated verbatim and the HTTP route is inlined in brackets, adding tokens without new information. The genuinely useful constraint (IPv6 only) is buried at the end rather than 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?

With only two parameters, full schema coverage, and rich annotations, the definition covers what an agent needs to invoke it correctly; no output schema exists, so return values need not be explained. The main remaining gap is that it says nothing about error behavior or side effects on related DNS 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 coverage is 100%, so ipAddress and x-trace-id are already documented in the schema. The description confirms the operation keys on the IP address but adds no format, zone-scoping, or IPv6 literal syntax detail beyond that, so the baseline 3 applies.

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?

Names a specific verb and resource (delete a PTR record) plus the addressing key (ip address), which distinguishes it from retrieve_ptr_record/update_ptr_record. It does not explicitly separate itself from the other delete_* siblings such as delete_dns_zone_record, but the resource name is unambiguous.

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?

"Only IPv6 can be deleted" is a real precondition that tells the agent when this call will fail, which is more than most definitions offer. However, there is no explicit routing guidance against siblings (create_ptr_record, update_ptr_record, delete_dns_zone_record) and no stated 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 already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds the genuinely non-obvious failure mode — deletion is blocked by existing user assignments — which an agent could not infer from the schema. It stops short of saying whether deletion is permanent/irreversible or what happens on an unknown roleId.

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 short sentences: the operation and endpoint first, then the blocking condition. Nothing redundant and nothing buried.

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 with no output schema, the description supplies the key precondition and the remediation path, and the annotations carry the safety profile. A note on irreversibility or the response on a nonexistent role would make it fully complete.

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 coverage is 100%, so both roleId and x-trace-id are already documented in the schema. The description only restates 'by id' and echoes the path template; it adds no meaning beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb and resource ('Delete existing role') plus the exact REST endpoint, which pins down the operation unambiguously. Against a sibling list containing many other delete_* tools (delete_tag, delete_user, delete_secret), the resource noun 'role' is enough to select it without opening the schema.

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?

Explicitly names a when-not condition: the role cannot be deleted while still assigned to a user, and the description tells the agent what to do instead ('remove the role from the users'). It does not point at a specific sibling tool (e.g. update_user or retrieve_role_list) for performing that prerequisite step, so it falls short of full alternative routing.

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 declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is well covered externally. The description adds the endpoint and confirms the secret is removed from the account, but it does not add further behavioral context such as irreversibility, dependencies, authorization requirements, or response behavior.

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 short lines with the operation and endpoint front-loaded, and every part contributes to identifying the action. There is no unnecessary text.

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?

The description plus annotations and schema identify the resource, required identifier, destructive nature, idempotency, and endpoint. It is sufficient for invoking a simple delete, though it does not mention downstream impact or what the deletion call returns.

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 100%, and the secretId parameter is already documented in the schema as 'The id of the secret'. The description reinforces that the operation is by id and cites the path template, but does not add syntax, format, or validation details 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 a specific verb (Delete), resource (secret), and identifier (by id), and the endpoint reinforces the exact operation. It is clearly distinct from sibling secret tools such as retrieve_secret, create_secret, and update_secret.

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 by saying it removes a specific secret from the account, but it gives no explicit when-to-use guidance, no exclusions, and no alternative or prerequisite behavior. For a straightforward delete operation the implied use is adequate, but it does not actively route the agent among siblings.

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 destructiveHint=true, idempotentHint=true, readOnlyHint=false and openWorldHint=true, so the description's only remaining job is to add context, which it does not. It says nothing about whether the deletion is permanent, whether dependent snapshots/images are affected, or what the caller gets back. It repeats the title verbatim rather than supplementing it.

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 text is short but wastefully duplicated: 'Delete existing snapshot by id [DELETE /v1/...]' is immediately followed by 'Delete existing instance snapshot by id', which restates the same fact. The endpoint path is also already implied by the operation; the second sentence earns no 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?

With full schema coverage and rich annotations, the minimum is met, but for a destructive operation the description should mention permanence or consequences. An agent knows what to send but not what it is about to lose, which is the one gap annotations cannot close.

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 100%, with instanceId and snapshotId both documented inline, so the baseline applies. The description adds no format or constraint detail (e.g., that snapshotId is a string UUID or whether x-trace-id is optional), so it neither helps nor hurts.

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?

States a specific verb and resource ('Delete existing snapshot by id'), so an agent can tell it apart from update_snapshot, rollback_snapshot, or delete_image without reading the schema. It stops short of explicitly contrasting itself with the sibling that would be the closest wrong choice (rollback_snapshot).

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 at all on when to use this versus rollback_snapshot or update_snapshot, no prerequisites, and no warning about irreversibility beyond what the destructiveHint annotation already says. The only usage signal is the implicit 'delete = removal'.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds the operationally important constraint that deletion fails when the tag is still assigned — genuine context beyond the structured fields, though it doesn't say what error behavior or side effects to expect.

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 short sentences, with the endpoint and the blocking precondition front-loaded. Minor waste in repeating the title and a typo ('assigments'), but nothing padding or buried.

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 simple two-parameter delete with no output schema, the definition covers what an agent needs: the target, the mutation, and the precondition that gates success. Only the exact failure mode when the tag is assigned is left implicit.

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 coverage is 100% and tagId is documented as 'The identifier of the tag'. The description only restates 'by id', adding no format, range, or acquisition guidance beyond the schema. Baseline 3 applies.

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?

States a specific verb and resource ('Delete existing tag by id') plus the underlying endpoint, so an agent can tell it apart from retrieve_tag, update_tag, and delete_assignment without opening the schema. It stops short of explicitly contrasting with the nearest sibling, delete_assignment.

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?

Gives a concrete precondition for use: the tag can only be deleted if it is not assigned to any resource, and it advises checking tag assignments first. It does not name the sibling tool (retrieve_assignment_list) that performs that check, leaving the agent to infer the next call.

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 destructiveHint=true and idempotentHint=true, so safety is covered. The description adds the actual blast radius — the user loses access to every endpoint and resource — which is real consequence detail beyond the boolean flags, though it says nothing about recovery, cascade effects on owned resources, or auth requirements.

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?

Front-loaded with the action and endpoint, then the consequence, then the alternative — good ordering with no filler. Minor deduction for the slightly awkward phrasing ('By deleting a user he will...') and mild redundancy about access loss.

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 two-parameter destructive tool with full annotations and no output schema, the description covers action, consequence, and the safer alternative. What remains unstated — irreversibility, dependent-resource handling, permission requirements — is a modest gap for a destructive operation but not a blocking one.

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 100% and both parameters are documented in the schema, including the trace header. The description only implies the userId comes from the path template; it adds no format or constraint detail, so the baseline 3 applies.

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?

States a specific verb and resource ('Delete existing user by id') plus the concrete endpoint, and distinguishes it from the sibling update_user by pointing at the 'enabled' attribute for the non-destructive path. An agent can tell this apart from update_user or delete_role without opening a schema.

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?

Explicitly splits the decision: use this for removal, use the enabled attribute to temporarily disable. That is an explicit when-to-use versus when-to-use-something-else statement, which is the highest bar for this dimension.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), which lowers the bar. However, the critical behavior for a secret-rotation tool is not disclosed: whether the existing client secret is invalidated by this call, whether the new secret is returned in the response, and what the idempotentHint=true actually means here (does a repeat call return the same secret?). The description only repeats the HTTP verb and path.

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?

Very short, which is good, but 'Generate new client secret' followed by 'Generate and get new client secret' is pure duplication. The verbatim reiteration spends a whole second sentence on zero new 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 mutation tool with no output schema, the description should say what comes back (the new secret) and what happens to the old one; neither is covered. Annotations carry the safety profile, but the core effect of the call is left unexplained.

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?

There is a single optional parameter (x-trace-id) with 100% schema description coverage, so the schema fully documents it and the description adds nothing on parameters. Baseline 3 applies.

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 verb 'generate' plus resource 'client secret' is specific, and the endpoint PUT /v1/users/client/secret pins down the scope to the current user's client. But the second sentence merely restates the first, and nothing distinguishes this from neighbours such as create_secret, retrieve_secret, generate_sso_token or regenerate_object_storage_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?

There is no when-to-use guidance, no mention of what condition warrants rotating a client secret, and no pointer to any alternative tool. The agent must infer everything from the name alone.

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

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

Annotations already declare readOnly=false, idempotent=false, and openWorld=true, so the agent knows this is a non-repeatable write-like action. The description adds the genuinely useful behavioral fact that the token is 'one time' (single-use), but says nothing about expiry, scopes, or whether prior tokens are invalidated — the details that would actually change how an agent sequences calls.

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 short but not tight: the bracketed HTTP path plus a second sentence that restates the first ('Generate one time SSO token' / 'Generate an one time SSO token...'). The duplicate phrasing and the 'an one time' grammar cost it a point without adding meaning.

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?

With no output schema, the description should say what comes back — a token string, its lifetime, and how it is consumed. It delivers only 'one time' and leaves the return value and expiry undocumented, which is a real gap for a token-issuing tool, though the low parameter count keeps the overall risk moderate.

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?

Only one optional parameter (x-trace-id) exists and the schema documents it at 100% coverage, so the description has little room to add value. It offers no parameter guidance of its own; baseline 3 applies when the schema carries the burden.

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?

Uses a specific verb+resource ('Generate one time SSO token') and scopes it to 'the authenticated user account', which tells an agent what it produces and for whom. It does not, however, distinguish itself from nearby siblings like generate_client_secret or get_auth_code, so an agent must infer which credential-minting tool to pick.

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 phrase 'for the authenticated user account' implies the context of use (an already-authenticated session), but there is no explicit when-to-use, when-not-to-use, or alternative named among the many sibling token/secret tools. Usage must be inferred rather than read.

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 declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the agent knows this is a non-idempotent, externally-visible write-like operation. The description, however, uses the word 'get', which reads as a safe read and obscures that a POST actually generates a new transfer authorization credential (with implications such as invalidating prior codes and code expiry). There is partial friction with the annotations, but the endpoint notation saves it from being a direct contradiction.

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?

Short and front-loaded, which is good, but the second sentence is pure redundancy ('Get auth code for a domain by id' repeats the first). The only new information is the HTTP path in brackets.

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?

No output schema exists, so the description should say what comes back (an EPP/transfer auth code string), whether the code expires, and that it is a sensitive credential. None of that is present, leaving an agent calling a credential-generating endpoint with no knowledge of the result or consequences.

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 coverage is 100%, so both parameters (domain, x-trace-id) are already documented in the schema. The description adds nothing about the domain argument beyond the schema, and 'by id' is mildly misleading about the expected identifier form, but the baseline of 3 applies since the schema carries the burden.

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 verb+resource (get domain auth code) is stated, and the bracketed POST path hints at the underlying behavior. But the second sentence merely restates the first, and 'by id' is inaccurate since the required parameter is a domain name string, not an id. Nothing distinguishes it from the large set of domain-related siblings such as retrieve_domain or update_domain.

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 indication of when to call this versus the many sibling domain tools, no prerequisites (e.g. domain must be owned/registered by the caller), and no note about when a new code is needed versus reusing one. The agent must infer usage entirely.

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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is clear. The description adds the GET endpoint path and single-entity scope, but does not add auth, error, or rate-limit context beyond the annotations.

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

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

The description is very short and front-loads the operation and endpoint. There is minor redundancy between 'Get check' and 'Get a single check by id', but nothing bloated.

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 simple read-only retrieval tool with complete schema coverage and rich annotations, the description provides enough to select and invoke it correctly. It does not describe the return shape, but the operation is straightforward and no output schema is provided.

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 100%, so checkId and x-trace-id are already documented in the schema. The description only reinforces that retrieval is by id and adds no additional parameter 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 states a specific verb and resource: get a single check by id, and includes the HTTP endpoint. It implies retrieval of one entity versus listing, but it does not explicitly name the sibling list_ext_checks as the alternative.

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 phrase 'by id' implies this tool should be used when a specific checkId is known, but there is no explicit when-to-use guidance or comparison to list_ext_checks. Usage is inferable but not spelled out.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the endpoint path and single-id scope, but does not add auth requirements, rate limits, or return behavior.

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 short and front-loaded with the operation and endpoint. It has minor redundancy between 'Get check collection' and 'Get a single check collection by id', but nothing materially wasteful.

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 simple read-by-id tool with full schema description coverage and rich annotations, the description is largely complete. It omits return-value details, but this is minor given the straightforward GET-by-id operation.

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 100%, so checkCollectionId, excludeCheckStatuses, and x-trace-id are already documented in the schema. The description only references checkCollectionId indirectly through the path and does not add 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?

States a specific verb and resource ('Get check collection') and clarifies scope with 'single ... by id', plus the HTTP path. It does not explicitly name list_ext_check_collections as the alternative, but 'single ... by id' sufficiently distinguishes the 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?

Provides no guidance on when to use this tool versus list_ext_check_collections, get_ext_check_collection_template, or get_ext_check. The agent must infer usage from the name and path 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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered elsewhere. The description adds only the REST path, with no information on error behavior for missing ids, auth requirements, or what the template contains.

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 short lines with the purpose front-loaded and nothing extraneous. The bracketed URL and the restated title 'Get check' duplicate what the name and endpoint already convey, but the waste is minimal.

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 simple single-parameter read this is largely adequate, and annotations cover the safety profile. However, with no output schema present, the description says nothing about what a template object contains or how a not-found id is handled, leaving a modest gap.

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 100% — both checkCollectionTemplateId ('Check collection template's id') and x-trace-id are documented in the schema. The description adds no format, range, or sourcing guidance beyond what the schema already provides, so the baseline 3 applies.

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?

States a specific verb ('Get') and resource ('a single check collection template by id'), which clearly separates it from the sibling list_ext_check_collection_templates bulk lister. It does not explicitly name the sibling, so it falls short of a 5.

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

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

The phrase 'by id' implies the tool is for fetching one known template, which indirectly distinguishes it from the list variant, but there is no explicit when-to-use/when-not guidance or mention of the alternative tool for discovering ids.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the raw endpoint path and repeats the title, offering no extra behavioral context such as error behavior for an unknown id or whether a missing remedy errors versus returns empty.

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 short lines, front-loaded with the action and scope, with no filler sentences. The bracketed HTTP path is mostly redundant with the tool contract but costs little.

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 simple single-resource read with a fully described schema and read-only annotations, the essentials are present. It is still thin on output expectations (no output schema exists) and never defines what a remedy is in this troubleshooting domain.

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 100%, so 'remedyId' and 'x-trace-id' are already documented in the schema. The description's 'by id' merely restates the required parameter, so baseline 3 applies.

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?

States a specific verb ('Get') and resource ('remedy') scoped to a single item by id, which distinguishes it from the sibling list_ext_remedies. It does not, however, distinguish it from get_ext_check or clarify what a 'remedy' object is relative to the other troubleshooting 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?

There is no guidance on when to call this versus list_ext_remedies, get_ext_check, or start_ext_remedy, nor any prerequisite such as needing an existing remedy id. The agent must infer the fit from the get/list naming pattern 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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that the result is meant for S3-compatible tooling, hinting the response contains usable secret material, but it does not state sensitivity (secret key exposure), permission requirements, or whether retrieval is audited — meaningful gaps for a credentials-fetching 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?

Short overall and the endpoint template is front-loaded usefully, but the second sentence largely restates the first ('Get S3 compatible object storage credentials' repeated) with only the aws-cli detail as new information. Minor 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?

With no output schema, the description should hint at what a credential object contains (access key, secret key, endpoints) so the agent knows what to expect. Annotations cover safety and the schema covers inputs, but return-value shape is left unexplained.

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 100%, so all four parameters are documented. The URL template [GET /v1/users/{userId}/object-storages/{objectStorageId}/credentials/{credentialId}] adds the useful detail that the three IDs form a hierarchical path, but nothing beyond that about parameter 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?

States a specific verb and resource (get S3 compatible object storage credentials) and the endpoint template shows it fetches a single credential by ID, implicitly distinguishing it from list_object_storage_credentials. It does not explicitly name the sibling, but the resource and scope are unambiguous.

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 clause 'for accessing it via S3 compatible tools like `aws` cli' implies the intended purpose of retrieving credentials, which is mild usage guidance. There is no explicit when-to-use versus list_object_storage_credentials or regenerate_object_storage_credentials, and no stated 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 already declare the mutation/safety profile, and the description adds substantive behavior: a Linux rescue system boots instead of the OS, the disk is mounted for repair, and a subsequent reboot returns to normal boot. It omits prerequisites (must the instance be running?) and how long rescue mode persists, but it goes well beyond the annotation coverage.

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

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

Front-loaded with the verb/resource/endpoint, then a single explanatory paragraph that earns its place by defining rescue mode. Mildly verbose and contains a typo ('sytstem'), but no filler sentences.

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 3-parameter mutation with a nested body, no output schema, and full schema descriptions, the definition covers what the operation does and its effect on the instance. Missing only ancillary details like permission requirements and preconditions.

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 coverage is 100% and each of sshKeys, userData, rootPassword and instanceId is documented in the schema itself; the description only restates the instance identifier and adds no extra meaning to the body parameters, so baseline 3 applies.

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?

States a specific verb and resource ('Rescue a compute instance / resource identified by its id') plus the underlying endpoint, and the second sentence explains what rescue mode actually is, so an agent can distinguish it from sibling operations like instance_restart or reinstall_instance.

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 gives a clear use scenario ('reboot your instance in rescue mode to resolve system issues') and describes the recovery workflow, but never explicitly contrasts with alternatives such as reinstall_instance or snapshot rollback, so routing is implied rather than stated.

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, destructiveHint=false, idempotentHint=false, so the safety profile is covered. The description adds useful effect context — the current password is replaced by the value supplied in the request body — but omits side effects, permission requirements, and the fact that the instance may need a restart; it also says "the password that you provided in the body" while the body actually takes a `secretId` reference, which is misleading.

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 opening line duplicates the title/endpoint, and the second sentence then restates the same purpose before adding the one new fact (the password is replaced). Front-loading is fine, but the redundancy costs a sentence that earns nothing.

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 non-idempotent mutation with a nested body and no output schema, the description covers the basic effect but omits what the caller should expect afterwards (restart requirement, timing), permission/authentication needs, and the surprising presence of SSH key and cloud-init fields in a "reset password" call.

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 100%, so all three parameters are documented in the schema and the baseline is 3. The description adds nothing about `instanceId` or the nested body fields, and notably does not explain that `sshKeys`/`userData` are also accepted alongside the password reset.

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?

States a specific verb and resource ("Reset password for a compute instance / resource referenced by an id") and includes the REST endpoint, so the agent knows exactly which operation this is. It does not, however, differentiate itself from the sibling tool `reset_password` (which appears to target user accounts), leaving a real name-collision ambiguity unresolved.

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 contains no when-to-use/when-not guidance, no prerequisites (e.g. required instance state, whether a reboot is needed), and no mention of the similarly named sibling `reset_password` that an agent could easily pick by mistake. Usage is only inferable from the verb itself.

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, idempotentHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the HTTP POST endpoint path, which is useful context not present in annotations, but it does not disclose disruption/downtime behavior or any permission requirements.

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 endpoint path is front-loaded and useful, but the second sentence ('To restart ... you should perform a restart action on it') is a tautology that repeats the first sentence without adding information. The description would be stronger if the redundant sentence were replaced with usage or behavioral context.

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 simple two-parameter action tool with complete schema coverage and annotations covering safety, the description is minimally adequate. It omits what an agent likely needs to choose correctly among many instance action siblings: expected disruption, when restart is appropriate versus stop/start, and any prerequisites.

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 100%, so both parameters are fully documented in the schema. The description says only that the instance is identified by its id, adding no syntax, format, or edge-case meaning beyond what the schema already provides, so the baseline 3 applies.

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 first sentence names a specific verb (restart) and resource (compute instance), which distinguishes it from siblings such as instance_stop, instance_shutdown, and instance_start. However, the phrase 'compute instance / resource' introduces ambiguity, and the description never explicitly contrasts itself with those action siblings.

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 choose restart versus stopping and starting, shutting down, or using rescue mode. No prerequisites, cautions, or exclusion conditions are stated.

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?

Goes beyond the annotations by explaining the mechanism: an ACPI event is sent for the guest OS to perform a clean shutdown, which tells the agent this is graceful rather than an immediate power cut. It omits whether the call is asynchronous, what happens if the guest ignores ACPI, or what is returned.

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 compact sentences, front-loaded with the action and identifier, then the behavioral explanation. The only flaw is a minor restatement of the tool name in the second 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?

Adequate for a simple single-parameter mutation with no output schema, but it leaves out async/completion semantics and any contrast with instance_stop or instance_restart, which are the main decision points 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 coverage is 100%, so both parameters are already documented; the description only restates 'by its id'. Baseline 3 applies since the schema does the heavy lifting.

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

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

States a specific verb+resource ('Shutdown compute instance / resource by its id') and includes the endpoint. However, it never distinguishes itself from the close sibling instance_stop, which an agent must choose between.

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 power-button analogy and 'ACPI event ... clean shutdown' imply graceful shutdown, hinting at when this is preferable to a hard stop, but no alternative is named and no exclusion condition is given. Usage is inferred rather than stated.

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 says that if the instance is already started, nothing will happen, which implies idempotent behavior on repeated start calls. This conflicts with the annotation idempotentHint=false, creating contradictory expectations for the agent.

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

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

The description is short and front-loads the action and endpoint, followed by useful behavioral notes. It is slightly repetitive with 'compute instance / resource' and includes the endpoint path inline, but there is no major 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 simple start action with complete schema coverage and annotations covering safety traits, the description covers the main behavior and status-check guidance. However, it does not state what a successful response contains, and the idempotency contradiction leaves the behavioral contract unclear.

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 100%, so the parameter meaning is already provided by the schema. The description only restates that the instance is identified by id and adds no syntax, constraints, or format details 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 uses a specific verb and resource: start a compute instance/resource identified by id. It also includes the concrete endpoint, leaving no ambiguity about the 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?

It explains the power-on use case and says an already-started instance results in no action, and it points to retrieving instance information to check status. It does not explicitly distinguish when to use instance_restart, instance_stop, or instance_shutdown instead.

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?

With annotations present, the description still adds real value: it warns that data may be lost (a risk not conveyed by destructiveHint=false), explains that stopping an already-stopped instance is a no-op, and points at status-checking afterwards. There is mild tension with idempotentHint=false and destructiveHint=false, but the warnings are additive context rather than a flat contradiction.

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?

Front-loaded with verb, resource, and endpoint, which is good, but the repeated 'compute instance / resource' phrasing bloats every sentence and the graceful-shutdown advice is verbose. The essential warning about data loss could be stated in far fewer 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 mutation tool with no output schema, the description covers the important unknowns: data-loss risk, no-op behavior when already stopped, and how to verify state afterwards. It omits permissions/auth requirements and whether the call returns immediately or is asynchronous, which are the remaining gaps.

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 coverage is 100%, so the baseline is 3. The description usefully says the id identifies the instance to stop, which implicitly corrects the schema's copy-paste error ('to be started in rescue mode'), but it adds nothing about x-trace-id or any id format expectations.

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?

States a specific verb and resource ('Stop compute instance / resource by its id') plus the concrete endpoint, so the agent knows exactly what operation is performed. It does not explicitly name the closely related sibling instance_shutdown, which is the tool an agent would most likely confuse this with; the graceful alternative is described generically ('via the operating system') rather than as a sibling tool.

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?

Gives clear context for when this hard power-off is appropriate and points to a gentler alternative (logging in and shutting down via the OS). It also states the already-stopped no-op case and suggests checking status via a retrieve call. It stops short of naming the sibling tools (instance_shutdown, instance_restart) that would make the choice unambiguous.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety is fully covered elsewhere. The description adds only the raw path GET /v1/domains and reveals nothing about pagination defaults, result ordering, or how multiple filters combine — no behavioral value beyond the annotations.

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

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

Two short lines with the verb-and-resource front-loaded; nothing is wasted. The bracketed endpoint path is slightly redundant with the tool name but is compact.

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?

With 8 optional parameters, full schema coverage and annotations present, the description is technically sufficient to call the tool. However it says nothing about how the filters interact or how paginated results are returned, which an agent listing domains would likely want.

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 100%, so all 8 parameters including the status enum and orderBy format are already fully documented in the schema. The description adds no parameter meaning of its own, making the baseline 3 appropriate.

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?

States a specific verb (list) and resource (domains) with a clear scope ('all your domains'), and the endpoint notation confirms a collection read. It does not explicitly distinguish itself from the sibling retrieve_domain, though the word 'all' implies the 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 phrase 'List and filter all your domains' implies the use case — bulk enumeration with optional filters — but there is no explicit statement of when to use this versus retrieve_domain for a single domain or list_pending_actions. Guidance is inferable rather than stated.

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, idempotentHint and destructiveHint=false, so the safety profile is fully covered structurally. The description adds only that results can be filtered broadly, and says nothing about pagination behavior, default page size, or what a returned check collection contains.

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?

It is short and front-loaded, but the three elements (title, endpoint path, sentence) restate each other; "List check collections" and "List and filter all check collections" are near-duplicates, and the bracketed GET path duplicates what the annotations already imply.

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?

With 12 optional parameters and no output schema, the definition is minimally sufficient for calling the tool but does not describe the shape of a check collection, its statuses, or pagination semantics, leaving an agent to infer return content entirely.

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 100% across all 12 parameters, including the orderBy format string and enum values, so the schema carries the semantic load. The description contributes no parameter meaning beyond the word "filter," which matches the baseline for fully documented schemas.

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?

States a specific verb and resource (list check collections) and adds the filtering capability, which is enough to separate it from the singular `get_ext_check_collection` and from `list_ext_check_collection_templates`. It never explicitly names those siblings, so differentiation is implied by the noun alone rather than stated.

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?

"List and filter all check collections" implies the browse/filter use case but gives no when-to-use versus get_ext_check_collection (single fetch) or the template-list variant, and no exclusions or preconditions. Usage is inferable but not guided.

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, idempotentHint and destructiveHint=false, so safety is covered. The description adds only the bare hint that filtering is supported; it says nothing about pagination behavior, default page size, sort defaults, or what a result set contains, so it barely exceeds what the structured fields 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?

Two short lines with the resource front-loaded and no filler prose. Slight redundancy: the title, the first phrase, and the second sentence all restate the same resource name.

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?

Annotations and a fully documented schema make the tool callable, and no output schema exists so return-value detail isn't mandatory. Still, a list-and-filter tool with 9 optional parameters would benefit from stating that results are a paginated collection of templates and how filtering by objectType/time ranges scopes them.

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 100% across all 9 parameters, including page/size/orderBy and the creation/modification time ranges, so the schema carries the semantics. The description adds no parameter-level meaning beyond the word "filter".

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?

States a specific verb and resource (list check collection templates) and repeats it in slightly expanded form with filtering. An agent can distinguish it from list_ext_check_collections and get_ext_check_collection_template by the name/description alone, though the description never makes that distinction explicit.

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?

"List and filter all check collection templates" implies the tool is for browsing filtered template catalogs, but there is no statement of when to use it instead of get_ext_check_collection_template or list_ext_check_collections, and no 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 already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds only the HTTP method/path; it says nothing about pagination behavior, default page size, or whether unfiltered calls return everything.

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?

Very short, but wasteful: 'List check' and 'List and filter all check' restate each other, and the phrase is ungrammatical. The endpoint breadcrumb is useful and front-loaded, but the payload beyond it is near-zero.

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 13-parameter list tool with no output schema, the description gives no sense of what a 'check' is, what result fields come back, or how paging/ordering interact. The complete schema descriptions carry almost the entire burden here.

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 100%, so all 13 parameters (including enums for status and objectType, and the orderBy format) are already documented in the schema. The description adds no parameter meaning beyond the word 'filter', so baseline 3 applies.

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 a verb+resource (list checks, with filtering) and includes the endpoint GET /v1/troubleshooting/checks, which confirms a read operation. However, 'check' is never defined, and nothing distinguishes this from sibling get_ext_check or list_ext_check_collections beyond the plural 'all'.

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 when-to-use or when-not-to-use guidance. The agent is left to infer that this is the bulk enumeration tool versus get_ext_check (single check) and list_ext_check_collections (collections) purely from the names.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds nothing beyond them — no mention of default page size, whether results are sorted, or what a 'remedy' object contains. With a lower bar due to annotations, this still falls short of adding any 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?

It is very short, but not efficiently so: the endpoint line and 'List and filter all remedy' are redundant with each other and the latter is ungrammatical. There is no information beyond the minimum, so brevity here reflects under-specification rather than tight writing.

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 13-parameter read-only listing tool with no output schema, the description should at least explain what a remedy is, how filters interact, and what a default call returns. None of that is present, leaving the agent to infer everything from parameter names.

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 100% across all 13 parameters, so the schema carries full semantics for pagination, status enum, ordering format, and time ranges. The description adds no parameter meaning (e.g., default page/size, whether filters combine with AND), so baseline 3 applies.

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 a verb+resource ('List ... all remedy') and even names the HTTP endpoint, so the purpose is identifiable. However, it never distinguishes this list operation from siblings like get_ext_remedy, start_ext_remedy, or cancel_ext_remedy, and the phrasing 'List and filter all remedy' is a near-restatement of the name.

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 implies the tool is a filtered listing but gives no guidance on when to use it versus get_ext_remedy (fetch one) or start_ext_remedy/cancel_ext_remedy (actions). No prerequisites, pagination expectations, or scoping notes are provided.

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