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

Despite destructiveHint and non-idempotent annotations, the description adds substantial behavioral context beyond them: it explicitly says the tool returns an UNSIGNED transaction/payload, closes are geo-gated, the two-phase signed_transaction flow is supported, and idempotency_key replays the original result. This greatly helps the agent understand side effects and execution phases.

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 organized with parameter-scoped notes and front-loads the core purpose before getting into idempotency and two-phase execution. It is somewhat long and repeats the place_perp_order reference multiple times, but each sentence contributes behavioral or safety-relevant 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?

The tool is complex (13 parameters) and the schema descriptions are absent, so the description carries a heavy burden. It covers the behavioral flow well, but leaves several defaulted and non-defaulted parameters unexplained and relies heavily on a sibling tool for crucial two-phase execution details. An output schema exists, but input semantics for parameters like wallet_address and pay_in_crank remain incomplete.

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

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

Schema description coverage is 0%, so the tool description must carry the parameter meaning; it does a good job for close_pct, position_id, jurisdiction, idempotency_key, verify, and signed_transaction. However, important parameters such as wallet_address, venue, pay_in_crank, payment_header, and acknowledge_tier_b receive no meaningful explanation, and the description defers a fair amount to place_perp_order rather than being self-contained.

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 ('Close a perp position'), the resource, and the full/partial scope, and it adds important context about non-custodial venue settlement and unsigned signing payloads. It does not explicitly distinguish itself from close-related siblings such as perp_close, so it falls just 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?

The description explains mechanics like idempotency, jurisdiction, and two-phase execution, but it does not state when to choose this tool versus alternatives such as perp_close, cancel_perp_order, or perp_modify. It also does not mention when not to use the tool, aside from implicitly being for closing perp positions.

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