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

Beyond the readOnly/non-destructive annotations, the description discloses that it is free, owner-signed with no account, that ownership is proved by the paying wallet, and that a placeholder signature returns details.expected with the exact message to sign in two forms. It does not cover rate limits or the response format, but the behavioral content is unusually rich.

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 key facts (free, owner-signed, states returned) are front-loaded, but the description is long and tacks on a paragraph about the POST /feedback channel and a 'no individual reply' policy that does not help an agent select or invoke this tool. Several sentences could be trimmed without loss.

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

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

With no output schema, the description carries the return-value burden and does so well, defining each state and clarifying that 'listed' is only written by a catalogue read that found the host, plus evidence, last-checked time, and failure reasons. The remaining gap is the concrete response shape, which is only implied.

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

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

Schema coverage is 100%, so the baseline is 3, and the description goes further by explaining the signature formats (EIP-191 for 0x wallets, ed25519 'solana:<pubkey>:<sig>'), the nonce's replay-protection purpose, the signedAt time window, and the placeholder-signature probe flow. This meaningfully extends the schema descriptions.

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 ('every venue of your order with its state') and enumerates the possible states (queued, submitted, listed, etc.), so the agent knows exactly what is read. It differentiates itself from placement_venues/placement_ready by framing the order-centric, per-venue status view, though it does not name a sibling explicitly.

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

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

Usage is implied: this is the free, owner-signed read for checking an order's placement state. However, it never states when to choose this over placement_ready, placement_venues or placement_cancel, nor what prerequisite state an order must be in. The auth precondition is covered, but the routing guidance is not.

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