Candidats correspondant à une opportunité

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

Beyond the annotations, the description explicitly states that this tool makes no BoondManager API call, reads no data, and is generated server-side by the MCP. It also clarifies that it returns only a runbook and that nothing is executed by the call itself. This fully discloses the non-executing side-effect-free behavior and does not contradict the read-only/idempotent 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?

The description is front-loaded with the main behavior and uses clear labels (Quand, Plutôt que, Returns) that make it scannable. It is slightly longer than strictly necessary and repeats the no-API/no-action point at the end, but every section contributes useful guidance. This earns a 4 rather than a 5.

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 workflow tool with no output schema, the description explains what is returned (an ordered runbook with exact filters), what the model is expected to do afterward, and why no data is read. It also covers when to prefer this tool over the equivalent prompt and how the input opportunity_id is resolved. No essential information is missing.

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?

The schema already covers the single parameter fully, stating that it accepts a numeric ID or an opportunity title and auto-resolves via `boond_opportunities_search`. The description adds contextual framing about tools, expertise, and mobility but no new parameter-level semantics. With 100% schema coverage, the baseline of 3 is appropriate.

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 specific behavior: from an opportunity's tools, expertise, and mobility, it identifies matching active candidates. It then clarifies that the actual deliverable is a runbook text, which distinguishes it from a direct search tool. However, it does not explicitly differentiate from sibling workflow or search tools, so it falls 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?

The 'Quand' section states precisely when to use this tool: to run the multi-step scenario without having to determine the correct tool sequence and filter names. The 'Plutôt que' section explicitly names the alternative MCP prompt `candidats_pour_opportunite`, explains it is identical content, and states when this tool variant is preferable (clients that mishandle prompts/get, e.g. claude.ai). This is clear when/when-not guidance.

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