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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the record is 'signed' and describes the hub layer fields (seat, market, claim, price, availability) and offers with tenant parameter. However, it does not disclose pagination, error behavior, or auth requirements beyond 'authorised presentation'. With annotations carrying the behavioural burden, a 3 is appropriate.

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 a single dense sentence with nested parentheticals listing id formats and field names. It is front-loaded but heavy, packing multiple lists into one sentence, which reduces readability. Some elements, such as the catalogue id, could be separated.

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 values need not be described. However, with 0% schema description coverage and an undocumented decision_id parameter, the description is incomplete for an agent to invoke correctly. It covers the main identifier formats but omits tenant and decision_id semantics, leaving the definition adequate but with clear 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 0%, so the description must compensate. It explains only presentation_id formats (US NDC, CA DIN, EU EMA number, KR MFDS, CH Swissmedic, JP code, or catalogue id) and mentions tenant is a parameter. It does not explain decision_id at all, nor does it clarify what 'tenant' does beyond being a parameter. Two of three parameters lack semantic detail, leaving a significant gap.

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 verb (retrieve) and resource (an authorised presentation product record), and enumerates the fields returned (brand, strength, form, route, device, pack, holder, status, offers). It is distinguishable from siblings like get_price or get_availability, which focus on single facets. It could more explicitly contrast with search_cleared_items or compare_presentations.

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 does not say when to use this tool versus alternatives. It does not mention search_cleared_items, compare_presentations, or any other sibling. There is no when-not-to-use guidance or precondition stated.

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