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

Annotations already cover safety (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds behavioral detail beyond that: it returns at most 10 real offers, includes price in euros and page address, and handles natural-language queries. It does not mention rate limits or auth, but for a read-only search tool the disclosed behavior is solid.

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 two sentences plus a brief language note, all front-loaded with purpose. Each sentence adds value: what it searches, how it responds, what it returns. No fluff or redundant restatement of the schema.

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?

For a search tool with no output schema, the description sufficiently covers what the agent needs to know: scope, input type, result limit, and result fields. It does not explain sorting or pagination, but that is minor for a 10-result max tool. Annotations cover safety, and schema covers parameters, so the description fills the remaining gap well.

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 100%, so the baseline is 3. The description implicitly informs the 'critere' parameter via example queries and the 'budget_max_eur' via 'a moins de 30 euros', but it does not add explicit parameter-level meaning beyond what the schema already describes. No deduction needed, but no bonus either.

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 clearly states a specific action ('Cherche dans le catalogue APP24') and the resource (chess training courses and subscriptions), distinguishes it from generic 'search' by focusing on natural-language queries, and specifies outputs (max 10 real offers, price, page address). This is enough for an agent to differentiate it from siblings like conseiller_une_offre or detail_offre.

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 provides example natural-language requests that imply when to use the tool, but it does not explicitly state when to prefer this over the sibling search or conseiller_une_offre, nor does it mention exclusions. Usage is inferable from examples but not directly guided.

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