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

Beyond the annotations, the description discloses that prepare is free and does not compute, that compute uses the existing authenticated pricing API, and that a credential must be configured first. The warnings against inventing answers and treating a continuation as authorization add useful safety context, though the exact side effects or outputs of compute remain unspecified.

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 short and front-loaded, moving from purpose to workflow to compute prerequisites to safety constraints in a few dense sentences. Every sentence adds operational value with no filler.

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?

Given the low schema coverage and lack of an output schema, the description does a good job explaining the conversational loop, credential requirement, and safety boundaries. The remaining gap is that it does not clarify what compute returns or how the answers fields map to the questions, but the core invocation is adequately covered.

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 only 33%, so the description must compensate, and it partially does by explaining the action enum semantics and the request/continuation workflow. However, it does not explain the answers object fields (currency, max_price, min_price, unit_cost, current_price, target_margin_pct) beyond saying they are sent back.

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 names a specific conversational pricing workflow: ask for missing pricing inputs, return questions, then compute once ready. It clearly separates prepare from compute, but does not explicitly name a sibling alternative such as compute_price or ask_pricing_analyst, so it stops short of full sibling 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 gives an explicit two-step flow (request: {}, then continuation.request plus answers) and states when to switch to action compute. It also warns to configure credentials before compute, but does not explicitly say when to use this tool rather than compute_price or ask_pricing_analyst.

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