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

Annotations already cover read-only, idempotency, and non-destructive behavior, so the description's real contribution is disclosing a gating dependency ('after the gate also ingredients, allergens, claims...'), i.e. that the response is tiered by access level. That is genuine behavioral context beyond the structured hints, though it never says what the gate is or how to satisfy it.

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?

Front-loaded with the key identifier and resource, then a semicolon-separated inventory of resolved fields. It is dense but single-purpose with no filler, though the field enumeration runs long.

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 most of the description's field list is arguably redundant, while the two genuinely ambiguous inputs (market as a filter, decision_id) and the unexplained 'gate' dependency are left open. Adequate but with clear gaps for a 3-parameter lookup with tiered responses.

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%, so the description must carry parameter meaning. It clarifies the gtin format ('EAN in European copy') and gestures at decision_id via the gating reference, but the market parameter is only listed as a returned field, not explained as an input filter, and decision_id is never defined.

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?

Names a specific resource and lookup key ('One item by GTIN'), and the enumeration of resolved fields signals this is the comprehensive item record rather than a slice like get_price or get_availability. The retrieval verb is only implicit, and it never names a sibling explicitly, so it stops short of a 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?

There is no explicit when-to-use or when-not-to-use guidance, and none of the plausible alternatives (verify_gtin, search_cleared_items, get_price, get_availability) are mentioned. The phrase 'after the gate' faintly implies a sequencing dependency on gate_transaction, but the agent must infer it.

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