Rechercher des opportunités

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context: server-side filtering, paginated list response, dictionary-based integer IDs, keyword-prefix matching (CSOC, CCON, etc.), and period filter semantics. No contradiction with annotations.

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?

Despite being long, the description is tightly structured with bolded use-case headers and terse bullet lines. The opening sentence is a concise purpose statement, and the final line cleanly notes the paginated return and detail tools. Every section carries actionable knowledge with no filler.

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 27 optional parameters and an output schema present, the description covers the main filter categories, common scenarios, sorting, and pagination. It does not address every param (e.g., shields, flags, narrowPerimeter), but those are sufficiently documented in the schema. Missing minor guidance on how to fetch dictionary IDs is a small gap.

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 significantly enhances understanding of several parameters: perimeterDynamic values, perimeterManagersType combination, keyword prefixes, and period filter examples. These go beyond the schema's field descriptions, though many simpler params (page, pageSize) are left to the schema.

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 opens with a clear, specific statement: 'Recherche des opportunités commerciales dans BoondManager avec filtres serveur.' This names the verb (rechercher), resource (opportunités commerciales), and scope (server-side filtering). It further distinguishes from the sibling detail tool by noting it returns a paginated list and directing users to boond_opportunities_get for detail.

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 abundant usage guidance: common use cases ('Mes opportunités', 'États / types', 'Lié à une société...', 'Période', etc.) with concrete parameter examples and a clear 'Returns' line recommending boond_opportunities_get for detail. It lacks an explicit 'when not to use' or alternatives among other search tools, but the context is clear.

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