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 by explaining the idempotency_key behavior (replaying original result on retry), the two-phase signed_transaction/verify flow (and that cancel needs no state re-read), and the geo-gated jurisdiction aspect. It also clarifies that the venue_action is used to force the venue's own relay route. This adds meaningful behavioral context that annotations do not cover, without 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 structured in clear thematic paragraphs (purpose, jurisdiction, idempotency, two-phase, venue_action) and front-loads the core purpose in the first sentence. It is longer than average but each paragraph adds essential context that justifies its presence. It could be slightly tighter by consolidating the repeated 'see place_perp_order' references, but overall it is well-organized and skimmable.

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 tool is complex (11 params, two-phase execution, idempotency, geo-gating) and the description addresses most advanced concepts by delegating details to place_perp_order. However, it leaves basic parameters unexplained and omits any discussion of failure modes or error handling. Since an output schema exists, return value documentation is not required, but the description could still be more self-contained. For a destructive, non-idempotent operation, missing details about precondition checks or side effects limit completeness.

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

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

With 0% schema description coverage, the description must compensate. It explains idempotency_key, signed_transaction, verify, venue_action, and jurisdiction (by reference to place_perp_order). However, it does not explain core parameters like wallet_address, order_id, ip, caller_id, or acknowledge_tier_b. It relies heavily on referencing place_perp_order, which may be acceptable if that tool is well-documented, but the current description alone leaves several parameters under-explained. Given the high parameter count and low coverage, a score of 3 reflects partial compensation.

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 clear, specific statement: 'Cancel a resting perp order on its venue (non-custodial).' This identifies the verb (cancel), the resource (resting perp order), and a key differentiator (non-custodial, on its venue). It distinguishes itself from siblings like perp_close or perp_modify by specifying 'resting order' rather than a position or modification. The reference to place_perp_order for shared details further clarifies scope without confusing the primary purpose.

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

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

The description implies use for cancelling open orders but never explicitly contrasts with related tools. It points to place_perp_order for shared patterns, but does not state when to use this versus perp_close (closing a position) or perp_modify. The context of 'resting perp order' is clear enough for an informed agent, but explicit exclusionary guidance ('use X instead') is absent. This meets a minimum viable level but leaves room for ambiguity.

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