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

Annotations already establish readOnly/idempotent/non-destructive, so the description adds useful behavior beyond them: it uses the live book, returns average and worst price, shares, cost, payout, fees and warnings. It doesn't mention potential auth/rate-limit quirks, but with the annotations covering safety, the extra context is sufficient.

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 dense sentences, front-loaded with purpose, followed by the only cross-parameter semantic that could trip an agent (amount units). No filler or repetition.

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 compensates by enumerating the main return concepts (prices, shares, cost, payout, fees, warnings). With 100% schema coverage for parameters, it is sufficiently complete, though a note on warning/error conditions would make it stronger.

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 schema already covers most parameter descriptions at 100%, but the description adds 'all-in' clarification for a market BUY amount and reinforces that market SELL and limit amounts are in shares. This is a small but real increment over the schema's 'USD for a market BUY, shares otherwise'.

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: 'Preview an order against the live book without placing it.' This clearly distinguishes quote_order from execution tools and sibling read tools like get_orderbook by emphasizing preview (quote) semantics, fee-inclusive output, and non-execution.

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 clear context: use this to preview an order before committing, and 'without placing it' draws the line against execution. It does not explicitly name an alternative order-placement tool or list exclusion conditions, 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.