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

Annotations cover the safety profile (destructive, non-idempotent, open-world) but the description adds substantial behavioral context beyond them: billing responsibility, backup-limit consumption, required permission level, and the specific 422 failure reasons. It also discloses the return payload.

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-loads the action and its consequence, then permissions, then error cases. Every sentence carries information, though the 422 enumeration makes it slightly dense.

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?

Covers action, side effects, permissions, failure modes, and even the return value despite there being no output schema. For a 2-parameter mutation tool, nothing an agent needs to call it correctly is missing.

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 cross-referencing list_backup_shares for shareId and the KROVA_SPACE_ID default for spaceId. The description adds no parameter-level 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?

States a specific verb+resource action ('accept a backup share') and immediately clarifies the side effect (the space gets its own copy). It is clearly distinguishable from the sibling decline_backup_share and cancel_backup_share.

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 explicit preconditions ('confirm with the user first'), authorization rules (owner or Manage Backups), and refusal conditions. It does not explicitly name the sibling alternatives (decline/cancel) as the when-not path, so it falls just short of a 5.

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

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

Annotations already declare it is a non-read-only, non-destructive, non-idempotent, open-world operation, so the safety profile is covered. The description adds real value beyond that by stating the authorization model (owner, Manage Backups member, or the originating member). It stops short of describing the effect on state or error 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?

Two tight sentences with zero waste; the operational condition is front-loaded and the permissions follow. Nothing redundant.

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

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

With no output schema and only one required parameter, the description covers the essential context: what it acts on, its timing constraint, and who may call it. Return values need not be explained. It is close to complete, missing only expected outcome/error semantics.

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% — shareId and spaceId are fully documented, including the KROVA_SPACE_ID default fallback. The description adds no parameter-level detail 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 (withdraw/cancel) and resource (a pending backup share this space offered), plus the temporal scope (before the destination answers). This clearly distinguishes it from the sibling accept/decline_backup_share, which operate on the recipient side.

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 the condition under which it applies (a pending share, before the destination responds) and lists who may invoke it. It does not explicitly name or contrast with sibling tools, but the 'this space offered' phrasing implicitly routes the agent away from decline/accept.

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 goes beyond the annotations by disclosing that provisioning is asynchronous and the Cube starts in a pending state, and that it begins hourly billing. These are valuable behavioral details not captured in the annotations, and they align with destructiveHint=true.

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

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

The description is two sentences with zero fluff. It front-loads the core purpose, then packs essential behavioral and cost warnings into the second sentence. Every clause earns its place.

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

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

With no output schema, the description explains the asynchronous return state, addressing the outcome. It also flags billable side effects. It doesn't discuss permissions or how to monitor pending progress, but combined with schema and annotations it is sufficiently complete 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 all 10 parameters thoroughly. The description adds no parameter-specific meaning, 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 clearly states 'Create (provision) a new Cube in a Space' with a specific verb and resource, making the tool's purpose unambiguous. It is obviously distinct from sibling tools like delete_cube or create_snapshot, even without naming 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?

The description implies usage by defining what the tool does and adds relevant context about asynchronous provisioning and billing, but it does not explicitly compare with alternatives or state when not to use it. This is adequate but not explicit 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 only declare the generic profile (not read-only, not destructive, not idempotent, open-world), yet the description adds the operationally critical behavior: the call returns the domain plus required DNS records, the domain is non-functional until those records exist, record counts differ for subdomains vs wildcards, and grey-cloud is mandatory on Cloudflare or certificate issuance fails. That is exactly the kind of consequence-level detail annotations cannot convey.

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

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

Purpose is front-loaded in the first clause, followed by return-value notes and then the failure modes, which is a sensible order. It is dense and every sentence carries information, though the Cloudflare/certificate sentence could be tightened slightly.

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 explicitly covers what is returned (domain plus DNS records) and what the agent must do with it. For a 7-parameter mutation with a 409 edge case already documented in the schema, this is complete enough to call correctly.

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

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

Schema coverage is 100% and the schema itself thoroughly documents port, originScheme, proxyProtocol, and confirmMixedProxyProtocol, so the description does not need to compensate. It adds only indirect color (port routing, record implications) and never clarifies any individual parameter beyond what the schema states, 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?

"Attach a custom domain to a Cube, routing it to an in-Cube port" gives a specific verb (attach), resource (custom domain), and target (in-Cube port), which distinguishes it cleanly from siblings like update_domain, list_domains, and create_tcp_mapping. An agent can pick this over the alternatives 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 strong post-call guidance (relay the DNS records verbatim, CNAME vs three records for wildcards, grey-cloud requirement) but never states when to choose this over update_domain or delete_domain, nor any prerequisites for calling it. Usage context is implied by the verb but no explicit alternatives or exclusions are named.

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-read-only, non-idempotent, non-destructive, open-world behavior. The description adds genuinely new operational context: the operation is asynchronous and the snapshot is enqueued, so the agent knows the call returns before the snapshot exists. It stops short of saying how to observe completion or whether duplicate calls enqueue multiple snapshots.

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, front-loaded sentences with no filler. The async clause is slightly redundant in phrasing ('Asynchronous — the snapshot is enqueued') but the emphasis is useful rather than 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 three-parameter create tool with full schema coverage and annotations covering the safety profile, the definition is nearly complete. The main gap is what the caller should do after enqueueing, such as polling list_snapshots, which would help an agent complete the workflow.

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 cubeId, name, and spaceId are already documented, including the KROVA_SPACE_ID default. The description adds no parameter-level meaning beyond confirming the snapshot targets the cube's disk; 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 snapshot of a Cube's disk'), which separates it cleanly from list_snapshots, delete_snapshot, and restore_cube. It doesn't explicitly name those siblings as alternatives, but the action 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?

Usage is implied by the create semantics, and the async note hints that the caller must not expect an immediate snapshot. However, there is no explicit when-to-use guidance (e.g., before restore_cube, or in place of a backup) and no pointer to list_snapshots for tracking progress.

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 this is a non-read-only, non-destructive, non-idempotent, open-world operation, so the safety profile is covered. The description adds that the exposure happens on the host and can be IP-restricted, but omits that UDP forwarding is on by default, whether repeated calls create duplicate mappings, and what is returned. Given annotation coverage, this is an adequate but thin addition.

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?

A single front-loaded sentence with no filler or repetition. It is efficient, though so terse that no room is used for the operational caveats a create-exposure tool warrants.

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 network-exposure tool with no output schema, the definition covers the core action and the whitelist option but leaves out the spaceId default behavior, UDP-on-by-default consequence, and failure modes. Rich schema and annotations carry much of the load, making it minimally sufficient rather than 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 all six parameters including the deprecated whitelistIps alias and the udpEnabled default are already documented in the schema. The description's 'optionally restricted to specific IPs/CIDRs' only restates whitelistedIps. 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 ('Expose a Cube TCP port on the host') plus the scope qualifier 'optionally restricted to specific IPs/CIDRs'. It is unambiguous what the tool creates, though it never names the sibling it complements (list_tcp_mappings / delete_tcp_mapping) or contrasts itself 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 when-to-use guidance: no mention of prerequisites (a running Cube, a spaceId or KROVA_SPACE_ID default), no note about host-port conflicts or what happens if the mapping already exists, and no routing to list_tcp_mappings to check existing mappings first. The only usage hint is embedded in the phrase 'optionally restricted'.

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 establish the safety profile (not readOnly, not idempotent, not destructive, openWorld), and the description adds genuinely new operational context that annotations cannot: the signing secret appears only in this response and must be persisted immediately. That is exactly the kind of one-shot-secret warning an agent needs. It misses a note on duplicate-endpoint behavior, 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?

Three short sentences with no filler, and the most consequential fact (secret returned once, persist now) is placed where it will be read. Nothing is redundant with the schema or annotations.

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 covers the one return value that matters for correct handling – the signing secret. It does not mention other returned fields such as the new webhook's id, which an agent would need for follow-up calls like get_webhook. For a simple 4-parameter create tool this is nearly 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%, with url, events, spaceId, and description all documented in the schema including HTTPS and 400-on-invalid-event behavior. The description adds only the phrase "one or more events," which the schema's array type already conveys. Baseline 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?

States a specific verb and resource ("Create a webhook endpoint") plus the subscription scope ("subscribe it to one or more events"), which clearly separates it from list_webhooks, get_webhook, and delete_webhook. It does not name any sibling explicitly, so it stops 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?

Usage is only implied by the verb – an agent can infer this is for registering a new endpoint, and the sibling list makes the alternatives obvious. There is no explicit when-to-use, no prerequisites (e.g. required permissions or space scoping rules), and no note on what to do if an endpoint for the same URL already exists.

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 (mutating, non-destructive, non-idempotent, open-world). The description adds valuable behavioral facts beyond that: nothing is copied or billed, and it requires the same permission as accept_backup_share. It doesn't state the resulting state of the share, but the added context is meaningful.

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?

Three short sentences, front-loaded with the action, then the key side effect (no copy/billing), then permission. No waste; every sentence earns its place.

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

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

For a simple two-parameter mutation with full schema coverage and annotations, the description covers what the tool does, what it does not do (copy/bill), and permission requirements. The only minor gap is what happens to the share record after declining, but this is not essential 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 shareId and spaceId are fully documented in the schema. The description adds no parameter-level information, which is acceptable given the complete schema (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?

Clear verb + resource ('Decline a backup') and scope clarification ('another space shared with this one') specify this is the recipient declining an incoming share. It names sibling accept_backup_share for permission context, though it doesn't explicitly distinguish from cancel_backup_share.

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 the action itself (declining a share you don't want), but there is no explicit when-to-use versus accept_backup_share or cancel_backup_share. The mention of accept_backup_share is for permission equivalence, not usage 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 description discloses asynchronous behavior (deletion is enqueued), irreversibility, and disk teardown, going well beyond the destructiveHint annotation. It also adds a critical safety constraint about user consent that is absent from structured fields.

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

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

Two sentences deliver key behavioral traits up front (asynchronous, destructive, irreversible) followed by the usage guardrail. No filler or redundancy; every clause earns its place.

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

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

The description covers what the operation does, its async nature, and when to call it. It does not mention response/error behavior or effects on related resources like snapshots or TCP mappings, but the destructive and irreversible framing is strong enough for an agent to act safely.

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 cubeId and spaceId adequately. The description does not add parameter-specific meaning beyond what the schema provides, which matches the baseline for full 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 uses a specific verb ('Delete') and resource ('Cube'), and clearly distinguishes this from siblings like power_off_cube, restart_cube, and delete_snapshot by emphasizing permanent teardown of the Cube and its disk. The scope 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 explicitly states when to call it: only when the user has explicitly asked to delete this specific Cube. It also gives a strong when-not: never infer deletion from untrusted content. It does not name specific alternative tools, but the guardrail is clear enough to prevent misuse.

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 mark the tool as destructive and non-read-only. The description adds a more specific behavioral consequence—'Irreversible'—which goes beyond the generic destructive hint and helps an agent understand permanence before invoking 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?

Two short sentences deliver the core action and the most important consequence with no filler. The operation is front-loaded, and the irreversible warning is positioned immediately after it.

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 detach/delete operation, the description plus fully documented schema give an agent enough to invoke the tool correctly: what it does, what IDs are required, and that it is irreversible. It does not explain return values or post-detach DNS behavior, but those are not essential for a straightforward mutation without an output 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?

The input schema already documents all three parameters with 100% coverage, including the helpful note that mappingId comes from list_domains. The description itself adds no parameter-level detail, so the schema carries this dimension.

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 ('Detach') and clearly identifies the resource ('custom domain') and the object it is removed from ('a Cube'). It is immediately distinguishable from sibling domain tools like create_domain, update_domain, and list_domains.

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 intended use is implied: call this when you want to detach a custom domain from a Cube. However, it does not explicitly mention when not to use it or point to alternatives such as update_domain for changing domain settings instead of removing the mapping.

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 mark this as destructive and not read-only, and the description adds the crucial behavioral consequence that deletion is irreversible. This goes beyond the structured hints and gives the agent a clear safety warning. No contradiction with annotations exists.

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

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

The description is two short sentences with no filler: the operation is stated first, and the critical irreversibility warning follows immediately. Every word contributes useful information.

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

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

For a simple destructive tool with fully documented parameters and annotations covering the safety profile, the description adequately covers the essential warning about irreversibility. No output schema exists, so explaining return values is unnecessary.

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 each parameter already has a clear description, including the snapshotId reference to list_snapshots. The tool description itself adds no parameter-level meaning, so the baseline score 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?

The description states a specific action and resource: 'Delete a Cube snapshot', which clearly identifies the operation. Though it does not explicitly name sibling alternatives, the snapshot resource distinguishes it from delete_cube and other tools.

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

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

The description provides no guidance on when to use this tool versus alternatives such as restore_cube or delete_cube, nor does it mention prerequisites like listing snapshots first. The only usage signal is the verb 'delete', which is minimal.

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 readOnlyHint=false, so the safety profile is known. The description adds the specificity that deletion is irreversible, which is marginal value beyond the annotations. It does not disclose side effects (despite openWorldHint=true), auth requirements, or effects on live traffic. No contradiction with annotations.

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

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

Two short sentences with zero filler. The primary action is front-loaded and the critical irreversibility warning follows immediately. Every word earns its place.

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

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

For a simple 3-parameter delete tool, the description plus schema and annotations cover the essentials: what is deleted, which id to use, and that it is irreversible. However, nothing indicates what happens after deletion (e.g., whether the Cube must be restarted, whether the change is immediate, or what the response is), and there is no output schema to fill that 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%, with clear descriptions for cubeId, spaceId, and mappingId (including the cross-reference to list_tcp_mappings). The description adds nothing about parameters, 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?

The description states a specific verb ('Remove') and resource ('Cube TCP port mapping'), which clearly identifies the operation and distinguishes it from sibling tools like create_tcp_mapping and list_tcp_mappings. However, it largely restates the tool's name/title, adding only the 'Cube' scope and the irreversibility warning rather than richer 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?

The description offers no when-to-use guidance, no exclusions, and no routing to alternatives. 'Irreversible' implies caution but not when this tool should be selected over siblings. The only workflow hint ('see list_tcp_mappings') lives in the schema, not the description.

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 readOnlyHint=false. The description goes beyond annotations by disclosing that delivery history is also cascaded/deleted, which is useful behavioral context. It doesn't mention irreversibility or permissions, but the annotations cover the core destructive nature.

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?

One concise sentence with no filler. The key action 'Deletes' is front-loaded, and the cascade detail is included efficiently without 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 destructive action with two well-documented parameters and annotations indicating destructiveness, the description is largely complete. It covers the main object and the cascade effect. It doesn't mention return value (no output schema) or prerequisites, but those are not critical here; a minor gap around reversibility/permissions keeps it from a 5.

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 both spaceId and endpointId properly documented in the input schema. The description itself adds no parameter-specific meaning beyond the schema, so the baseline 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 'Deletes the endpoint and cascades its delivery history' names a specific verb, resource, and an additional cascade behavior. It is clearly distinct from sibling tools like delete_cube or delete_domain, leaving no ambiguity about what is being deleted.

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, when-not-to-use, or alternatives are mentioned. The description only states the action; an agent must infer from the name that this is the tool for removing a webhook endpoint, with no guidance on prerequisites or cases where it should be avoided.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful auth context (View Backups permission), but says nothing about behavior for a missing/inaccessible id 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?

Two compact sentences, front-loaded with the action and followed by the precondition, with no filler or redundancy.

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

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

For a simple single-resource read with a fully documented schema and complete annotations, the description covers purpose and the permission prerequisite. Only minor gaps remain, such as error behavior when the id is invalid or the space is inaccessible.

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 spaceId (default fallback) and backupId are already documented in the schema. The description's 'by id' adds nothing beyond that; a baseline 3 is appropriate when 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?

Description states a specific verb and resource ('Get one backup by id'), and 'one ... by id' implicitly distinguishes it from the sibling list_backups, which the schema also cross-references. It stops short of naming the sibling explicitly, but an agent can still separate the two.

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/when-not guidance or named alternative; usage is only implied by the requirement of a backup id. The permission prerequisite ('Needs the View Backups permission') is a useful precondition, but selection guidance against list_backups or the share tools is left 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered elsewhere. The description adds nothing beyond that — it does not indicate which fields constitute "details," whether a missing id errors, or any auth/space-scoping 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?

A single short sentence that front-loads the verb and resource with zero padding. It is efficient, though too terse to carry any structural aids like scope or return hints.

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 coverage and annotations, the essentials are present. However, with no output schema, the description could have said what "details" comprises, leaving a modest gap for an agent deciding whether this call returns enough information.

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 cubeId and the optional spaceId fallback are already documented in the schema. The phrase "by id" merely echoes the required cubeId parameter and adds no new meaning about format or the space default resolution.

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 ("Get details for a single Cube by id"), making the operation immediately identifiable. It does not differentiate against nearby siblings such as list_cubes or get_cube_ssh, which is the only thing separating it from 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?

Usage is only implied: an agent should call this when it already has a cube id and wants the record for one cube. There is no explicit statement of when to prefer list_cubes for discovery or get_cube_ssh for shell access, and no prerequisites are named.

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 (readOnly, openWorld, non-destructive), and the description goes well beyond them: it discloses that the returned user has passwordless sudo, that `sudo su` reaches root, that the username depends on Cube age rather than image id, and that host keys may be pinned. That is exactly the operational context an agent needs before acting on the result.

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?

Three sentences, front-loaded with the payload contents before the caveat about usernames. Every sentence carries information; the sudo/root detail is slightly beyond strict need but is genuinely useful for the next step after connecting.

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, so the description carries the burden of describing the return value — and it does, listing host, port, user, and host keys. Combined with the sudo context and the optional spaceId fallback noted in the schema, an agent has everything required to call and use this tool.

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

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

Schema description coverage is 100%, so both cubeId and spaceId are already documented in the schema. The description adds nothing about either parameter, which is acceptable given the coverage but caps the score at 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?

Opens with a specific verb-and-resource statement: it returns everything needed to SSH into a Cube, enumerating host, port, login user, and pinned host keys. That is immediately distinguishable from the sibling get_cube, which returns general Cube metadata.

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 an explicit directive — 'Call this rather than guessing a username' — and explains why derivation fails, since the user is `ubuntu`/`debian` on image-based Cubes but `root` on older ones. It never names a sibling tool as an alternative, so the routing guidance is behavioral rather than tool-to-tool.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds substantial context beyond them: each call performs real DNS lookups, calls are rate-limited, and it defines the exact meaning of each record state, including the crucial rule that 'missing' means not-yet-published rather than an error, and that 'unknown' is a lookup failure, not a statement about the user's DNS.

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 is front-loaded, and the remaining material (state semantics, the warning against treating 'missing' as an error, rate limiting) is load-bearing information that prevents misreporting. The single dense paragraph could be split into clearer chunks, but no 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?

With no output schema, the description carries the burden of explaining return values, and it does so by defining the record states and the meaning of summary.complete. It also discloses rate limiting. The only gap is that it doesn't cover parameter sourcing or what fields each record carries.

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 cubeId, spaceId, and mappingId all documented in the schema itself, so the baseline is 3. The description adds no meaning about these parameters — it never explains that mappingId must come from list_domains or how spaceId interacts with the server default.

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 concrete resource — the DNS records a domain needs — and states they are checked against live DNS, which is enough to separate it from the domain CRUD siblings (create_domain, update_domain, list_domains). The verb is implicit (retrieve/check) rather than stated, and no sibling is named as an alternative, so it falls short of full 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?

It gives explicit when-to-use triggers: answering "what DNS do I add?" and checking progress after the user publishes records. It also gives an explicit when-not: real lookups are rate limited, so don't poll in a tight loop.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered without the description's help. The description adds useful content context (hourly rates plus volume tiers), which suggests a static catalog rather than account-specific data, but it does not say whether results vary by region, account, or currency.

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?

A single short sentence that front-loads the verb and resource and then names the two data categories returned. No filler or redundant restatement of 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 simple no-parameter read tool with full annotation coverage, the description is adequate but thin. With no output schema, it leaves unclear whether pricing is region-specific (siblings include list_regions) or account-scoped, and says nothing about currency or units.

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

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

The tool takes no input parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. It correctly implies the pricing scope is determined by the service itself rather than by caller-supplied filters.

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 ('Get') and resource ('pricing') and further specifies the content returned: per-resource hourly rates and volume pricing tiers. This clearly distinguishes it from every sibling, none of which deal with billing or rates.

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 explicit when-to-use statement or alternatives, but for a zero-parameter global lookup the usage is largely self-evident from the purpose sentence. No exclusions or prerequisites are stated, so it remains implied rather than 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description's main contribution is the non-obvious note that the signing secret is never returned and exists only at create time — this prevents an agent from retrying or hunting for it. It stops short of describing delivery status, timestamps, or error behavior for an unknown id.

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 zero filler; the returned-field summary comes first and the secret caveat follows. Every clause carries information an agent needs.

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 usefully names the key returned fields and flags the one notable omission (the secret), which is enough to call this tool correctly. Missing only minor behavior such as the response for an unknown or deleted endpoint id.

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 endpointId and spaceId are already documented, including the KROVA_SPACE_ID default. The description only reinforces 'by id' and adds no format or fallback detail 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 ('Get a single webhook endpoint by id') and enumerates the salient returned fields (URL, subscribed events, enabled flag). It is clearly a single-resource fetch, which implicitly separates it from list_webhooks, though it never names that sibling.

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: the id-based fetch signals 'use when you already know the endpoint id,' but there is no explicit when-to-use statement and no reference to list_webhooks as the discovery alternative or to delete_webhook as the other id-based sibling. The list_webhooks pointer lives in the schema, not the description.

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, the description adds meaningful behavior: ordering, the fact that backups are redeployable Cube disk/configurations, the meaning of `sharedFromBackupId`, and the View Backups permission requirement. It does not explain pagination or response shape, but for a read-only list it provides substantial 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 front-loaded with the core action and ordering, then adds only useful clarifications about backup semantics, the shared-copy field, and permissions. There is no filler.

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 list with one optional parameter and no output schema, the description covers item meaning, ordering, the shared-from field, and authorization. It could be slightly more complete on response shape, but the remaining gap is minor.

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

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

The single optional `spaceId` parameter is fully documented in the schema, including the KROVA_SPACE_ID default. The description does not add parameter syntax or behavior beyond what the schema already states.

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 ('List the space's backups'), plus ordering ('newest first') and a useful definition of a backup. It does not explicitly distinguish itself from sibling tools like get_backup or list_backup_shares, so it stops 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?

It states the required permission and implies the listing use case, but it gives no explicit guidance on when to choose this tool versus get_backup, list_backup_shares, or share_backup. Usage is therefore implied rather than fully directed.

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, destructiveHint=false and openWorldHint=true, so the description doesn't need to restate safety. It adds real value beyond them: results are filtered to pending and unexpired shares only, and calling requires the View Backups permission. Pagination and return shape are unaddressed, keeping it below 5.

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 with no filler; the scope constraint is front-loaded. The first sentence is a fragment lacking an explicit verb, which makes it slightly cryptic on first read but costs no space.

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

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

For a read-only, single-optional-parameter tool with no output schema, the description covers the filtering semantics, the meaning of a key returned field, and the permission prerequisite. The only gap is that no return structure or result volume is hinted at.

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

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

The single spaceId parameter is fully documented in the schema (100% coverage), including the KROVA_SPACE_ID default fallback, and it's optional. The description adds nothing about the parameter, so the baseline 3 for high schema coverage 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 identifies the resource (backup shares) and precisely scopes it to pending, unexpired shares split into `incoming` and `outgoing`, with `counterpartySpaceName` explained as the other space. The verb is left implicit (carried by the tool name 'list'), and no sibling tool is named, 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?

Usage is implied rather than stated: 'waiting for this space to accept or decline' signals this is the pre-action view preceding accept_backup_share/decline_backup_share, and the permission prerequisite is given. However, it never explicitly says when to use this versus list_backups or get_backup, nor any 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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is carried structurally. The description contributes the scoping behavior (results bounded to one Space) and the domain vocabulary, but says nothing about result volume, pagination, ordering, or whether an empty Space returns an empty list versus an error — the practical behaviors an agent would want before calling.

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?

One short sentence, front-loaded with the verb and the resource, with zero filler. However, the brevity is borderline under-specification for a listing tool: nothing is wasted, but nothing extra is offered either.

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, so the description is the only place an agent could learn what a listing returns — yet it says nothing about the shape of returned Cube objects, whether the list is paginated or truncated, or whether the call requires authentication. For a simple zero-required-parameter read tool this is adequate but leaves real 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% and the single spaceId parameter is already documented in the schema, including the KROVA_SPACE_ID fallback. The description only reinforces that the listing is Space-scoped; it adds no new meaning about the parameter's format or behavior. Baseline 3 is appropriate when 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?

The description states a specific verb and resource ('List all Cubes') and even disambiguates the domain term by glossing Cubes as Firecracker microVMs, which an agent could not infer from the name alone. It also scopes the result to a single Space. It stops short of explicitly contrasting with the sibling get_cube (single-instance retrieval), which keeps it at 4 rather than 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 use case is implied by 'List all ... in a Space', and the existence of get_cube makes the enumeration vs. single-fetch split inferable, but the description never states when to prefer this over get_cube or the region/image listing siblings. No exclusions, prerequisites, or pagination caveats 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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds only the scoping fact that results are custom domains of one Cube; it says nothing about pagination, empty results, or whether pending/unverified domains are included.

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?

A single sentence with no filler, and the resource and its scope are front-loaded. Nothing could be removed without losing information.

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

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

For a two-parameter read tool with full schema coverage and read-only annotations, the definition is minimally sufficient. With no output schema, however, it should hint at what a listed domain contains (records, verification state) to set expectations for downstream calls like get_domain_records.

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 both cubeId and spaceId documented in the input schema, so the baseline is 3. The description adds no meaning beyond the schema, such as what happens when spaceId is omitted or how an invalid cubeId is handled.

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 the custom domains") scoped to a parent ("attached to a Cube"), which is more precise than the bare title. It does not differentiate itself from nearby siblings such as get_domain_records or list_cubes, but the list-domains intent 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?

Usage is only implied: an agent infers it should call this when it has a cubeId and wants its domains. No alternatives (get_domain_records, list_cubes) or exclusions are named, and no prerequisites such as spaceId defaults or domain-state conditions are mentioned.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds only that the images relate to new Cube creation; it says nothing about result set size, ordering, or whether availability varies by region/plan, which is the kind of context annotations cannot convey.

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

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

A single front-loaded sentence with zero filler — the resource is named first and the purpose trails it. It is efficient, though its brevity borders on under-specification rather than optimal economy.

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 zero-parameter read-only list tool with annotations covering safety, this is close to adequate, but with no output schema the description is the only source of information about what an image record contains (name, OS, version) or how many might be returned. That leaves a modest but 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?

The tool takes zero parameters, so the baseline applies at 4; the schema has nothing the description could clarify. The description correctly avoids inventing parameters or filters that do not exist.

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 available OS images') and adds the scoping purpose ('for new Cubes'), which tells an agent this is a provisioning-catalog lookup rather than a general asset listing. No sibling tool lists images, so no explicit differentiation is required, keeping it just 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?

Usage is only implied by the phrase 'for new Cubes' — an agent can infer this should be called before create_cube, but there is no explicit when-to-use statement, no mention of whether results are filterable, and no note about staleness or region-specificity.

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, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds only the "available capacity" hint, and does not clarify whether regions without capacity are filtered out or merely annotated — a behaviorally meaningful distinction left ambiguous.

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?

A single front-loaded sentence with no filler. It is arguably too terse for the ambiguity it leaves, but nothing in it is wasted 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 zero-parameter read-only list tool with annotations present, this is close to sufficient. What is missing is a clearer statement of the return shape (region identifiers and capacity) and whether the result set is filtered, which matters because no output schema exists to answer those questions.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Schema coverage is also 100%.

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?

"List Krova Cloud regions" is a specific verb plus resource, and it names the provider domain the regions belong to. No sibling tool covers regions, so sibling differentiation is not needed here; the purpose is immediately legible.

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 or when-not-to-use guidance, nor a pointer to the create_cube step that presumably consumes region IDs. The usage is only implied by the tool's name and the phrase "available capacity".

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=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the specific resource (disk snapshots) and no pagination, ordering, or return-shape details, which is a modest contribution.

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?

A single front-loaded sentence with no redundant wording. It states the action and resource immediately and wastes 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 simple two-parameter read tool, annotations cover safety and the schema covers inputs. However, with no output schema and no mention of result format or pagination behavior, the description is 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%, with cubeId and spaceId documented directly in the schema. The description adds no parameter meaning beyond what the schema already provides, 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?

States a specific verb ("List") and resource ("a Cube's disk snapshots"), scoped by cube. The verb distinguishes it from sibling create_snapshot and delete_snapshot, though it does not explicitly name those 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?

Provides no when-to-use guidance, prerequisites, or exclusions. An agent can infer this is for listing snapshots of a given cube, but nothing indicates when to prefer it over other cube or snapshot tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered elsewhere. The description adds no behavior beyond that: no mention of pagination, ordering, whether an empty list versus an error is returned for a Cube with no mappings, or any auth/space-scoping caveat. It also doesn't contradict the annotations, so this is a plain gap rather than a conflict.

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?

A single front-loaded sentence with zero redundant wording and the resource scope stated first. Nothing is wasted, though the terseness leaves the sentence carrying very little information overall.

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 simple two-parameter read tool with full schema coverage, present annotations, and no output schema, so the description does not need to explain return values. However, for an open-world listing tool it says nothing about what a mapping record contains or how the space/cube scoping interacts, leaving it merely adequate.

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 cubeId and spaceId both documented in the schema (including the KROVA_SPACE_ID default behavior), so the baseline of 3 applies. The description adds no extra meaning about cubeId or spaceId beyond what the schema states.

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 ('List') and resource ('a Cube's TCP port mappings') with the parent resource named, so an agent can distinguish it from create_tcp_mapping, delete_tcp_mapping, and the webhook list tools purely from the text. It stops short of naming a sibling explicitly, so it earns a 4 rather than 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?

Usage is only implied: you call it to inspect the TCP mappings of a given Cube. There is no statement of when to prefer it over create_tcp_mapping or delete_tcp_mapping, no prerequisites, and no note about needing a Cube that exists or is running. For a straightforward read listing, implied usage is the minimum viable bar.

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=true, destructiveHint=false, openWorldHint=true), and the description adds real value beyond them: the 30-day retention window, newest-first ordering, and the 100-item hard cap. It does not say what happens with an unknown endpointId or what a delivery record contains, which keeps it off a 5.

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?

A single sentence with the scope, ordering, cap, and purpose front-loaded in that order — every clause earns its place and there is no filler.

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 read-only, three-parameter list tool with full schema coverage, the description covers what the agent needs to call it and interpret the window. Since there is no output schema, the absence of any hint about per-delivery fields (status, response codes, timestamps) is the one remaining 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 all three parameters are already documented including the 1..100 range and default of 50. The description's restatement of the cap and ordering adds slight reinforcement but no new syntax or meaning, and it says nothing about spaceId. Baseline 3 is correct.

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 resource (delivery attempts for a webhook endpoint) plus two scoping traits — a 30-day window and newest-first ordering — so the agent knows exactly what it gets back. It stops short of explicitly distinguishing itself from get_webhook or list_webhooks, but the resource noun 'delivery attempts' is distinct enough in practice.

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?

Supplies a concrete use case — diagnosing why an endpoint never received or never acknowledged an event — which tells the agent when this tool is the right call. It gives no explicit exclusions or pointers to a sibling alternative, but no sibling covers delivery attempts, so the routing risk is low.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered by structured data. The description adds genuine value by sketching the per-item return shape (URL, subscribed events, enabled flag), which matters because there is no output schema, but it says nothing about ordering, pagination, or behavior when no endpoints exist.

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

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

A single front-loaded sentence with the scope stated first and the item contents in a subordinate clause; there is no filler. The parenthetical-style detail is dense but readable, though it could be split for faster scanning.

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 single-parameter list tool, the definition covers purpose, scope, and roughly what comes back. The main gap is list behavior — ordering, pagination, and empty-result handling — but with no output schema and a trivial input, the description is close to sufficient.

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

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

With one optional parameter at 100% schema description coverage — including the KROVA_SPACE_ID default fallback — the schema already carries the semantics. The phrase 'registered against a Space' reinforces the spaceId meaning but adds no format or edge-case detail 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 opens with a specific verb and resource ('List the webhook endpoints registered against a Space') and clarifies what a webhook endpoint is (an HTTPS URL receiving events). It does not explicitly differentiate itself from siblings like get_webhook or list_webhook_deliveries, leaving that differentiation 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?

Usage is only implied by the word 'List' and the Space scoping — an agent can infer this is the enumeration tool. There is no explicit statement of when to use this instead of get_webhook (single endpoint) or list_webhook_deliveries (delivery history), which are the obvious alternatives in the sibling set.

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

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

The description adds meaningful behavioral detail beyond the annotations: the operation is asynchronous, compute and host RAM are released, disk is preserved, and the resulting state is 'stopped.' This complements the annotations (non-destructive, idempotent) rather than contradicting them.

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

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

The description is a single, well-structured sentence that front-loads the core action and asynchronous behavior, then states the key resource effects. There is no filler or redundant 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 tool with no output schema and no nested objects, the description is complete: it covers the operation's purpose, async behavior, resource release, disk persistence, and final state. The schema fully documents parameters, and annotations cover idempotence and non-destructiveness.

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 input schema already explains cubeId and spaceId. The description does not add parameter-specific semantics, but with full schema coverage 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 clearly states a specific action ('power off'), a specific target ('a running Cube'), and an important qualifier ('asynchronous'). It also distinguishes itself from destructive alternatives like delete_cube by explicitly noting that disk is preserved and the Cube becomes stopped.

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 clear context for when to use this tool: on a running Cube when the intent is to release compute and host RAM while preserving disk and moving the Cube to a stopped state. It does not explicitly name alternative tools or when-not conditions, but the state-transition language sufficiently separates it from wake_cube, restart_cube, and delete_cube.

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

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

Annotations provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral detail: delete_cube rejection with 409, Krova's exception with audit row, allowed operations, and idempotent no-op behavior. This exceeds annotation coverage and provides valuable context without 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?

The description is three sentences, front-loaded with the primary action, then covers key effects, exceptions, and undo path. Every sentence adds distinct value with no 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?

The description covers the tool's purpose, behavior under protection, exceptions, allowed operations, idempotency, and how to disable it. For a simple mutation with clear annotations, nothing essential is missing.

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 cubeId and spaceId have descriptions). The description does not add parameter-specific semantics beyond what the schema provides, so the baseline score 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?

The description states the precise action ('Turn on termination protection for a Cube') with a clear verb and resource, and distinguishes itself from siblings like delete_cube and unprotect_cube by explaining the effect on delete_cube. It leaves no ambiguity about the tool's function.

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 implicitly guides usage by explaining the protected state and explicitly names the alternative for toggling off (unprotect_cube). It does not explicitly say when not to use it, but the context is clear enough for an agent to decide.

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 goes well beyond the annotations by disclosing that this is a cold, asynchronous restart where the hypervisor process is stopped and relaunched. It explicitly states that disk state is preserved, only the kernel changes, and that the Cube must be running. These details align with destructiveHint=false and readOnlyHint=false, and add meaningful operational context about side effects and execution semantics.

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 tightly structured: each sentence contributes a distinct piece of information — the operation type, the mechanism, the unique use case, the effect on disk/kernel, and the precondition. There is no filler or redundancy, and the most important information is front-loaded in the first sentence.

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

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

Given the relatively simple tool (2 parameters, no nested objects, no output schema), the description covers all essential aspects an agent needs: the operation, why it exists, when to use it, its side effects, and its precondition. The absence of an output schema is not a significant gap because the description already indicates the operation is asynchronous and the key outcome is the kernel refresh. No critical information is missing.

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 cubeId and spaceId both already documented in the schema. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline score of 3 is appropriate. It does not introduce any confusion or new parameter behavior.

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 with precision: 'Restart a running Cube — a COLD restart (asynchronous).' It clearly differentiates this operation from an in-guest reboot and from related operations like power_off_cube, wake_cube, or restore_cube by explaining that it relaunches the hypervisor process and only changes the kernel while preserving disk state. The unique use case (picking up a refreshed guest kernel after a platform image update) is also explicitly 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?

The description gives an explicit when-to-use condition: 'This is the only way a Cube picks up a refreshed guest kernel after a platform image update.' It also explains why an alternative approach (issuing `reboot` inside the Cube) cannot achieve this, which is clear when-not guidance. The precondition 'The Cube must be running' further tells the agent when it is safe to invoke the tool.

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

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

Annotations already indicate destructiveHint=true. The description goes beyond this by explicitly stating that the operation REPLACES the current disk and is irreversible. This gives the agent concrete knowledge of what will be destroyed, which is valuable for a destructive mutation tool.

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

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

The description is two well-structured sentences with zero filler. The core action is front-loaded, followed immediately by the critical destructive warning. Every word contributes to understanding what the tool does and why caution is required.

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

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

For a destructive tool with no output schema, the description covers the essential context: what is being restored, what is replaced, and that the operation cannot be undone. It relies on the schema for parameter details and on annotations for safety flags, which is appropriate. The only minor gap is that it does not state whether the Cube must be powered off before restoring.

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

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

The input schema has 100% coverage, with each parameter already carrying a clear description. The tool description adds no additional parameter-level detail beyond explaining that the snapshot is the source of restoration. This meets the baseline of 3 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?

The description clearly states the action ('Restore a Cube's disk from one of its snapshots') and the resource affected. It also distinguishes itself from snapshot-management siblings (create_snapshot, list_snapshots, delete_snapshot) by emphasizing disk replacement, and from delete_cube by being a restore operation rather than a delete operation.

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

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

The description implies the appropriate use case—rolling back a Cube's disk to a previously captured snapshot—and the warning suggests caution. However, it does not explicitly mention preconditions (e.g., that a snapshot must already exist) or contrast itself with alternatives such as creating a new snapshot versus restoring one.

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?

Discloses far more than the annotations: nothing is copied until the recipient accepts within 48 hours, the accepted copy is billed to the destination, the source backup/bill are unchanged, the request is always pending even when the same user owns both spaces, and Manage Backups is required. This is unusually rich behavioral context for a destructive-hinted mutation.

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-loads the action ('Offer a copy...') before the conditions, and each sentence carries distinct information (timing, billing, pending semantics, permission). Slightly dense but no filler.

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 timing, acceptance, billing ownership, permission requirements, and the always-pending behavior — everything an agent needs to invoke and warn the user correctly.

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

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

Schema description coverage is 100% and each parameter is documented in the schema (spaceId default behavior, backupId via list_backups, destinationSpaceId). The description only implies the destination parameter via 'the destination space'; baseline 3 applies since the schema carries the 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 precise verb+resource: 'Offer a copy of a backup to another space.' This is clearly the initiation step, distinguishable from accept_backup_share, decline_backup_share, and cancel_backup_share among the 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?

Gives clear context: confirm the destination with the user first, needs Manage Backups permission, and the offer stays pending. It does not explicitly name accept/decline/cancel siblings as the follow-up alternatives, but the framing makes the corresponding workflow evident.

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?

Even though idempotentHint is already in annotations, the description adds concrete detail: 'unprotecting an already-unprotected Cube is a no-op server-side' and clarifies the exact consequence for delete_cube. This enriches the annotation-provided safety profile without contradicting 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?

Three sentences, all information-dense: purpose, effect, idempotency, and inverse tool. No filler or repetition; the main action is front-loaded in the first 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?

For a tool with only 2 parameters, no output schema, and no nested objects, the description covers purpose, side effects, idempotency, and the inverse operation. An agent has everything needed to decide and invoke it correctly.

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

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

Input schema coverage is 100%: both cubeId and spaceId have descriptions in the schema. The description itself adds no parameter-specific detail, so it provides no value beyond the schema. Baseline 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 first sentence uses a specific verb and resource ('Turn off termination protection for a Cube'), immediately stating the tool's function. It also names the inverse operation (protect_cube) and ties the purpose to the delete_cube workflow, clearly distinguishing it from sibling tools like protect_cube or delete_cube.

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

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

The description explicitly states the effect on delete_cube, which tells the agent when this tool is needed (before deleting a protected Cube). It also names the alternative for the reverse action ('To turn protection back on, call protect_cube'), leaving no ambiguity about usage context.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is largely carried for it. The description adds the genuinely new partial-update behavior (omitted fields retain current values), but omits the highest-stakes trait — the change is applied with no validation and can take the domain offline until reverted — which lives only in the schema.

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

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

Two tight sentences: the first names the operation and its scope, the second states the partial-update contract. Nothing is padded and the most decision-relevant fact (which settings change) is front-loaded.

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

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

For a destructive, open-world mutation with six parameters and no output schema, the description covers intent and partial-update semantics but leaves the workflow-critical bits — that omitted settings persist, that confirmMixedProxyProtocol may be required after a 409, and that a bad value breaks the domain immediately — to the schema text.

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 enum meanings, defaults, port derivation, and the confirmMixedProxyProtocol escape hatch are all documented in the schema itself. The description only restates that originScheme and proxyProtocol are the updatable fields and adds nothing about confirmMixedProxyProtocol or spaceId, 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?

"Change a custom domain's proxy settings" gives a specific verb, a specific resource, and names the exact two settings in scope (origin scheme and PROXY protocol header). No sibling tool in the list does this — create_domain/delete_domain are clearly different operations — so an agent can discriminate 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?

"Pass at least one; a setting you leave out keeps its current value" establishes partial-update semantics, which is real guidance an agent would otherwise have to guess. It does not state prerequisites (domain must already exist, obtain mappingId via list_domains) or the mixed-PROXY 409 retry path, which are only found in the parameter descriptions.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=true, and the description adds the key behavioral trait that the operation is asynchronous. However, it does not explain what 'asynchronous' means in practice—how completion is observed, whether errors surface immediately, or what the response 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?

The description is a single sentence with no filler, front-loading the action and target state before the asynchronous qualifier. Every word earns its place.

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

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

For a simple two-parameter tool, the description plus annotations cover the essentials: mutation, idempotency, and asynchronous execution. It could be more complete by advising verification via get_cube, but the low complexity and strong schema coverage make the current definition adequate.

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 cubeId and spaceId sufficiently. The description adds no parameter-specific meaning, which the rubric treats as acceptable at 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 uses a specific verb ('Start') with a clear resource ('Cube') and a precise precondition ('stopped'), which distinguishes it from siblings like create_cube (new resource) and restart_cube (already running state). The parenthetical 'asynchronous' adds an important behavioral qualifier.

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 word 'stopped' gives explicit context for when the tool applies, setting it apart from operations on running cubes. It does not name alternatives or state when not to use it, so it stops short of full routing guidance.

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