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

Annotations already declare read-only, open-world, non-idempotent and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: quota accounting ('one admitted API call consumes one shared account request, including admitted errors'), no automatic retries, and null-means-unknown semantics. It stops short of describing failure modes or pagination, but the quota/retry disclosure is material.

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 lead sentence front-loads the core purpose, and the following sentences are dense with no filler. The 'Product guides do not filter condition, language or edition' sentence is a useful scope guard, though its placement between price semantics and quota rules slightly interrupts the flow.

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?

An output schema exists, so return shape need not be explained, and the description still adds value with observed_at, quote scope, and null semantics. It covers quota and retry behavior, which matters for an API-consuming read. The one gap is that it never clarifies whether this alias is functionally identical to get_prices or differs.

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 50%: card_id is documented but the 'view' enum is not described anywhere. The description partly compensates by stressing 'one exact variant' and mentioning 'quote scope', which hints at the compact/full distinction, but it never explains what 'view' changes or what full returns. Baseline 3 is appropriate given the schema does half the work.

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 verb and resource ('Read measured EUR prices') and narrows scope to 'one exact variant', which is more precise than the title alone. It also identifies itself as a 'Compatibility alias of get_prices', which is informative but leaves ambiguous whether behavior differs from get_prices. Sibling differentiation against batch_prices, get_price_history and get_prices is only partially achieved.

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?

'Compatibility alias of get_prices' implies this exists for backward compatibility and that get_prices is the forward path, but it never states when to prefer one over the other. There are no explicit exclusions relative to batch_prices or get_price_history. Usage is inferable but not spelled out, so this sits at the minimum-viable level.

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