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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuine behavioral context beyond them: the result is gated on a prior gate_transaction allow and is derived from the maker's offers on the record. It does not disclose caching, staleness, or failure behavior if no decision exists, so not 5.

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 purpose and the gate precondition are front-loaded, which is good, but the trailing fragments 'Plain $ on human surfaces' and 'Tiers buy services, never rank' are cryptic domain asides whose value is unclear at first read. Roughly half the text earns its place.

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, returns need not be described, and the critical gate/decision_id dependency is documented. However, two of three parameters are undocumented and no fallback is given for the case where gate_transaction did not return allow, leaving gaps for an agent to call it correctly.

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 0% across three parameters, so the description carries the full burden. It explains decision_id (produced by gate_transaction) but leaves gtin and market completely undefined, and even decision_id's format is left implicit. It compensates for only one of three parameters.

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 the resource (the price for this buyer) and its basis (list · contract · promotion window from the maker's offers), which distinguishes it from sibling getters like get_availability. The verb is only implied, and slogans like 'Tiers buy services, never rank' muddle rather than sharpen the statement, so it stops short of 5.

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 an explicit precondition: the tool must be called once gate_transaction has answered allow, with the resulting decision_id. That is a concrete sequencing rule an agent needs. It offers no when-not guidance or sibling alternatives (e.g., where to get a price without a gate decision), so it is not a full 5.

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