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

Annotations only declare the general write profile (readOnlyHint false, destructiveHint false, openWorldHint true); the description goes well beyond by disclosing the two-phase signature protocol, that the protocol operator key is never used as user identity, and the exact 409 CLORDID_CONFLICT failure mode for clOrdId reuse. It also clarifies that signing is a distinct request requiring a fresh idempotency key, which is the kind of detail an agent cannot infer from annotations.

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

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

The union rule is correctly front-loaded, but the three trailing 'Examples' restate the same two branches almost verbatim ('First call without signature — server returns EIP-712 typedData to sign' repeats sentence two). The only genuinely new information in that block is the parameter pairing of orderSignature + nonce, so the tail is largely redundant.

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

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

For an 18-parameter write tool with an output schema, the description covers the hard part: the prepare/sign/resubmit lifecycle and the idempotency conflict rule. What remains unstated is prerequisite ordering relative to the wallet-proof nonce and how this tool relates to the batch and plan siblings, which the schema alone cannot resolve.

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 baseline is 3; the description still adds the sequencing semantics of `orderSignature` and `nonce` that the schema documents only in isolation. It does not cover the other 16 parameters, but the schema already carries unusually detailed semantics for those.

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 ('Prepare or place a limit order') and immediately qualifies the dual mode via the `requiresSignature` union, so an agent knows this single tool covers both the prepare and the submit phase. It stops short of naming siblings, so it does not help the agent distinguish this from batch placement or the other order-preparation tools in the sibling list.

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

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

The branching guidance is explicit: call without `orderSignature` to get signable typedData, sign it exactly as returned, then resubmit with the signature plus the nonce from the payload. The clOrdId reuse rule (409 CLORDID_CONFLICT on divergent body, existing order returned on matching body) gives a concrete usage condition. No guidance is given on when to prefer this over batch placement or other preparation siblings.

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