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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses substantive behavior: currency is fixed by the delivery country and cannot be chosen, EU deliveries carry French VAT while non-EU carry 0% with duties payable by the buyer, and the result is indicative rather than authoritative. This is exactly the kind of pricing/tax context annotations cannot convey.

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?

A single dense sentence that front-loads the core behavior (currency determined by delivery country) and then layers tax regime and the non-binding caveat. Every clause carries information an agent needs; nothing is padding.

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 an output schema present, return values need no explanation, and the description covers the two things schemas can't: tax treatment and the indicative/non-authoritative nature of the price. The undocumented lang parameter and the unexplained display_currency are the only meaningful gaps.

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 25%, so the description must compensate. It usefully clarifies that country drives the billing currency (delivery-country semantics), but gives no meaning for lang or display_currency — and "the currency cannot be chosen" sits in unexplained tension with the existence of a display_currency parameter.

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 outcome — a price quote in the delivery country's billing currency, with the applicable tax regime. It is clearly separable from siblings like validate_configuration, render_configuration, and describe_model, though it never names them. Purpose is unambiguous but lacks explicit 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?

"Indicative and non-binding; the checkout on brm-chronographes.com is authoritative" implies this is a preview rather than a committing operation, which hints at when to use it. However, it never says when to prefer validate_configuration or create_order, or that this should precede an order. Usage is implied, not stated.

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