Rechercher des paiements

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, so the safety profile is fully covered. The description adds the compatibility note that invoiceId/companyId are kept for compatibility and passed as query params, which is useful behavioral detail. It doesn't describe pagination behavior edge cases or output structure, but with annotations covering the read-only nature, a mid score 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 reasonably compact, listing params in a docstring style with brief annotations. It front-loads the core purpose in the first line. The Args listing is organized and easy to scan. Minor inefficiency: 'Conserves pour compatibilite' and the Returns line are useful but could be consolidated. Overall efficient, though the docstring format is slightly verbose for what could be one to two sentences.

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/list tool with 100% schema coverage, no output schema, and strong read-only annotations, the description is fairly complete. It documents the essential query mechanisms (keywords format, date ranges, pagination, legacy params). It doesn't define return value structure, but that's mitigated by the absence of an output schema being a common pattern across these search siblings. Adequate for a search operation.

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 adds meaningful value by explaining the keywords format ('ACH<id>, CSOC<id>, PRJ<id> selon la doc Boond'), which is critical for a search tool. It also clarifies that invoiceId/companyId are legacy-compatibility params. However, several params like purchaseId, resourceId, projectId, fields aren't given additional semantic context beyond the schema, so it doesn't reach a 5.

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 clear verb+resource: search payments/settlements in BoondManager. The title and description align ('Rechercher des paiements'). It distinguishes well enough from sibling tools like boond_payments_get (which retrieves a specific payment) and boond_payments_create. However, sibling differentiation is implicit rather than explicit — there are many _search tools with similar patterns.

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 gives some context on how to filter (keywords with ACH<id>, CSOC<id>, PRJ<id> format per Boond doc) and mentions the date range and pagination usage. It explains compatibilité for invoiceId/companyId. However, it does not explicitly state when to use this search tool vs the single-get variant, or when not to use it. Usage context is implied but not framed as clear guidance.

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