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

Annotations already indicate this is a write operation (readOnlyHint=false, idempotentHint=false). The description adds no behavioral context beyond stating it creates a request, such as side effects, required permissions, or what happens on success. No contradiction with annotations, but no additional transparency.

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 a single, front-loaded sentence that is concise and free of unnecessary words. It states the core action and the primary object without any 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?

Despite the rich schema, the description is extremely minimal. It gives no indication of what the tool returns (no output schema), does not explain any side effects, and offers no usage context for a create operation. The agent is left without critical information for a complex 9-parameter mutation tool.

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 input schema provides descriptions for all 9 parameters (100% coverage), so the baseline is 3. The description only mentions 'absencesPeriods' without adding detail, and it does not enhance understanding of any parameters beyond 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 clearly states the tool creates a Boond absence request, using the specific verb 'Cree' and the resource 'demande d'absence'. It is unambiguous and aligns with the tool name, but it does not explicitly differentiate from sibling tools like boond_absences_update or boond_absences_delete, so it misses the top score.

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 no guidance on when to use this tool versus alternatives such as boond_absences_update or boond_absences_search. It does not mention prerequisites, constraints, or any context for when a create operation is appropriate.

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

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

Annotations already declare destructiveHint=true. The description adds that the action is irreversible, which is useful context but doesn't go beyond the annotation's destructive indication.

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 short sentences, front-loaded with the action, and contains no waste.

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 a simple one-parameter destructive tool, the description plus annotations and output schema cover the essential information. The irreversibility note addresses a key risk.

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 input schema fully documents the single 'id' parameter with description and pattern, so the description adds no additional parameter semantics.

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 uses the specific verb 'Supprime' (deletes) with the resource 'absence' and system 'BoondManager', clearly distinguishing it from create/update/search siblings.

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 states what the tool does but provides no explicit usage context, exclusions, or alternatives to other absence tools. The 'irréversible' warning implies caution but doesn't guide when to use it instead of update.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no new behavioral traits beyond what the schema and annotations already convey. It is consistent but does not provide extra context such as authentication needs or response shape.

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 exactly one sentence, front-loaded with the action verb, and contains zero redundancy. Every word serves a purpose, making it highly concise and well-structured.

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 simple 1-parameter get-by-ID tool with strong annotations, the description is complete. It tells the agent what the tool does and by what key, while the schema handles parameter details. No output schema exists, but the phrase 'informations detaillees' sufficiently sets expectations. The sibling tool list reinforces the get/search/create/update/delete pattern.

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 description coverage is 100%, and the schema already explains 'id' as a numeric unique identifier. The description restates 'par son ID' without adding syntax or format details. With full schema coverage, the baseline 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 clearly states the tool's function: retrieve detailed information of an absence request by its ID. The verb 'recupere' is specific and the resource 'demande d'absence' is unambiguous. It naturally distinguishes from sibling search/create/update/delete tools by emphasizing retrieval by ID.

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 implies clear usage context: use when you have a specific absence ID and need detailed information. It does not explicitly mention when not to use it or name alternatives, but the 'par son ID' makes the intended scenario evident. This is clear context without exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a useful behavioral detail: 'resourceId est converti en COMP<id>', and specifies the period format YYYY-MM, but does not describe other behaviors like pagination defaults or return structure.

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 brief, well-structured with 'Args:' and 'Returns:' sections, and every line provides value without repeating the schema verbatim. It is front-loaded with the core purpose and then lists parameter details efficiently.

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?

The tool is relatively simple with 7 optional parameters and no required ones. The description covers the overall purpose, mentions the key filter dimensions, and summarizes the return value. With strong annotations and complete schema descriptions, the definition is adequate, though a bit more detail on the return format could be beneficial.

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 description coverage is 100%, giving a baseline of 3. The description adds meaning beyond the schema with the conversion rule 'resourceId est converti en COMP<id>', which is not present in the parameter descriptions. This is a meaningful addition that helps the agent understand how to use the resourceId parameter.

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 'Recherche des demandes d'absence dans BoondManager' with a specific verb ('Recherche') and a clear resource ('demandes d'absence'). It distinguishes from sibling tools like boond_absences_get or boond_absences_create by signaling a search operation with filter criteria.

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?

Usage is implied through the verb 'Recherche' and the list of filter parameters, but there is no explicit guidance on when to use this tool versus alternatives such as boond_absences_get or boond_planning_absences_search. No exclusions or alternative tool names are mentioned.

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

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

The description adds PATCH-like behavior with 'Seuls les champs fournis sont modifies', which is not covered by annotations. It also reinforces that the absence must already exist. Given the annotations already declare non-readonly, non-destructive, and idempotent, this extra context is valuable.

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 short French sentences, front-loaded with the action verb 'Met a jour'. No filler or repetition, achieving maximum clarity in minimal space.

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 simple update tool with 5 parameters, 1 required, no output schema, this description covers the essential behavior. It could mention error cases or response format, but the annotations cover the safety profile, making it adequate for an agent to invoke correctly.

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 each parameter is individually described. The description adds the crucial semantic that omitted parameters are left unchanged, clarifying that optional fields are not reset. This builds on the schema without redundancy.

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 'Met a jour une demande d absence existante' (Updates an existing absence request), clearly identifying the action (update) and resource (absence). 'Seuls les champs fournis sont modifies' further specifies partial update semantics, distinguishing it from create/delete operations.

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 implies this tool is for modifying an already-existing absence, and that only provided fields are changed. It does not explicitly mention alternatives like create or delete, but the 'existing' qualifier gives clear context for when to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no extra behavioral context beyond what annotations and the schema provide, such as return format, permissions, or error behavior. It does not contradict annotations, so a neutral 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?

A single, well-formed sentence communicates the purpose without redundancy. It is front-loaded and every word earns its place, making it highly concise and easy to parse.

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?

Given the tool's low complexity (one parameter, no output schema) and strong annotations, the description is adequate for a simple get-by-ID operation. It clearly states what is returned (detailed information) without needing to enumerate fields. The absence of an output schema is compensated by the ubiquitous getter pattern among sibling tools.

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 description coverage is 100% for the 'id' parameter, with a clear description of it as a numeric unique identifier. The description's phrase 'par son ID' merely restates the schema, adding no new semantic meaning. Baseline of 3 applies because the schema handles parameter documentation well.

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 uses the specific verb 'Récupère' (retrieves) and clearly identifies the resource as 'compte utilisateur' accessed by ID. This distinguishes it from sibling tools like boond_accounts_search, which implies a search operation rather than a direct fetch.

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?

No guidance is given on when to use this tool versus alternatives. The description does not mention boond_accounts_search or other getters, nor any prerequisites or exclusions. The context only implies 'use when you have an ID' without stating it explicitly.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds that it returns a list with ID, name, and details, but discloses no additional behavioral traits like authentication needs or rate limits. The conflicting pageSize limit (100 vs schema's 500) introduces a minor transparency issue.

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 has a clear summary and structured Args/Returns sections, but the Args list redundant with the schema and contains incorrect values. Not as concise as it could be.

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?

The description omits the 'fields' projection parameter and provides wrong pagination limits, leaving the agent with incomplete and partially incorrect contextual information. While the output schema and annotations help, the description's errors make it insufficient for fully understanding the tool's capabilities.

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 input schema covers all four parameters, so baseline is 3. However, the description omits the 'fields' parameter entirely and provides contradictory defaults for pageSize (default 20/max 100 vs schema's default 30/max 500). This actively misleads the agent instead of adding value.

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 the tool searches user accounts in BoondManager by keywords with pagination. The verb 'Recherche' and resource 'comptes utilisateurs' make the purpose unambiguous and distinct from siblings like boond_accounts_get, though it doesn't explicitly name alternatives.

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 no guidance on when to use this tool versus alternatives such as boond_accounts_get for single-account lookups. It lacks any explicit exclusions or context on preferred scenarios.

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

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

The description discloses important behavioral details: the mandatory dependsOn relation, the positioningId requirement for certain action types (with error 422 note), the companyId-only-with-contactId constraint, and the return of the created action with its ID. This extends well beyond the minimal annotations (all false) to give agents actionable expectations.

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 well-structured with a purpose sentence, an args list, and a return statement. It is moderately long but every line adds value, without fluff.

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 create operation with 12 parameters and no output schema, the description covers the core purpose, parameter constraints, API caveats (positioning error), and return behavior. It provides sufficient context for an agent to invoke it correctly, even if it lacks full examples.

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?

Though schema coverage is 100%, the description adds crucial relational semantics not visible in the schema: exactly one of contactId, candidateId, resourceId, opportunityId, or projectId is required, companyId pairs only with contactId, and positioningId is API-required for positioning-linked action types. This elevates it above the schema baseline.

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 it creates a new action (call, email, appointment, note) in BoondManager, specifies the attachable entity types (contact, candidate, resource, opportunity, project), and includes the mandatory dependsOn relation. This distinguishes it from search/get/update/delete siblings.

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 clear context on when to use: creating an action tied to any supported entity, and it notes the mandatory dependsOn relation. However, it does not explicitly name alternative tools or exclusion scenarios, which prevents a 5.

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

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

Beyond the destructiveHint annotation, the description adds that the action is irreversible and that a confirmation may be requested if the MCP client supports elicitation. These are important behavioral details that help the agent manage side effects and user interaction. 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?

The description is extremely concise, front-loaded with the action and resource, and immediately follows with the critical warning about irreversibility and confirmation. Every sentence earns its place without repeating schema or annotation information.

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 simple delete tool with one parameter, the description covers the essential behavioral traits (irreversibility, possible confirmation) and the schema covers the parameter. The presence of an output schema handles return values. Minor omission of related side effects or prerequisites, but sufficient for this straightforward 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?

The schema already fully describes the only parameter 'id' with a numeric pattern and a clear description. The tool description does not add any additional semantic value for the parameter. 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 clearly states the tool deletes an action from BoondManager ('Supprime une action de BoondManager'), using a specific verb and resource. It distinguishes this from other delete tools for different entities (e.g., boond_candidates_delete) by specifying 'action'. The title reinforces but the description adds the BoondManager context.

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?

No explicit when-to-use or alternatives are provided, but the delete semantics imply usage when an action needs to be removed. The description does not contrast with boond_actions_update or boond_actions_get, leaving selection to the agent's reasoning based on the clear purpose.

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

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

Les annotations indiquent déjà que l'outil est en lecture seule, idempotent et non destructif. La description n'ajoute aucune information comportementale supplémentaire, comme le format de retour, les erreurs possibles ou les autorisations requises. Elle se contente de reformuler l'action.

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?

La description est une phrase unique, directe, sans mots superflus, et place l'information essentielle en tête. Elle est parfaitement concise.

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?

Pour un outil de récupération par ID avec un seul paramètre et d'excellentes annotations, la description est suffisante pour une utilisation de base. Elle aurait pu explicitement mentionner que la réponse contient les détails complets de l'action, mais cela reste implicite et la complexité est faible.

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?

Le schéma fournit une description complète du paramètre 'id' (type, motif, description). La description de l'outil n'apporte aucune précision supplémentaire sur le paramètre, donc la note de base de 3 s'applique car la couverture du schéma est de 100 %.

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?

La description utilise le verbe 'récupère' avec une ressource précise ('une action') et un critère clair ('par son ID'). Elle distingue bien cet outil des frères comme 'boond_actions_search', 'create', 'update' et 'delete'.

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?

L'usage est implicite : on comprend qu'il faut avoir l'ID d'une action pour obtenir ses détails. Cependant, aucune alternative n'est mentionnée (par exemple, utiliser 'boond_actions_search' pour trouver l'ID), ni de contexte d'exclusion. Le guidage est minimal.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds that it returns a list of matching actions, which is useful but does not disclose pagination behavior, field projection effects, or what constitutes the standard summary. This is adequate but not rich.

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 concise: a one-sentence summary, a bulleted Args list, and a Returns line. It is front-loaded and every sentence adds value without unnecessary verbiage.

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 8 parameters and no output schema, the description provides a basic list of arguments and a vague return description ('Liste des actions correspondantes'). It omits the 'fields' projection parameter from its Args list and does not explain default behavior (e.g., if no filters, all actions are returned). This leaves gaps for an agent to fully understand the tool's capabilities.

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 description coverage is 100%, so parameters are already well documented. The description repeats the purpose of keywords and entity IDs, but omits the 'fields' parameter entirely and adds no extra syntax or format details. This aligns with the baseline of 3.

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 the tool searches actions (calls, emails, appointments, notes) in BoondManager with optional filters. This differentiates it from sibling tools like boond_actions_get (retrieve a single action) and boond_actions_create/update/delete.

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 implies usage via optional filters by candidate, resource, contact, or company, indicating when this tool is appropriate. However, it does not explicitly state when to prefer this over alternatives or provide exclusions, so it stops short of a perfect score.

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

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

The description reveals important behavioral traits not covered by annotations: partial PUT semantics, preservation of relations (dependsOn, positioning, calendar sync), and that text replaces existing content rather than appending. It also warns against a destructive alternative. This is substantial added context beyond the structured fields.

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 well-structured with a concise summary, a warning note, a clear parameter list, and a return statement. It is appropriately sized for six parameters and every sentence contributes essential information without redundancy.

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 a full input schema, output schema, and annotations, the description still adds key operational context (partial update, no relations sent, calendar preservation) that structured data does not convey. The tool is fully specified and the description rounds out the behavioral story.

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 description coverage is 100%, so the schema already documents every parameter including typeOf's dictionary reference and date formats. The description restates the parameter list and adds the general partial-update note, but does not provide significant new meaning per parameter beyond what the schema already offers.

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 the tool 'Met à jour une action existante' (updates an existing action) in BoondManager, specifying it is a partial PUT where only provided fields are modified. This distinguishes it from create/delete tools and explicitly names the target resource.

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 explicit guidance on when to use this tool: it is 'Idéal pour ajouter un compte-rendu sans casser l'agenda' and contrasts directly with 'delete + recreate' which would delete the calendar event. It also explains that no relations are sent, preserving dependencies and scheduling, making the usage context clear.

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

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

Annotations already disclose read-only, idempotent, and non-destructive behavior. The description adds that it returns 'informations détaillées' but does not describe error handling, permissions, or the exact structure of the response. Beyond annotations, it provides minimal behavioral context.

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 a single, front-loaded sentence that directly states the tool's purpose without any redundant phrasing. Every word contributes to understanding.

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 simple single-ID retrieval tool with annotations and a fully described parameter, the description conveys the core behavior sufficiently. However, it lacks any indication of what 'détails' includes in the absence of an output schema, which could be slightly more explicit.

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 input schema fully covers the single parameter 'id' with a description and pattern. The tool description does not add any additional meaning beyond what the schema already provides, so 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 uses a specific verb ('Récupère') and names the resource ('avantage') with a clear scope ('par son ID'). It distinguishes this tool from sibling search tools like boond_advantages_search and resource-specific endpoints.

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 implies usage when you have an ID and need a single advantage's details, but it does not explicitly state when to use it versus alternatives like boond_advantages_search. No alternative tools or exclusions are mentioned, so guidance is only implicit.

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

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

Annotations (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false) already cover the safety profile. The description adds a minimal 'Returns: Liste des avantages correspondants' but does not disclose pagination behavior, response format details, or any rate limits. It adds some context beyond annotations but not significant behavioral depth.

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 concise with a clear structure: a one-sentence summary, an Args list, and a Returns line. The Args list is redundant with the schema, but it is organized and easy to scan. It earns high marks for clarity, though it could trim redundant parameter repetition.

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 read-only search tool with comprehensive schema coverage, the description is adequate but not complete. There is no output schema, and the Returns line is vague ('Liste des avantages correspondants') without specifying the structure or whether standard summary fields are included. The schema's 'fields' description hints at a 'standard summary', but the description itself does not clarify return expectations. Given the low complexity, a 3 is fair.

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 description coverage is 100%, so the baseline is 3. The description repeats the keywords, resourceId, and pagination params but adds no new meaning beyond the schema. It omits the 'fields' parameter entirely, but since the schema fully documents it, the description does not need to compensate. The redundancy means no added value.

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 the tool searches for benefits (avantages) in BoondManager, with examples (tickets restaurant, mutuelle, véhicule, primes) and an optional resource filter. This is a specific verb+resource+scope that distinguishes it from sibling tools like boond_advantages_get (a getter) and boond_resources_advantages (resource-specific).

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?

No guidance is given on when to use this search tool versus alternatives. The sibling list includes boond_resources_advantages and boond_advantages_get, but the description does not mention when to prefer this tool or any exclusion criteria. The 'optional resource filter' hint is implicit usage, not explicit comparative guidance.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds that it retrieves 'detailed information', which is consistent but not significantly more specific. No additional behavioral traits such as response format or error conditions are disclosed, but the annotations cover the essential safety profile.

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 a single, concise sentence that immediately communicates the purpose. No unnecessary words or repetition; it earns its place.

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 simple retrieval by ID with a single parameter and no output schema, the description provides all necessary context. The tool is a straightforward getter, and the description is complete enough for an agent to select and invoke it correctly.

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 input schema already describes the 'id' parameter fully (numeric identifier). The description echoes 'by its ID' but adds no new semantic meaning beyond the schema, and schema coverage is 100%, so baseline 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 uses a specific verb 'Récupère' and clearly states the resource ('agence') and access method ('par son ID'). This clearly distinguishes it from the sibling search tool (boond_agencies_search) and other entity-specific get tools.

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 clearly implies the tool should be used when you have an agency ID and need its detailed information. It does not explicitly mention alternatives or exclusions, but the 'by ID' context makes the use case unambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds return-value information (list with ID, name, main details) and pagination, but does not disclose additional behavioral constraints beyond existing annotation coverage. 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?

The description is moderately concise but the Args section is redundant with the schema and contains factual errors about pagination limits. The structure is clear, but inaccuracies undermine its value, so it does not earn a higher score.

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?

The output schema exists and annotations are present, so a brief description would suffice. However, the inconsistent pageSize defaults/max and omission of the 'fields' parameter create confusion, leaving the tool less complete than the bare schema alone.

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 has 100% coverage, but the description's Args section misstates pageSize (default 20, max 100 vs schema's default 30, max 500), omits the 'fields' parameter entirely, and adds no meaningful detail beyond what schema already provides. This actively harms parameter understanding.

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 the tool searches agencies in BoondManager by keywords with pagination, using a specific verb (Rechercher) and resource (agences). It distinguishes itself from siblings like boond_agencies_get, which presumably fetches a single agency.

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 implies usage for keyword-based search but does not explicitly mention when to prefer this over boond_agencies_get or mention exclusions. No alternative tools are named, so guidelines remain implicit.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context about the returned data (profile, permissions, agency) and specifies the return format (JSON). No contradictions 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?

The description is two sentences, front-loaded with the action and resource, and includes a brief return note. No fluff or redundant statements.

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 simple zero-parameter read-only tool, the description is adequate: it explains what is returned and provides examples. Without an output schema, it gives a clear idea of the payload, though a full field list is absent.

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 tool has zero parameters, so the schema covers everything. The description does not need to explain parameters. Baseline for 0 params is 4, and no additional semantic info is required.

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 the tool retrieves the currently connected BoondManager user's information, with examples (profile, permissions, agency). It uses a specific verb (récupère) and resource, distinguishing it from other user/resource tools.

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 context is clear: this is for the current authenticated user. However, it does not explicitly mention when to use it versus alternatives (e.g., searching for users). No exclusions or alternative tools are referenced.

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

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

Beyond the readonly and idempotent annotations, the description explains caching (TTL 1h, configurable), subtree extraction behavior, return shape, and the isError flag for invalid paths. This gives an agent essential context about data freshness and error handling.

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 purpose is front-loaded, followed by logical sections for path pattern, examples, and a critical note. While the example list is extensive, each example is instructive and the warning about legacy syntax justifies the length.

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 one-parameter, read-only tool with no output schema, the description covers return values, error behavior, caching, and path semantics thoroughly. It is complete enough for an agent to invoke the tool correctly without additional assumptions.

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 description greatly enriches the minimal schema by explaining that dictionaryType is a dotted path relative to 'data' and listing numerous valid examples. It also explicitly corrects the outdated slash syntax found in the schema, preventing likely misuse.

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 the tool retrieves a BoondManager reference dictionary, listing specific categories and the dedicated endpoint. This distinguishes it from all sibling entity-specific tools.

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 implies usage for any reference data lookup and provides explicit guidance on correct path syntax, including a warning about the invalid legacy slash format. It does not explicitly exclude alternative entity tools, but none serve this purpose.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral details beyond saying 'detailed information', such as return format, error behavior, or permissions. It is consistent with annotations but does not go further.

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 a single, clear, front-loaded sentence with no wasted words. It efficiently states the action, resource, and parameter.

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 simple get-by-ID tool with one parameter, good annotations, and no output schema, the description is mostly sufficient. It clearly indicates the purpose, but it does not explicitly describe the return shape or mention the search sibling for locating IDs, leaving a small completeness 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 description coverage is 100% and the single 'id' property is already well-described in the schema as a numeric identifier. The description only repeats 'by its ID' without adding extra meaning, so it meets the baseline but does not exceed it.

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 uses a specific verb ('Récupère') and resource ('business unit') with a clear scope ('par son ID'), which clearly distinguishes it from the sibling search tool (boond_business_units_search). It directly states what the tool does.

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 implies it is for fetching a single business unit given an ID, but it does not explicitly mention when to use it versus the sibling search tool or any exclusions/alternatives. The usage context is clear but not explicitly differentiated.

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

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

Annotations cover read-only, idempotent, open-world, and non-destructive behavior. The description adds pagination details but these are contradictory to the input schema: it states pageSize default/max as 20/100 while the schema declares 30/500. This is misleading and reduces transparency. It also omits the 'fields' parameter entirely, giving an incomplete behavioral view.

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 short and front-loaded with a clear summary, but the Args section largely duplicates schema information and includes an inaccuracy. The Returns line is helpful but the overall structure could be tighter without the redundant parameter listing.

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?

Given the tool has an output schema and annotations, the description could rely on those, but it still provides inconsistent pagination info and omits 'fields'. It also does not clarify how this search tool relates to boond_business_units_get. These gaps make it incomplete for an agent to confidently invoke the tool correctly.

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 baseline is 3. The description adds value for 'keywords' with examples (nom, email, compétences) and clarifies pagination defaults, but it contains incorrect pageSize values and completely omits the 'fields' parameter. Thus it neither fully compensates nor significantly degrades clarity beyond 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 clearly states the tool does a keyword-based search of business units in BoondManager with pagination. This distinguishes it from the sibling tool boond_business_units_get (which presumably retrieves a single business unit) and other entity-specific searches like boond_opportunities_search or boond_resources_search.

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 no guidance on when to use this tool versus alternatives. It does not mention the existence of boond_business_units_get or any other search tools, nor does it state when not to use this tool. Though the name implies search, there is no explicit usage context or exclusions.

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

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

Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds no additional behavioral context (e.g., response format or data included), but it does not conflict with annotations. The safety profile is fully covered by annotations, so a middle 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 a single, concise sentence that immediately states the action, resource, and key parameter. There is no wasted wording or unnecessary detail.

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 simple get-by-ID tool with one parameter, strong annotations, and no output schema, the description is sufficient. It clearly conveys the tool's purpose without omitting critical information needed for selection or invocation.

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 provides full coverage for the single id parameter with a clear description. The tool description adds no extra meaning beyond the schema, and the schema already defines the pattern and type. Given 100% schema coverage, the baseline of 3 applies.

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 uses the specific verb 'Récupère' (retrieves) with a clear resource 'calendrier' and scoping 'par son ID'. This distinguishes it from the sibling boond_calendars_search, which is implied to be for searching without an ID.

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 phrase 'par son ID' clearly indicates the tool is for retrieving a specific calendar when the ID is known. Though no alternative is explicitly named, the intended use context is unambiguous, and the sibling search tool is clearly the alternative for finding IDs.

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

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

The description introduces inaccurate behavioral details: it states pageSize has a default of 20 and max of 100, whereas the schema specifies default 30 and max 500. This could mislead an agent about response limits. It also omits the 'fields' projection parameter. While annotations cover read-only and idempotent behavior, the description adds misleading pagination info, which is a transparency failure.

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 short, well-structured with an overview, args list, and returns statement. It is front-loaded with the core purpose. However, it includes redundant parameter details that conflict with the schema, which slightly reduces efficiency, but the overall format remains concise.

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?

Given that the schema provides full parameter descriptions and an output schema exists, the description could be minimal, but it still misses the 'fields' parameter and provides incorrect pagination bounds. This creates an incomplete and slightly inconsistent picture, though the core functionality is adequately conveyed.

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 description coverage is 100%, so the baseline is 3, but the description does not add meaningful value beyond the schema. It repeats keywords and page defaults mostly as-is, but gives conflicting pageSize limits and completely omits the 'fields' parameter. The description's incorrect parameter metadata actively harms understanding rather than clarifying it.

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 the tool searches calendars in BoondManager by keywords with pagination, and specifies it returns a list with IDs, names, and main details. This is a distinct search operation compared to the sibling tool boond_calendars_get, which retrieves a single calendar.

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 implies this tool is for keyword-based searches and mentions pagination, but it does not explicitly state when to use this tool versus boond_calendars_get or any other alternative. There are no exclusions or alternative tool references, leaving usage to be inferred from the name and generic search behavior.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is known. The description adds the types of actions included (appels, emails, RDV, notes) but does not disclose other behavior such as pagination, ordering, or potential errors.

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 concise and well-structured, with a clear main sentence followed by Args and Returns sections. Every sentence is useful and there is 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?

The tool is simple (single parameter, read-only, no output schema). The description states what it returns (list of actions) and even lists example types, which is adequate for a basic retrieval operation. Minor missing details like sorting or pagination are not critical here.

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% with a parameter description. The description restates that 'id' is the candidate ID, slightly clarifying the generic schema phrase 'entité BoondManager', but adds minimal extra meaning beyond what the schema already provides.

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 uses the specific verb 'Récupère' (retrieves) with the resource 'actions associées à un candidat' and lists examples (appels, emails, RDV, notes). This clearly distinguishes it from sibling tools that operate on other entities or actions in general.

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?

It clearly implies this tool is for fetching actions tied to a specific candidate, which provides context on when to use it. However, it does not explicitly mention alternatives or exclusion criteria, e.g., when to use boond_actions_search instead.

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

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 no extra behavioral context such as return format, error behavior, authentication requirements, or data sensitivity. It merely repeats the tool's purpose without value beyond 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 very short and front-loaded, with a one-sentence purpose and an args/returns structure. However, the 'Returns' line simply repeats the purpose, and the 'Args' block duplicates the schema, introducing minor redundancy.

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 simple read-only getter with one parameter and good annotations, the description is reasonably complete. However, without an output schema, it fails to clarify what 'administrative data' includes, which could lead to ambiguity when choosing among similar candidate endpoints. Slightly more specificity would improve completeness.

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 fully documents the single 'id' parameter (string, numeric pattern, unique identifier). The description's 'ID du candidat' adds only a slight clarification that it refers to a candidate ID, which is already obvious from the tool name. With 100% schema coverage, the baseline is 3.

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 the tool retrieves administrative data for a candidate using a specific verb ('récupère') and resource. However, it does not distinguish this from sibling tools like boond_candidates_information or boond_candidates_technical_data beyond the word 'administrative', which is a clear but unstated differentiation.

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?

No guidance is given on when to use this tool versus alternatives. The intended use is only implied by the name/title, and the description offers no exclusions, prerequisites, or comparisons to sibling candidate endpoints.

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

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

The description adds the return note 'Returns: Données du/de la candidat créé(e) avec son ID', which is useful context beyond annotations. It does not mention side effects or prerequisites, but annotations already indicate a non-read-only operation, so the bar is lower.

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 extremely concise: one sentence for the main purpose and a short line for the return value. No wasted words, front-loaded with action.

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?

Given the full schema and presence of an output schema, the description is adequately complete. It covers what the tool does and what it returns, though it could mention that only firstName and lastName are required or distinguish from update/delete.

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 input schema has 100% description coverage for all 10 parameters. The description does not add any parameter-specific meaning, but baseline 3 is appropriate given the high schema coverage.

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 'Crée un(e) nouvel(le) candidat dans BoondManager', specifying the action (create) and resource (candidate). It distinguishes from sibling tools like boond_candidates_update or boond_candidates_delete through the verb 'create', though it is close to restating the title.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention that update should be used for existing candidates or search for finding candidates. The context is only implied by the action verb.

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

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

Annotations already indicate destructiveHint=true, but the description adds important context: the action is irreversible and confirmation may be requested. This goes beyond annotations without contradicting them.

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 concise, front-loaded with the action, and includes a clear warning. The Args section is redundant but not wasteful. Every sentence serves a purpose.

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 simple delete tool with one parameter, good annotations (destructiveHint), and an output schema, the description is complete. It covers irreversibility and confirmation behavior, and no additional return-value details are needed.

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 covers the 'id' parameter 100%, including its pattern and description. The description repeats the parameter without adding meaningful new semantics, so it adds minimal value beyond 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 clearly states the tool's function with 'Supprime un(e) candidat de BoondManager' (deletes a candidate), using a specific verb and resource. This distinguishes it from sibling tools that delete other entity types.

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 implies usage for deleting candidates but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. The irreversibility warning and elicitation note give some context but not enough for a 4.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context by noting the optional tab can return specific sub-data and that the response is complete JSON, which goes beyond the structured 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 a clear purpose sentence, but the 'Args' section duplicates the schema in near-identical wording, wasting space. The 'Returns' line is useful but the overall structure includes redundancy that could be trimmed.

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 simple get-by-id tool with full schema coverage and strong annotations, the description is largely complete. It covers the main behavior, optional tab feature, and return type. It does not detail error conditions or auth, but those are not critical given the tool's simplicity and annotation coverage.

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 description coverage is 100%, with clear descriptions for both id and tab. The description repeats these argument definitions almost verbatim, adding no additional meaning or context beyond what the schema already provides, so 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 clearly states the tool retrieves detailed information for a candidate by ID, with an optional tab parameter. It distinguishes from search tools by requiring an ID and covers the specific tab siblings by naming them explicitly.

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?

No guidance is provided on when to use this tool versus alternatives like boond_candidates_search or the specialized tab tools (boond_candidates_information, boond_candidates_technical_data, etc.). The optional tab list implies flexibility, but no explicit direction or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a list of return fields (contact info, address, photo, tags, source) which is useful context, but does not go beyond annotations with additional behavioral details such as response format or edge cases.

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 extremely concise with one sentence of purpose and a short Args/Returns block. Every line serves a purpose, and it is well-structured with no filler or redundant content.

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 simple read-only endpoint with a single parameter and strong annotations, the description adequately covers the purpose, parameter, and a general overview of return data including example fields. Although there is no output schema, the description provides enough context for an agent to understand what the tool returns, though more detail on response structure could be beneficial.

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 input schema provides 100% coverage with a detailed description for 'id' as a numeric unique identifier. The description's Args section merely repeats 'id' without adding new meaning, so the schema already carries the semantic load. Baseline 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 clearly states that the tool retrieves general candidate information, listing specific fields like coordonnées, adresse, état civil, photo, tags, and source. The verb 'Récupère' and resource 'candidat' make the action specific, but it does not explicitly distinguish from sibling tools such as boond_candidates_get.

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 no guidance on when to use this tool versus sibling alternatives like boond_candidates_get, boond_candidates_administrative, or boond_candidates_technical_data. It only states what the tool does without any context on selection criteria.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safe read nature is covered. The description adds only that it returns a list, which is already evident from 'Récupère' and the Returns line. It does not disclose any additional behavioral traits such as pagination, ordering, or potential empty results beyond what annotations imply.

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 short and front-loaded, with a clear purpose sentence. The Args/Returns section is structured and minimal. Minor redundancy: 'Returns: Liste des positionnements' restates what 'Récupère' already implies, but overall it is efficient.

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 simple read-only list tool with one well-documented parameter and full annotation coverage, the description provides enough information. It explains the resource type and return format, though it could note that the list might be filtered/detail-free. No output schema exists, but the return list is described sufficiently.

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% and the schema already thoroughly documents the 'id' parameter with type, pattern, and description. The description merely repeats the parameter name and type, adding no extra semantic value over 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 uses a specific verb 'Récupère' and names the exact resource: 'les positionnements (placements sur des opportunités/projets) d'un candidat'. It disambiguates from sibling tools like boond_candidates_get (gets candidate info) and boond_positionings_get (general positionings) by scoping to a specific candidate.

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 implies usage (when you need a candidate's positionings) but does not explicitly contrast with alternatives like boond_positionings_search or boond_candidates_get. There is no direct 'use this when' guidance, only the inherent purpose from the name and description.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds behavioral details beyond these: default keyword search behavior (resumeTd), AND/OR logic for tools via '#AND#', perimeterDynamic shortcuts, and the requirement to combine coordinates/location with geoDistance. No contradictions 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?

Although long, the description is well-structured with bullet points and bold category headers. It front-loads the core purpose and each section covers a coherent filter group. For a tool with 36 parameters, this level of detail is warranted and every sentence contributes practical guidance without redundancy.

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?

The description covers all major filter categories, pagination, sorting, and return type, and directs users to complementary tools for candidate details. Combined with the 100% schema coverage and output schema, it provides complete guidance for an AI agent to select and invoke the tool correctly.

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%, but the description substantially enriches parameter meaning with real-world usage examples: perimeterDynamic values for 'Mes candidats', perimeterManagersType main/hr distinction, languages format ('langueId|niveauId'), tools AND/OR syntax, and period combinations. It also links parameters to dictionary lookups, adding practical value beyond 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 specific verb+resource+scope: 'Recherche des candidats dans BoondManager avec filtres serveur.' It clearly identifies the tool as a server-filtered candidate search, distinguishes it from boond_candidates_get by recommending that tool for detail, and states the return type (paginated list).

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 extensive usage contexts for common scenarios (perimeter, states, technical profile, sourcing, period, keyword search, geolocation) and explicitly mentions alternatives for detail retrieval ('Utiliser boond_candidates_get ou les outils d'onglets pour le détail'). It also references supporting tools like boond_application_dictionary and boond_application_current_user for ID lookups, giving clear when-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is disclosed. The description adds context about the data payload scope (technical skills, resume) and does not contradict the 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 concise, with a single clear sentence and compact Args/Returns format. Every part is informative and directly useful, with no redundancy or 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?

The tool has a single parameter and no output schema. The description lists the major content categories returned but does not describe response structure or potential error conditions. For a simple read operation with strong annotations, this is adequate but not fully complete.

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 input schema already fully documents the 'id' parameter with type string and pattern for numeric digits, offering 100% coverage. The description merely restates 'ID du candidat', adding no new semantic information beyond what the schema provides.

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 uses the specific verb 'Récupère' (retrieves) and identifies the resource as the technical profile of a candidate, enumerating content areas (skills, experiences, training, certifications, languages, CV). This clearly differentiates it from sibling tools like boond_candidates_information or boond_candidates_administrative.

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 implies usage when a candidate's technical profile is needed but does not explicitly state alternatives or when-not-to-use. It does not mention that boond_candidates_get might return basic info or that boond_candidates_information covers other aspects, leaving the choice to the agent's inference.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, covering the mutation and safety profile. The description adds valuable context beyond annotations: the partial-update semantic ('Seuls les champs fournis sont modifiés') and the return value ('Données mises à jour'). This is meaningful behavioral disclosure without violating 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 extremely concise: two sentences plus a return line. It front-loads the action with a specific verb and resource, then adds the critical partial-update detail. Every sentence serves a purpose with no filler or redundancy.

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 tool with 11 parameters, 1 required, full schema coverage, and an output schema, the description covers the core purpose, the partial-update behavior, and the return value. Annotations handle idempotency and destructive hints. It does not mention error cases or authentication, but these are not essential for a well-specified update operation, so it is nearly complete.

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 input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds the key insight that only provided fields are modified, which is a parameter-level behavior not captured in the schema. This clarifies how to interpret all optional parameters and justifies a score above baseline.

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 the action: 'Met à jour un(e) candidat existant(e) dans BoondManager' (Updates an existing candidate). It uses a specific verb and resource, and explicitly mentions 'existant(e)' to distinguish from create/delete. This differentiates it from sibling tools like boond_candidates_create and boond_candidates_delete.

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 clear context that this tool is for updating an existing candidate, implying it should not be used for creation or deletion. It also specifies partial-update behavior ('Seuls les champs fournis sont modifiés'), which guides when and how to use it. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds context by listing the action types (calls, emails, appointments, notes) and the return format, but it does not disclose additional behavioral traits like pagination or ordering.

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 concise, starting with a clear sentence, followed by an Args section and a Returns line. Every sentence adds value and there is no redundancy or wasted words.

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 simple read-only retrieval tool with one parameter and no output schema, the description adequately covers purpose, parameter, and return type. It could mention pagination or filtering, but the tool's simplicity means the current level is nearly complete.

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 description coverage is 100%, with the schema already fully explaining the 'id' parameter as a numeric BoondManager entity identifier. The description's 'ID de la société' adds little beyond the schema, so 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 clearly states 'Récupère les actions (appels, emails, RDV, notes) associées à une société' with a specific verb (Récupère) and resource (actions for a company), distinguishing it from sibling tools like boond_contacts_actions or boond_opportunities_actions. The scope is unambiguous.

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 implies usage for retrieving actions linked to a company, but it does not explicitly mention alternatives such as boond_actions_search or provide when-not-to-use guidance. The context is clear but not comparative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read. The description adds that it returns a list of contacts, consistent with the read-only annotation. It does not disclose additional behaviors like pagination or response structure, but given the annotations, this is acceptable.

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 three short lines: a one-sentence purpose, an args list, and a returns statement. It conveys all necessary information without waste, front-loading the primary action first.

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?

This is a simple one-parameter read-only tool. The description specifies the input (company ID) and output (contacts list) sufficiently. Without an output schema, the return statement provides basic information. It doesn't address edge cases like empty lists or errors, but the low complexity keeps this adequate.

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% for the single 'id' parameter, and the schema already describes it as a numeric BoondManager entity identifier. The description's 'ID de la société' adds a slightly clearer domain context but does not introduce new semantics like format or constraints. Baseline 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 clearly states: 'Récupère les contacts associés à une société' – a specific verb (récupère) and resource (contacts of a company). This distinguishes it from sibling tools like boond_companies_get (company details) or boond_contacts_get (single contact), as it focuses specifically on retrieving the contact list for a given company.

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 implies when to use: when you have a company ID and need its associated contacts. It lists the required 'id' parameter as 'ID de la société'. However, it does not explicitly discuss alternatives or exclusions, such as using boond_contacts_search for broader contact searches. Thus usage is implied rather than explicit.

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

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

Annotations indicate readOnlyHint=false, confirming a write operation, and the description aligns with this by saying 'Crée'. The description adds the return behavior (data with ID), but provides no additional context on side effects, required permissions, or edge cases. It does not contradict the annotations, but it does not enrich them significantly.

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 extremely concise: two short sentences that immediately state the action and the return value. It is front-loaded and contains no redundant information, making it easy for an agent to parse quickly.

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?

Given the tool has 9 parameters and an output schema, the description is minimally sufficient but lacks contextual guidance such as which fields are required or any business rules around company creation. The input schema covers required fields, but the description does not reinforce or explain them, leaving the agent to rely entirely on schema and annotations.

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 description coverage is 100%, with each parameter having a basic label (e.g., 'Ville', 'Nom de la société'). The description does not add further meaning to the parameters beyond what the schema already provides, so 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 clearly states the tool's action: 'Crée un(e) nouvel(le) société dans BoondManager' (creates a new company in BoondManager). It uses a specific verb ('Crée') and resource ('société'), and explicitly mentions the return of the created entity with its ID, which distinguishes it from sibling tools like search, get, update, or delete.

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 implies usage for creating a new company but provides no explicit guidance on when to use this tool versus alternatives (e.g., update for existing companies). No conditions, prerequisites, or exclusions are stated, leaving the agent to infer context from the tool's name and basic action.

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

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

Annotations already mark destructiveHint=true, and the description adds an explicit irreversibility warning and explains that confirmation is requested when the MCP client supports elicitation. This adds behavioral context beyond the annotations, though it doesn't address cascading effects or error states.

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 short, front-loaded with purpose, and includes the warning and confirmation behavior. The Args list is minimal and necessary. No redundant content.

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 simple one-parameter delete tool with annotations and output schema, the description covers purpose, irreversibility, and confirmation behavior. It lacks details on cascading deletions or error states, but these are not essential for basic use.

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 description's Args section restates the id parameter, but the input schema already provides fuller information (unique, numeric pattern). With 100% schema coverage, the description adds limited value beyond 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 clearly states 'Supprime un(e) société de BoondManager' with the verb 'Supprimer' and resource 'société', distinguishing it from sibling delete tools for other entities (candidates, resources, opportunities). The title and description are fully aligned.

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 use case is clear: use when deleting a company. The description does not explicitly mention alternatives, but the purpose is unambiguous. It also provides context about confirmation behavior via elicitation, which helps set expectations for usage.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds that it returns complete JSON data and supports optional tabs, which is some behavioral context, but it doesn't go beyond that or contradict 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 compact and front-loaded with the main action and resource. However, the Args section duplicates the schema, adding some redundancy, so it's not perfectly optimized, but still efficient.

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 simple get-by-ID tool with strong annotations, the description covers purpose, parameters, and return type. It lacks details on error handling or the relationship to specialized endpoints like boond_companies_information, but is adequate for most use cases.

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 description coverage is 100% with both id and tab described. The description repeats these args without adding new semantics, so it provides no value beyond what the schema already documents. 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 clearly states it retrieves detailed information for a company by ID, with optional tabs (information, technical, financial, actions, contracts, documents). This specific verb+resource combination distinguishes it from search and other entity-specific get tools, even though it doesn't explicitly name alternatives.

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?

It provides clear context: use this when you have a company ID and want detailed information, optionally specifying a tab. It doesn't mention when not to use it or name alternative tools, but the prerequisite of having an ID is implied and the optional tab guidance is helpful.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat safety traits. The description's 'Récupère' aligns with annotations but adds no additional behavioral context such as permissions, rate limits, or response format details.

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 concise and front-loaded, using a clear Args/Returns structure. Every sentence conveys necessary information without waste, and the field examples provide useful detail in a compact format.

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 simple read-only tool with one parameter and strong annotations, the description is mostly complete: it states purpose, lists expected field categories, and mentions return data. However, it does not detail the exact response structure or any edge-case behavior, leaving minor gaps.

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 description coverage is 100%, with the 'id' parameter fully documented as a unique numeric entity identifier. The description's 'id (string): ID de la société' is redundant and adds no new meaning beyond 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 clearly states the tool retrieves general company information, listing specific examples (coordonnées, SIRET, site web, secteur, taille, tags). It uses a specific verb+resource structure, but does not explicitly distinguish itself from sibling tool boond_companies_get, so it lacks full differentiation.

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 guidance on when to use this tool versus alternatives, no mention of exclusions or prerequisites, and no reference to sibling tools. The description only states what it does and its parameters, providing no usage context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so there is no contradiction. However, the description adds no behavioral context beyond the purpose, such as filters, pagination, sorting, or scope of invoices included. It only mentions the return type.

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 highly concise with a clear structure: a one-line purpose, an Args block, and a Returns line. Every part is necessary and there is no redundant information.

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 simple one-parameter read operation with robust annotations, the description is minimally acceptable. It states purpose and return type, but lacks usage guidance and clarification of invoice scope. Given many related invoice tools, the absence of alternative pointers leaves a 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?

The input schema has 100% description coverage for the id parameter ('Identifiant unique de l'entité BoondManager'). The description adds 'ID de la société', which clarifies the role but not any new semantic meaning beyond the schema. Baseline 3 applies.

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 specific verb and resource: 'Récupère les factures d'une société' (retrieves invoices of a company). It is clearly distinguished from global invoice search/get tools, though it doesn't explicitly differentiate from provider invoices (boond_companies_provider_invoices).

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?

No usage guidelines are provided. The description does not indicate when to use this tool versus boond_invoices_search, boond_invoices_get, or boond_contacts_invoices, nor any exclusions or prerequisites.

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