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

Beyond the annotations, the description discloses meaningful behavioral traits: the state parameter is subject to BoondManager's validation workflow and the request starts in its initial state, and the write is explicitly non-idempotent with no deduplication. This is valuable context that annotations alone do not provide.

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 clear 'Quand', 'Plutôt que', bullet points, and a Returns line. Every section earns its place, and the most decision-relevant information is front-loaded.

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 9-parameter creation tool without an output schema, the description adequately covers the key behaviors, parameter subtleties, non-idempotence, workflow implications, and return value. The schema documents the remaining parameter details, so no critical context is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: absencesPeriods can be omitted and a single period is inferred from startDate/endDate, and state is not directly applied but submitted to workflow. This raises the 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 opens with a specific verb and resource: 'Crée une demande d'absence' for a resource, and lists absence types. It also explicitly contrasts this with boond_absences_update, making the tool's purpose and scope immediately distinguishable from its 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 'Quand' section states exactly when to use the tool: to submit an absence for a resource identified by ID. The 'Plutôt que' section explicitly names boond_absences_update as the alternative for modifying an existing request, giving clear routing 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?

Although destructiveHint is already true, the description adds meaningful behavioral nuance: deletion is irreversible with no trashbin on the API side, an elicitation-capable MCP client will request user confirmation and can return deleted:false with a reason, and otherwise the deletion proceeds immediately. This enriches the annotations rather than merely repeating 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 compact and front-loaded, starting with a clear one-sentence purpose, then using bullets for usage conditions, alternatives, safety warnings, and return semantics. Every section contributes necessary information with no filler or 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 single-parameter destructive delete tool with annotations and an output schema, this description is complete: it defines the trigger condition, the safer alternative, the irreversible behavior, the confirmation mechanism, and the meaning of the response field. Nothing an agent needs to call it correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single id parameter is fully documented in the input schema with a numeric pattern and description, giving 100% coverage. The description does not add much parameter-specific meaning beyond advising ID verification with boond_absences_get, which is operational context but not new syntax or constraints.

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 precise verb and resource: 'Supprime définitivement un(e) demande d'absence de BoondManager.' It then explicitly contrasts this tool with boond_absences_update, making it easy for an agent to distinguish destructive deletion from non-destructive state changes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Quand' section states that the tool should only be used when the user explicitly asks to delete and after the ID has been verified via boond_absences_get. The 'Plutôt que' section names boond_absences_update as the preferred alternative when only disabling or modifying an absence is desired, so the when-not-to-use guidance is 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 already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat that. It adds valuable behavioral context by noting that an unknown ID returns the raw BoondManager error, and that the response is a JSON entity with attributes and relations. This goes beyond annotations and helps the agent anticipate error behavior and response 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 compact and every sentence contributes value: main action, when to use, when not to use, a warning, and return format. The purpose is front-loaded, and there is no redundant or filler content. It is well-structured for quick agent parsing.

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 single-parameter get-by-ID tool with high schema coverage and no output schema, the description is sufficiently complete. It explains the return type (JSON entity with attributes and relations) and error behavior. It doesn't list specific fields, but that is acceptable given the typical nature of such tools and the absence of an output schema.

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 the id parameter described as 'Identifiant unique de l'entité BoondManager (numérique).' The description adds further meaning by explicitly stating the ID must be numeric and must come from boond_absences_search, not guessed. This enhances the schema's baseline and provides necessary usage nuance.

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 specific verb and resource: 'Récupère la fiche complète d'un(e) demande d'absence par son ID numérique.' It distinguishes the tool from its siblings by emphasizing that it retrieves full details by numeric ID, contrasting with the search tool that returns a list summary. The purpose is unambiguous and helps an agent select this tool over other absence 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 provides explicit when-to-use and when-not-to-use guidance: 'Quand : après un boond_absences_search' and 'Plutôt que : boond_absences_search si l'ID n'est pas connu.' It also warns that the ID must come from search, not guessed, giving clear operational context. This fully addresses the usage decision relative to the obvious alternative.

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 valuable behavior beyond that: the 'fields' projection is local-only and never sent to the API, unknown field names are ignored, and resourceId is normalized to COMP<id>. It does not detail pagination behavior, but the annotation coverage lowers the burden.

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 clear sections: purpose, when to use, alternatives, arguments, return value, and a focused note on the 'fields' projection. It is compact, front-loaded, and contains no filler while still covering the most decision-relevant details.

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 100% schema coverage and safety annotations, the description is largely complete: it explains purpose, alternatives, period format, pagination, and the special 'fields' behavior. Since there is no output schema, the return description is somewhat minimal ('Liste des demandes d'absence correspondantes'), but it is still enough for basic 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?

Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning by explaining the resourceId-to-COMP<id> conversion and detailing the 'fields' projection behavior (local, replaces summary, unknown names ignored), which goes beyond the schema's short descriptions.

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 action and resource: 'Recherche des demandes d'absence dans BoondManager' and states what information is retrievable ('leur état de validation'). It also explicitly names sibling alternatives, so the tool is clearly distinguished from planning_absences_search and validations_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 'Quand' and 'Plutôt que' sections give explicit usage context and name the alternatives: use this for absence requests and their validation state, planning_absences_search for the calendar view, and validations_search for items pending validation. This leaves no ambiguity about when to select this tool.

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 beyond the annotations: it states partial-update semantics and the `absencesPeriods` exception where the provided array replaces existing periods. It also states the return, which is useful because there is no output schema. The only limiting factor is that it does not address permissions, validation, or rate limits, but the annotations already cover idempotency and non-read-only, so this is a strong-but-not-complete disclosure.

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 well-structured: purpose, when to use, what not to use, partial-update behavior, notable exception, and return value. Every sentence earns its place, and the structure front-loads the most relevant 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 5-parameter update tool with no output schema, the description explains purpose, usage, return value, partial update, and the replacement exception. It is not fully complete because `absencesPeriods` is described as a replaceable field but is absent from the input schema, and the `state` parameter receives no meaningful operational detail. These gaps make the definition serviceable but not fully reliable.

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?

Since schema description coverage is 100%, the baseline is 3. The description does add some value by mapping the update use case to dates, comment, and reason, and by clarifying partial update behavior. However, it does not explain the `state` parameter's possible values, and it mentions `absencesPeriods` although that field is not present in the input schema, which can confuse an agent.

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 opening sentence names a specific verb and resource: 'Met à jour une demande d'absence existante, identifiée par son ID.' It also differentiates the tool from the sibling `boond_absences_create` by explicitly pointing to create as the 'Plutôt que' alternative. An agent can immediately tell what this tool updates and how it differs from creating an absence.

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 'Quand' guidance: use the tool to correct dates, the reason, or the comment of an already-submitted request. It also says 'Plutôt que : boond_absences_create si la demande n'existe pas encore,' which is a concrete alternative and exclusion. This is model usage clarity with a named sibling.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context: unknown IDs pass through BoondManager's raw error, the ID must come from a prior search rather than guessing, and the response is the full JSON entity with attributes plus relations. No contradiction exists.

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 core purpose in the first sentence and supporting usage guidance in short labeled lines. Every sentence earns its place, and the structure makes the key routing information easy to scan.

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-parameter get-by-ID tool with no output schema, the description covers the essential context: prerequisite search, excluded alternative, error behavior, ID provenance, and return shape. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the id parameter as a numeric BoondManager identifier. The description reinforces that only a numeric ID is accepted and that names are not allowed, but it does not add substantial meaning beyond the schema's existing documentation.

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 la fiche complète d'un(e) compte utilisateur par son ID numérique.' It clearly distinguishes this from boond_accounts_search by emphasizing the full record retrieval and ID-based lookup, so an agent can tell them apart immediately.

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 explicitly says when to use it ('après un boond_accounts_search'), when not to use it ('Plutôt que : boond_accounts_search si l'ID n'est pas connu'), and notes the tool does not accept a name. This is strong routing guidance with no reliance on 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?

Even with readOnlyHint, idempotentHint, and destructiveHint=false annotations, the description adds meaningful behavioral context: it returns a page of summaries with ID + main label, exposes structuredContent.total as the BoondManager-side total, and is explicitly marked 'Lecture seule'. It also discloses that the fields parameter is an MCP-side projection never transmitted to the API, with unknown names silently ignored — non-obvious behavior an agent needs to know.

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 and front-loaded: purpose first, then usage context, then returns, then parameter-specific notes. It is moderately detailed but every section earns its place, with no filler or tautological repetition of the tool name or title. The use of short labeled sections makes it easy for an agent to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with a rich input schema and output schema, the description covers all essential decision factors: when to use it, what it returns, how total is exposed, how fields projection behaves, and what pagination limits apply. There is no obvious missing information an agent would need to invoke it correctly, and the alternatives are explicitly named.

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?

Although the schema already covers all parameters at 100%, the description adds valuable semantics beyond the schema. It clarifies that 'fields' is a client-side projection that replaces the default summary and is ignored if names are unknown, and it spells out the effective pagination boundaries. This extra meaning helps the agent use fields and pagination correctly without inferring them from the schema alone.

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?

Description opens with a clear verb-resource pair: 'Liste et recherche les comptes utilisateurs de BoondManager, par mots-clés et pagination.' It explicitly contrasts with boond_accounts_get, stating that the search only returns a one-line summary per account while the get tool is for known IDs. This makes the tool easily distinguishable from its closest sibling.

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 concrete when-to-use guidance: finding an account ID from a name or enumerating existing accounts. It also says when not to use it: if the ID is already known, use boond_accounts_get instead. Additional pagination rules ('pageSize 1–500, page 1–100, beyond that refused') strengthen the operational 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?

Le description comporte des informations comportementales au-delà des annotations : « Returns: L'action créée avec son ID» expose le retour ; la contrainte « positioningId requis par l'API pour les types d'action liés aux positionnements (ex. RQ)» et l'erreur associée apportent un contexte de négociation. Les annotations indiquent déjà readOnlyHint=false, idempotentHint=false et destructiveHint=false, ce qui est cohérent avec une opération de création. La description n'ajoute toutefois pas plus de détails sur les effets (par exemple, elle n'insiste pas sur le fait que l'opération n'est pas idempotente, la création de doublon possible, mais cela est déjà suggérée par la comparaison à update).

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?

Description assez longue mais bien structurée : une première phrase qui énonce l'objectif, puis une phrase de guidance (« Plutôt que... »), puis une liste `Args:` en bullets. Chaque ligne apporte une information (format de date, contrainte relationnelle, compléments commerciaux). Il y a une certaine redondance avec le schéma (chaque paramètre y est listé), mais la description est utilisable seule et front-load les informations clés. Un cran de plus serait possible si elle omises les list d'Args pour pointer vers le schéma, mais la taille reste raisonnable pour un outil avec 12 paramètres.

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?

Avec 12 paramètres, un output en sortie non spécifié et une opération de création, la description fournit presque tout ce qu'un agent seek : les types d'actions, la nécessité d'une entité de rattachement, le format dates, l'exigence de `typeOf` via la dictionnELIN, la contrainte de `companyId`, et le retour avec id. Manque peut être un exemple d'appel complet, mais ce n'est pas indispensable puisque le schéma a déjà une couverture à 100%. Il serait possible d'ajouter les prérequis d'authentification ou de politique, mais ces informations ne sont pas plus attendues pour un tool d'API.

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 de l'objet couvre 100% des paramètres avec des descriptions, donc la baseline est à 3. La description dépasse ce baseline en ajoutant des sémantiques transversales : elle regroupe les cinq identifiants de messagerie potentiels et précise « un requis » (contrainte qui the net est pas exprimée dans le schéma formulé, car seule `typeOf` est requise). Elle explique aussi la relation `dependsOn` obligatoire et l'incompatibilité de `companyId` sauf en complément d'un `contactId`. Ce sont des informations nécessaires pour appeler l'outil correctement, non visibles dans le schéma seul.

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 indique un verbe d'action précis (« Crée une nouvelle action »), précise les types d'actions (appel, email, RDV, note), l'univers BoondManager et les entités de rattachement (contact, candidat, ressource, opportunité, projet). Elle différencie explicitement de sa sœur boond_actions_update (« Plutôt que : `boond_actions_update` »), ce qui permet à un agent de sélectionner correctement l'outil dès la lecture.

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?

La description indique explicitement dans quels cas ne pas utiliser : « Plutôt que : `boond_actions_update` pour compléter une action déjà enregistrée plutôt que d'en créer un doublon ». Elle précise aussi une condition d'usage importante : une entité de rattachement doit être fournie (« relation dependsOn, obligatoire », « contactId | candidateId | ... (string, requis) »). Ceci guide l'agent vers le bon choix entre création et modification, et impose une contrainte critique pour réussir l'appel.

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?

Au-delà des annotations (destructiveHint=true), la description ajoute l'information cruciale de l'irréversibilité ('sans corbeille côté API') et du flux conditionnel de confirmation selon la capacité `elicitation` du client. Elle décrit précisément le comportement en cas de refus (deleted: false + reason), dupliquant ainsi l'annonce de destructivité par une mise en garde concrète. Légère marge (pas de mention des effets annexes), d'où 4.

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?

Structure exemplaire avec en-têtes ('Quand :', 'Plutôt que :'), listes à puces et ligne 'Returns' explicite. L'avertissement ⚠️ est placé en tête des risques. Chaque phrase apporte de l'information, sans redondance. Légèrement plus long que nécessaire dans l'énoncé du flux elicitation, d'où 4 plutôt que 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Le schéma de sortie existe, donc la description n'a pas à détailler le retour, mais elle le fait quand même ({ id, deleted, reason? }) pour clarifier le cas de refus. Elle couvre tous les aspects nécessaires à un appel correct : condition d'usage, pré-vérification, destructivité, flux de confirmation conditionnel, et interprétation du retour. Rien d'essentiel ne manque pour une opération destructive complexe.

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?

La couverture du schéma est de 100% avec un seul paramètre (id) déjà bien décrit ('Identifiant unique... numérique', motif ^\d+$). La description n'ajoute pas de sémantique supplémentaire sur le paramètre, mais référence l'étape de vérification de l'ID via boond_actions_get, ce qui contextualise son usage. Le niveau de base 3 est approprié.

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 énonce une action précise — 'Supprime définitivement un(e) action de BoondManager' — avec un verbe, un objet et une sémantique (permanente) nettement définis. Elle se distingue explicitement de boond_actions_update et boond_actions_get, ce qui permet à un agent de choisir sans ambiguïté.

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?

Le 'Quand :' précise l'unique condition d'usage (demande explicite de l'utilisateur + vérification préalable de l'ID via boond_actions_get) et le 'Plutôt que :' donne l'alternative exacte (boond_actions_update pour désactiver sans détruire) en indiquant qu'elle est 'presque toujours l'intention réelle'. Guidage explicite et actionnable.

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 provide readOnly, idempotent, and non-destructive hints. The description adds useful behavioral context: unknown IDs cause the raw BoondManager error to be returned, and the response includes attributes plus relations as returned by the API. It also confirms the operation is read-only.

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, front-loaded with the core action, and uses short labeled sections for when to use, what not to use, error behavior, and return value. Every sentence contributes useful information without 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 single-parameter read-only getter, this description is complete. It explains the purpose, when to use it, what the response contains, and the error behavior for invalid IDs. The annotation set covers safety, and no output schema is needed since the return format is described.

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 with type, pattern, and description. The description adds meaningful usage semantics by specifying that the ID is numeric and must originate from boond_actions_search, never from assumption. This extra provenance guidance goes 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 states a specific verb and resource: 'Récupère la fiche complète d'un(e) action par son ID numérique.' It clearly distinguishes itself from boond_actions_search by noting it retrieves full attributes not present in the list summary, and it is also distinct from create/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?

Explicit guidance is given: use after boond_actions_search to obtain full attributes, and avoid it in favor of boond_actions_search when the ID is not known because this tool does not accept a name. The warning that IDs must come from boond_actions_search, never from guesswork, is especially strong.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds value by explaining the scope (multiple entities) and the 'fields' projection behavior ('projection côté MCP, jamais transmise à l'API'), which is non-obvious and important for the agent. It loses one point because the return behavior beyond 'Liste des actions correspondantes' is not detailed, which would be useful for a search tool.

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, well-organized with 'Quand', 'Plutôt que', and 'Args' sections, and every sentence earns its place. The fields note is placed after the return description, which is fine as it's an advanced feature. No redundancy with schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only search tool with full schema coverage and clear sibling differentiation, the description is largely complete. It explains the fields projection quirk and pagination parameters are in the schema. Missing: no explicit mention of result format (beyond the plain 'Liste des actions correspondantes') and whether filters combine, but these are minor for a search tool with annotations covering safety. The output schema is absent, but for a list endpoint the description's brief return statement is acceptable.

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 description coverage is 100%, so the description doesn't need to restate parameters. The description's only addition is the 'fields' projection note ('remplace le résumé par les seuls attributs listés'), which adds real value. However, it doesn't explain filter semantics (e.g., whether filters are ANDed), which the schema also leaves implicit. This is baseline 3 territory, with a slight bonus for the fields note balanced by minimal added filter 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 is explicit and specific: 'Recherche des actions (appels, emails, RDV, notes) dans BoondManager avec filtres optionnels par candidat, ressource, contact ou société.' It names the resource (actions), the domain (BoondManager), and the filter dimensions, which clearly distinguishes it from siblings like boond_candidates_actions or boond_actions_get. The distinction is further reinforced by the explicit 'Plutôt que' section naming an alternative.

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 'Quand' and 'Plutôt que' guidance, explicitly stating to use this tool for sweeping commercial/HR history across multiple entities, and explaining why entity-specific action tabs are less direct. This is exemplary usage guidance that routes the agent to the correct tool in ambiguous multi-entity 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?

Beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description adds substantial behavioral detail: it's a partial PUT ('PUT partiel, seuls les champs fournis sont modifiés'), it does not send relations and preserves dependsOn/positioning/calendar sync, and it warns that text replaces existing content rather than appending. This gives the agent crucial insight into side effects. 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 somewhat lengthy but well-structured: it starts with the core purpose, then usage guidance, a behavioral warning, and an args list. Every sentence contributes meaning; there is no fluff. The front-loading of the primary action and the sibling distinction makes it easy to scan 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?

For an update tool with a rich schema and annotations, the description is complete. It covers the operation type, idempotent partial update behavior, preservation of relationships, and parameter semantics. The 'Returns: L'action mise à jour' line, combined with the stated output schema, ensures the agent knows what to expect. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (all six parameters have descriptions), so the baseline is 3. The description adds value by clarifying that 'text' replaces existing content (not adds), specifying the date format with a concrete example (2026-06-05T10:00:00+0200), and noting typeOf uses the dictionary setting.action.*. These details go beyond the schema's basic field descriptions.

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 purpose: 'Met à jour une action existante dans BoondManager' (updates an existing action). It explicitly differentiates from the sibling boond_actions_create by noting 'Plutôt que : boond_actions_create si l'action n'existe pas encore' (rather than create if the action doesn't exist yet). This leaves no ambiguity about the action's role.

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 direct guidance on when to use this tool versus alternatives. It names boond_actions_create as the correct choice when the action doesn't exist, and contrasts with delete+recreate, explaining why update is preferable for preserving calendar sync. This is explicit and actionable.

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 and idempotentHint, but the description adds valuable context: it states the return is a JSON entity (attributes + relations) and that an unknown ID raises the raw BoondManager error. This goes beyond the basic safety hints and discloses error behavior.

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?

Four concise sentences with clear subheadings (Quand, Plutôt que, a bullet for error, and a return note). Front-loaded with the main purpose, zero waste, and efficient use of whitespace.

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 single-parameter get-by-id tool with full schema coverage and safety annotations, the description is complete: it covers when to use, the source of the ID, error behavior, and the return format. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers 100% with full parameter description, but the description adds critical semantic guidance: the ID must come from a prior search, not be guessed. This linkage is not in the schema and helps correct parameter sourcing.

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 the complete record of an advantage by its numeric ID, using the specific verb 'Récupère' and naming the resource. It explicitly distinguishes itself from the search tool by noting it provides attributes not in the list summary.

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?

Explicitly gives when to use (after a search, to get full attributes) and when not (if ID unknown, use search instead since this tool doesn't accept a name). Also warns that IDs must come from search, never guessed, providing clear routing to the sibling.

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, so no extra safety disclosure is needed. The description adds useful behavioral detail beyond annotations: the fields projection is MCP-side, never transmitted to the API, unknown names are ignored, and it is recommended for large pages.

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: purpose and routing first, then a compact Args block, then a short return note and a focused explanation of the one non-obvious parameter. Every sentence contributes to correct invocation.

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 five optional parameters, full schema coverage, and no output schema, the description covers the return type, the main filters, pagination, and the non-obvious fields behavior. Annotations cover safety and idempotency, so nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics for the 'fields' parameter: it clarifies that the projection is handled MCP-side, is not sent to the API, replaces the summary, ignores unknown names, and is intended for large result pages. This goes beyond the schema's brief wording.

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 action and object ('Recherche des avantages ... dans BoondManager') and gives concrete examples of what counts as an avantage. It also names the sibling tool boond_resources_advantages, which helps an agent distinguish between the two without inspecting schemas.

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 explicitly contrasts this tool with boond_resources_advantages and gives the context ('quand on part d'une ressource précise') where the routing choice matters. It also documents optional keyword and resourceId filters plus pagination, which is enough guidance for selecting and invoking the tool.

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 and destructiveHint=false, so the read-only nature is covered. The description adds the behavior that an unknown ID will surface the BoondManager error as-is, and that the ID must come from `boond_agencies_search`, never from a guess. This is useful context beyond 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 and well-structured: it opens with the core purpose, then provides usage context, a clear contrast with the sibling, a behavior note, and a returns description. Each sentence earns its place, and key information is front-loaded.

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 is complete for this simple one-parameter read tool. It covers what it returns (JSON of the entity with attributes and relations), the read-only nature, error behavior for unknown IDs, and its role in the workflow. The only minor gap is not detailing exact response fields, but that's not critical given the output is JSON from the API.

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 description coverage is 100%, and the parameter `id` is adequately described as the unique BoondManager entity identifier (numeric). The description reinforces that the ID must be obtained from the search tool)Skip, which adds context beyond the schema. No additional parameter details are needed.

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 purpose: retrieving the full record of an agency by its numeric ID. It specifies the resource ('fiche complète d'un(e) agence') and the action ('Récupère'), and it distinguishes this tool from the search tool by noting it does not accept names, only IDs.

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 explicitly says when to use this tool: after a `boond_agencies_search` to get full attributes not in the list summary. It also states when NOT to use it: if the ID is not known, use `boond_agencies_search` instead. This clear routing is very 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 mark this as read-only, idempotent, and non-destructive, and the description adds substantial behavioral context: returns only summaries, reports `structuredContent.total`, warns that pagination parameters are ignored by the API, and explains that `fields` is an MCP-side projection never sent to the API. This goes well beyond the annotations and materially changes how the tool should be invoked.

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 and front-loaded: core purpose first, then usage context, then return behavior, then parameter-specific warnings. Every sentence earns its place, and the bullet format makes the critical gotchas easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with rich annotations and an output schema, the description covers all the essential operational knowledge: when to use it, what it returns, how `fields` behaves, and that pagination is a no-op. There is no missing information an agent would need to call this 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 description coverage is 100%, so the baseline is 3, but the description adds significant value: it clarifies that `fields` is a local projection, that unknown field names are ignored, that `pageSize` and `page` are ineffective, and that keywords drive the search. This prevents an agent from paginating unnecessarily or assuming the fields parameter is forwarded.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb and resource: 'Liste et recherche les agences de BoondManager'. It explicitly distinguishes itself from the sibling `boond_agencies_get`, noting the search returns only a one-line summary per agency, so an agent can immediately tell which tool fits its goal.

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 when-to-use guidance: find an agency ID from its name or enumerate agencies. It also names the alternative `boond_agencies_get` and explains why it is preferable when the ID is already known. This is direct, actionable routing information.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context: it returns JSON data about the current user, mentions no parameters, and clarifies that this is not the tool for querying other users.

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 'Quand', 'Plutôt que', and 'Returns' sections, and the main purpose is front-loaded. It is slightly longer than necessary and the 'identique et moins coûteuse' phrase adds ambiguity without much benefit.

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 zero-parameter introspection tool, the description covers the main decision point: when to call it and when to use boond_resources_search instead. Since there is no output schema, the explicit mention of JSON user data with profile, permissions, and agency is useful and sufficient for a basic agent decision.

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 zero parameters, so the baseline is 4. The description reinforces this by explicitly stating that the tool takes no parameters, which is helpful for an agent choosing between this and a parameterized sibling like boond_resources_search.

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 information about the currently connected BoondManager API user, including profile, permissions, and agency. It uses a specific verb and resource, and it distinguishes itself from boond_resources_search by the account-holder scope.

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 explicitly says to use this tool at the start of a session to identify the account and its scope, and it points to boond_resources_search when querying someone other than the account holder. However, the comparison with the boond://application/current-user resource is worded ambiguously ('identique et moins coûteuse') and could confuse an agent about whether to prefer the tool or the resource.

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 communicate read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond that: one endpoint returning everything, server-side caching with a configurable TTL, dotted-path subtree extraction, the invalid legacy slash form, and the isError response for unknown paths. It does not discuss auth or rate limits, but those are not central for this read-only dictionary lookup.

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 long but clearly structured with Quand/Plutôt que/endpoint/Args/Returns sections, and the extensive path examples are reference material rather than fluff. It could be slightly condensed, but no sentence is wasted.

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 single-parameter read-only lookup with no output schema, the description is complete: it explains when to use it, what the parameter means, what the response looks like, the error behavior, and important constraints. An agent has everything needed to 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?

One parameter with 100% schema coverage, but the description adds the crucial semantics: dictionaryType is a path relative to data, with many concrete examples and an explicit correction that the schema-style slash form ('states/resources') is invalid in favor of dotted form ('setting.state.resource'). This goes well beyond the schema and prevents a common mistake.

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 precise verb and object ('Récupère un dictionnaire de référence BoondManager') and enumerates the dictionary contents (états, types, pays, devises...). It also distinguishes itself from reading the same data via the boond://dictionary/* resources, so an agent can tell this tool apart from the read-resource alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Quand' section gives an explicit trigger: translate a BoondManager state or type ID to its label before filtering a search. The 'Plutôt que' section names the alternative (resources/read on boond://dictionary/*) and states the condition for still using this tool (tables not published as resources).

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, idempotentHint, and destructiveHint false. The description adds useful context: the return value is the full entity JSON with attributes and relations, and unknown IDs surface BoondManager's raw error. This exceeds what annotations alone provide, though it does not describe auth or other operational 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 well-structured and front-loaded: the main purpose is stated first, followed by clear usage conditions and return information. Every sentence adds value, and the bullet/list formatting makes it 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?

For a single-parameter, read-only get-by-ID tool, the description covers the key operational concerns: when to use it, where the ID comes from, error behavior, and the shape of the response. No critical information is missing for correct 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?

Schema coverage is 100%, so the schema already documents the id parameter. The description adds semantic guidance by emphasizing that the ID is numeric and must be obtained from boond_business_units_search rather than guessed, which helps the agent understand the provenance and validity constraints of the 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 a specific action ('Récupère la fiche complète') and resource ('business unit par son ID numérique'), and differentiates it from the sibling search tool by saying it accesses attributes missing from the list summary. An agent can clearly understand what this tool does and how it differs from boond_business_units_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 explicitly says when to use it ('après un boond_business_units_search'), what to use instead in a different situation ('Plutôt que : boond_business_units_search si l'ID n'est pas connu'), and warns that the ID must come from search, never from guesswork. This is strong, actionable 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?

Les annotations couvrent déjà la sécurité (readOnlyHint=true, destructiveHint=false, etc.), mais la description ajoute des détails comportementaux critiques : format de retour (page de résumés ID + libellé, `structuredContent.total`), comportement de la projection `fields` (jamais transmise à l'API, noms inconnus ignorés), et les limites strictes de pagination (pageSize 1-500, page 1-100, refus au-delà). Cette transparence va bien au-delà des 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?

La description est structurée en paragraphes courts avec des titres implicites (« Quand », « Plutôt que », « Returns ») et des puces pour les paramètres. Chaque phrase apporte une information unique et nécessaire, sans répétitions ni remplissage. L'information critique est front-loaded dans les premières lignes.

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?

La description couvre tous les aspects nécessaires pour appeler l'outil correctement : but, cas d'usage, alternative, format de retour, détails de paramètres, limitations de pagination, et le fait que l'opération est en lecture seule. Le schéma de sortie existe et la description fournit les informations de contexte qui ne sont pas dans le schéma, rendant l'ensemble complet.

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 a déjà une couverture de 100% pour les 4 paramètres, mais la description enrichit chaque paramètre : `fields` est expliqué comme une projection locale non envoyée à l'API, `page` et `pageSize` sont présentés avec leurs plages et le comportement de refus en cas de dépassement, et `keywords` est illustré avec des exemples concrets. L'utilisation recommandée de `fields` sur les grosses pages apporte une valeur ajoutée nette.

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 commence par un verbe d'action précis (« Liste et recherche ») accompagné de la ressource cible (« business units de BoondManager ») et des critères de recherche (« mots-clés et pagination »). Elle distingue explicitement l'outil de son alternative `boond_business_units_get` en précisant que la recherche ne renvoie qu'un résumé d'une ligne, ce qui lève toute ambiguïté.

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?

La section « Quand » définit clairement les cas d'usage : retrouver un ID à partir du nom ou énumérer les business units. La section « Plutôt que » indique explicitement d'utiliser `boond_business_units_get` si l'ID est déjà connu, et explique pourquoi (résumé limité). C'est une directive d'utilisation complète et orientée vers le choix du bon outil.

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 set readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds that unknown IDs return the raw BoondManager error, which is useful behavioral context, but does not describe other edge cases (e.g., network failures, response format details). The description does not 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 concise and well-structured with clear sections for 'when' and 'rather than', front-loading the primary purpose and usage guidance. No redundant sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only tool with annotations covering safety, the description covers the key context: when to use, how to get the ID, and what the return is (attributs + relations). It does not detail the output structure, but no output schema exists, so the description is 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 description coverage is 100%, so the schema already documents the `id` parameter as the unique identifier. The description reinforces that it must be numeric and from search, but adds limited new semantic value beyond that.

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 the complete record of a calendar by its numeric ID, distinguishing it from the search tool that returns list summaries. It explicitly says it is for after a search to get full attributes, which differentiates it from sibling 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 provides explicit when-to-use guidance: after `boond_calendars_search` to obtain attributes not in the list summary, and explicitly says to prefer `boond_calendars_search` when the ID is not known because this tool does not accept names. Also warns that the ID must come from search, not guesswork.

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 readOnlyHint annotation, the description discloses that pagination parameters are ignored by the API and that the response always contains the full calendar list. It also explains that 'fields' is processed client-side and never sent to the API, plus the return format (ID + main label, with total). These are non-obvious behaviors that prevent misuse.

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 well-structured: a one-line summary, a 'Quand' paragraph, a 'Plutôt que' alternative, and focused bullets for `fields` and pagination. Every sentence adds new information and the structure makes it skimmable.

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 the use case, alternative tool selection, return format summary, the critical pagination caveat, and the special behavior of `fields`. Combined with the input schema and output schema, an agent has everything needed to call this endpoint 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?

All four parameters already have descriptions in the schema (100% coverage), but the description adds valuable clarification: `fields` is a client-side projection (not passed to the API) and `pageSize`/`page` are ineffective. This exceeds the baseline for 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 opens with 'Liste et recherche les calendriers de BoondManager, par mots-clés et pagination', clearly stating the action (list/search), the object (calendars), and the criteria. It explicitly differentiates from boond_calendars_get, so an agent can distinguish this search endpoint from the direct retrieval endpoint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Quand' section specifies the exact use case (find calendar ID by name, enumerate calendars) and explicitly advises using boond_calendars_get when the ID is already known. This gives unambiguous routing 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, which cover safety and idempotency. The description adds that it retrieves actions and is read-only ('Lecture seule'), which slightly reinforces the annotation. It does not disclose any additional behavioral traits such as pagination, response format, or potential for large data sets, but given the annotation coverage, 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 concise, with key information front-loaded in the first sentence. It uses short paragraphs for usage guidance and return type, making it scannable. It could be slightly more compact, but it is not verbose or redundant.

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 single-parameter read-only tool. The description covers purpose, usage context, and return type. Given the presence of annotations (readOnly, idempotent) and full schema coverage, nothing critical is missing. The only minor gap is not describing the response structure in detail, but the absence of an output schema suggests standard behavior.

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 parameter 'id' is well-documented ('Identifiant unique de l'entité BoondManager (numérique)'). The description does not add any parameter-specific detail beyond the schema, but also does not need to, since the schema covers it fully. Per baseline, score 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 states a specific verb ('Récupère') and resource ('actions d'un candidat') and lists the action types (appels, emails, RDV, notes), which distinguishes it from generic get tools. It does not explicitly name the sibling tools it differs from, but the context signals (sibling list) include similar actions tools for other entities, and the description's specificity is sufficient.

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 states when to use this tool ('pour ne charger que cette section, sans le reste de la fiche') and provides explicit alternatives ('Plutôt que : `boond_candidates_get` pour la fiche de base, ou `boond_candidates_search` si l'ID est inconnu'). This is exemplary usage guidance with both when and when-not conditions.

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 cover read-only, idempotent, and non-destructive behavior. The description adds useful context by stating the return is the administrative block and that document IDs can be consumed by boond_documents_get. This goes beyond the 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 compact, front-loaded with the core action, and organized with 'Quand', 'Plutôt que', and 'Returns' sections. Every element earns its place 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?

For a one-parameter read-only tool, the description covers purpose, usage context, alternatives, and return shape. No output schema exists, but the high-level return description is sufficient for an agent to invoke this 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?

The schema already fully describes the single 'id' parameter with 100% coverage. The description only restates that data is fetched 'par son ID', adding no extra semantic detail 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 uses a specific verb ('Récupère'), a clear resource ('données administratives d'un candidat'), and an explicit identifier (ID). It also distinguishes this section-scoped tool from the general candidate profile tool, which is a strong differentiator.

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 explicitly states when to use this tool ('pour ne charger que cette section, sans le reste de la fiche') and names the alternatives to prefer instead: boond_candidates_get for the base profile and boond_candidates_search when the ID is unknown.

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 explicitly discloses non-idempotent behavior ('deux appels identiques créent deux enregistrements - l'API ne déduplique pas') and explains that relation IDs and state/type IDs are BoondManager numeric IDs requiring pre-resolution. It also discloses the return content and reusability of structuredContent.id. This goes beyond annotations (which only say readOnly=false) and carries the behavioral load well.

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 structured with clear sections (Quand, Plutôt que, bullet point, Returns) and uses short sentences. It front-loads the primary action in the first sentence, then adds conditions, exclusions, behavioral notes, and return value information. No filler or 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 create tool with 10 parameters, it is complete enough: it covers usage context, behavioral side effects, ID resolution approach, and return value chaining. It does not document every parameter's semantic nuance, but the schema already does that. Missing explicit prerequisites (e.g., authentication) which annotations and general Boond context might provide, but not material.

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, each with descriptions in French. The tool description adds meaning for state (numeric ID, needs pre-resolution) and the type/state relation. However, parameter descriptions are mostly short labels; the description could add more about semantics or formats for a few fields. But because schema coverage is 100%, the baseline is 3, and the added ID-resolution guidance elevates it slightly.

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 explicitly states the action ('Crée un(e) candidat dans BoondManager'), specifies when to use it ('pour ajouter un(e) candidat inexistant(e)'), and distinguishes it from sibling tools like boond_candidates_update and boond_candidates_search. This clearly differentiates it from the many sibling candidate 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 provides explicit 'Quand' (when) guidance and 'Plutôt que' (instead of) guidance, naming the alternatives and the workflow: search first with boond_candidates_search, then update with boond_candidates_update, or create. This is comprehensive usage 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 include destructiveHint=true, but the description goes beyond them by warning that deletion is irreversible, has no trash/recycle bin on the API side, and can be bypassed or canceled depending on the MCP client's 'elicitation' capability. It also explains refusal behavior via 'structuredContent.deleted: false' and 'reason'. These are significant behavioral details the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main delete action, followed by compact 'Quand' and 'Plutôt que' lines. The important warnings and return behavior are placed in short bullet phrases. Every sentence contributes distinct operational value, and there is no fluff or tautological text.

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 destructive, single-parameter tool, the description covers all key context: when deletion is appropriate, which sibling to use instead, the irreversibility risk, the possible user confirmation flow, and the output combination for a refusal. Nothing relevant for an agent to invoke this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one parameter, 'id', and the input schema already describes it as the unique numeric BoondManager entity ID with a regex pattern. Since schema coverage is 100%, the baseline is 3; the description adds no extra parameter details beyond the advice to verify the ID first, which is more operational guidance than parameter semantic. This does not substantially raise the score.

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 the exact action with a specific verb and resource: 'Supprime définitivement un(e) candidat de BoondManager.' It also distinguishes the tool from siblings by explicitly pointing to boond_candidates_update for non-destructive state changes and boond_candidates_get for verifying the ID, so an agent can clearly recognize this tool's unique destructive purpose.

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 'Quand' guidance: only on explicit user request and after verifying the ID with boond_candidates_get. It also tells the agent to prefer boond_candidates_update when the real intention is to disable or change state without destroying, making both when to use and when not to use this delete tool 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?

While the annotations already declare readOnlyHint and idempotentHint, the description adds valuable behavioral details not present in annotations: without `tab` only the base fiche is returned rather than a merge of tabs, unknown IDs surface the raw BoondManager error, and returned data is the JSON entity as provided by the API. The 'Lecture seule' note is consistent with the readOnlyHint annotation, and no contradiction appears.

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 and front-loaded: it opens with the main action, then organizes usage context, alternatives, parameter behavior, and return value in short labeled sections. Every sentence adds useful information without repetition or padding.

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 get operation with two parameters and no output schema, the description covers the essentials: input provenance, tab behavior, error behavior, and return format. The main completeness gap is the lack of clarification about when to use this tool's `tab` parameter versus the dedicated tab-specific sibling tools, which are present in the sibling list and semantically overlap.

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 both `id` and `tab`. The description adds useful meaning by stating that `id` must come from `boond_candidates_search` and never from guesswork, and by explaining the effect of omitting `tab`. However, there is a notable inconsistency: the schema lists `technical` while the description uses `technical-data`, which could mislead an agent about valid `tab` values.

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 operation: 'Récupère la fiche complète d'un(e) candidat par son ID numérique', with a specific verb and resource. It also differentiates from `boond_candidates_search` by noting that this tool requires a numeric ID and returns list-attributs beyond the summary. However, it does not clarify its relationship to the sibling tab-specific tools such as `boond_candidates_information`, `boond_candidates_technical_data`, or `boond_candidates_administrative`, despite the `tab` parameter overlapping with them.

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 an explicit usage context: 'Quand : après un `boond_candidates_search`, pour obtenir les attributs qui n'apparaissent pas dans le résumé de liste.' It also tells the agent when not to use it: 'Plutôt que : `boond_candidates_search` si l'ID n'est pas connu.' It lacks explicit exclusions or routing guidance for the dedicated tab-specific sibling tools, so the when-to-use guidance is clear but incomplete.

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 includes "Lecture seule" and a fetching verb, which is consistent with the `readOnlyHint` and `idempotentHint` annotations. With these annotations present, the description adds only a little extra context (return block), but does not disclose errors, authentication, or other operational behavior beyond what the annotations already 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 compact and uses clear labels (Quand, Plutôt que, Returns), making it easy to scan. The main redundancy is that the "Returns" line largely repeats the fields already mentioned in the first sentence, so it falls slightly short of a perfect 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?

For a simple read-only tool with one ID parameter and no output schema, the description provides the purpose, the scope of the returned block, and the alternatives. It does not describe response errors or envelope details, but this is not essential for an agent to call the tool correctly in most 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?

The schema already describes the single parameter `id` with type, pattern, and purpose. The description only restates "par son ID," adding no new semantic details about the ID parameter. With 100% schema description 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 names a specific verb and resource ("Récupère les informations générales ... par son ID") and explicitly contrasts itself with `boond_candidates_get` for the base record and `boond_candidates_search` when the ID is unknown. It lists key fields (coordees, adresse, état civil, photo, tags, source), making the scope clear without needing the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The "Quand" and "Plutôt que" lines give direct, actionable guidance: use this tool when only this section is needed, use `boond_candidates_get` for the base record, and `boond_candidates_search` when the ID is unknown. This fully covers when and when-not relative to the two relevant sibling tools.

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 establish readOnly, idempotent, and non-destructive behavior. The description adds useful context by saying the result is a list and that this call intentionally fetches only the positionings section. It repeats 'Lecture seule', which is redundant with annotations, but does not contradict them and does add the scoped-loading behavior.

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, scannable, and front-loaded with the purpose before usage guidance. The 'Quand / Plutôt que / Returns' structure adds clear organization. It loses a point only because 'Lecture seule' repeats information already carried by annotations.

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 section fetch, this is largely complete: it explains what is returned, when to use it, and how it relates to sibling tools. It does not specify pagination or the exact item shape of a positioning, and there is no output schema, so a perfect-completeness score is not warranted.

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 single id parameter is already fully described in the schema with a numeric pattern and an explicit meaning. The description only says 'par son ID', which repeats but does not extend the schema. With schema coverage at 100%, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear, specific verb 'Récupère' and identifies the resource: positionnements for a candidate by ID. The parenthetical explanation and the 'Plutôt que' alternatives make it easy to distinguish from boond_candidates_get and boond_candidates_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?

It gives explicit 'Quand' guidance - use it to load only the positionings section rather than the whole record - and names the alternatives: boond_candidates_get for the base fiche and boond_candidates_search when the ID is unknown. This is exactly the kind of routing an agent needs.

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 portent déjà `readOnlyHint=true`, `idempotentHint=true` et `destructiveHint=false`, et la description ajoute sans contradiction des comportements supplémentaires : la perte d'accès aux personnes recrutées, les limites de pagination avec refus au‑delà de page 100, la projection `fields` côté MCP jamais transmise à l'API, et la sémantique par défaut de `keywords`. C'est une valeur nette au‑delà des 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?

La structure est exemplaire : phrase d'ouverture, distinction avec l'outil frère, puis catégories filtrées en puces. Le texte est dense mais chaque section sert un besoin réel d'utilisation ; seuls quelques énumérations du schema sont presque redondantes. La longueur est justifiée par les 36 paramètres, mais un léger élagage serait possible, d'où 4.

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 recherche complet avec 36 paramètres optionnels et un schema de sortie existant, la description couvre les groupes de filtres à plus haute valeur (périmètre, états, profil technique, sourcing, période, géolocalisation), les contraintes de pagination et le comportement de `sort`/`order`. Le format retournment n'est pas décrit, mais le schema de sortie en assume la charge. Rien d'essentiel ne manque.

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?

Bien que la couverture du schéma soit à 100 % (baseline 3), la description ajoute énormément de sens opérationnel : syntaxe `#AND#` pour `tools`, format `langueId|niveauId` pour `languages`, combinaison obligatoire `coordinates`/`location` avec `geoDistance`, raccourcis `perimeterDynamic`, dictionnaires source pour les IDs, et exemples concrets pour `keywords`/`keywordsType`. Elle compense largement le reste.

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 énonce clairement le verbe et la ressource : « Recherche des candidats dans BoondManager avec filtres serveur ». Elle se distingue explicitement de `boond_resources_search` en expliquant que candidats et ressources sont deux référentiels distincts, ce qui lève toute ambiguïté face aux nombreux outils frères.

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?

Le texte nomme l'alternative directe (`boond_resources_search`) et donne la règle de choix : collaborateurs internes vs candidats. Il renvoie aussi vers `boond_candidates_get` ou les outils d'onglets pour le détail, et fournit des cas d'usage concrets pour chaque combinaison de filtres. C'est un guidage explicite et actionnable.

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 reinforces this with 'Lecture seule' and adds context about the return content (technical profile, CV document IDs) and how those IDs are used. It does not contradict annotations and adds useful behavioral context beyond what annotations provide.

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 clear sections (main purpose, when to use, alternatives, returns). It is concise, front-loaded with the main action, and every sentence adds value, such as the relationship to boond_documents_get. No 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 single-parameter read-only retrieval with no output schema, the description is complete. It states what is returned, when to use it, and how to chain with other tools. The agent has all necessary information to call it correctly without needing additional details.

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 single 'id' parameter, which already has a clear description. The tool description does not add any additional parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies. It only restates 'par son ID' without new details.

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 ('Récupère') and the specific resource ('profil technique' of a candidate) and explicitly distinguishes from siblings by naming boond_candidates_get for the base profile and boond_candidates_search when the ID is unknown. This leaves no ambiguity about 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 includes a 'Quand' section explaining when to use it (to load only this section) and a 'Plutôt que' section giving explicit alternatives and conditions (boond_candidates_get for the base, boond_candidates_search if ID unknown). It also mentions that returned document IDs feed boond_documents_get, providing downstream usage 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?

Beyond the annotations, the description discloses important behavioral details: the update is partial, only provided fields are written, and absent fields are left untouched. It also warns that array fields are replaced rather than merged, and states the return payload: confirmation and the updated candidate record. These details are not contained in 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 compact and well structured: core behavior first, then a clear 'Quand' section, an alternative-tool note, and a short bullet list. Every line provides actionable information, and the return value is included without unnecessary elaboration.

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 high schema coverage, the presence of an output schema, and the annotations, this description is complete enough for correct invocation. It covers the update scenario, partial-update behavior, the create alternative, and the response, so an agent can decide when to call it and how to interpret the result.

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 each parameter is already documented in the schema. The description adds valuable cross-parameter semantics by clarifying that omitted optional fields are not cleared, and that provided fields are written as part of the partial update. This goes slightly beyond the baseline but does not deeply explain individual parameter formats.

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 the exact operation: update an existing candidate identified by its ID. It explicitly distinguishes the tool from the sibling creation tool by saying 'Plutôt que : boond_candidates_create si l'enregistrement n'existe pas encore.' This removes ambiguity about whether to use update or create.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Quand' clause clearly indicates this is for modifying specific fields of an existing record. The 'Plutôt que' clause names the alternative tool and its condition of use: if the record does not exist yet, use boond_candidates_create. This gives the agent a clear decision rule.

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 useful context by stating the return is a list of actions attached to the company and explicitly notes 'Lecture seule', reinforcing the read-only nature. It doesn't describe pagination or ordering, but for a simple read tool with strong annotations, this is adequate.

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 well-structured: a one-line summary, a 'Quand' usage condition, a 'Plutôt que' alternative routing, and a 'Returns' note. Every sentence earns its place and the most important scoping information is front-loaded.

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 single-parameter read-only tool with full schema coverage and strong annotations, the description covers the essential context: what it returns, when to use it, and how it differs from siblings. It doesn't mention pagination or response format, but with no output schema and a simple list return, this is a minor gap rather than a critical omission.

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 single 'id' parameter is already fully documented in the schema. The description adds that the ID is the company's ID and that it retrieves actions for that company, which is consistent with the schema but doesn't add new format or constraint details beyond it. 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 states a specific verb ('Récupère') and resource ('les actions ... d'un(e) société, par son ID'), and enumerates the action types (appels, emails, RDV, notes). It clearly distinguishes this from sibling tools like boond_companies_get and boond_companies_search 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?

The description explicitly says when to use this tool ('Quand : pour ne charger que cette section, sans le reste de la fiche') and names the alternatives to use instead ('Plutôt que : boond_companies_get ... boond_companies_search si l'ID est inconnu'). This gives an agent clear routing 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns a list of contacts and is read-only, which reinforces but adds little beyond annotations. It doesn't detail response structure or potential errors, but annotations cover the main safety profile, so 4 is fitting.

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 the main purpose, and includes a compact 'Quand' and 'Plutôt que' section. Every sentence serves a purpose with no 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 simple single-parameter read-only tool with annotations covering safety, the description adequately covers when to use and alternatives. It doesn't describe the response format, but since there is no output schema and the tool is simple, it's largely sufficient. Minor gap: no mention of pagination or error handling, but not critical.

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 only parameter 'id' is well-documented in schema. The description clarifies it's the company's ID and is used to retrieve contacts, but adds no new syntax or format details. 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 retrieves contacts for a specific company by its ID, using specific verb and resource. It distinguishes itself from siblings like boond_companies_get and boond_companies_search, making it easy to identify.

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?

Explicitly says when to use: to load only the contacts section, and when not to: use boond_companies_get for the base record or boond_companies_search if ID is unknown. Provides clear alternatives.

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 explicitly states that the operation is a real write and non-idempotent, meaning two identical calls create two records, and the API does not deduplicate. It also notes that relation IDs and state/type IDs are BoondManager numeric IDs that need to be resolved beforehand, which is crucial for correct invocation. While annotations do not include a readOnlyHint (it is false), the description adds value beyond the annotations by detailing the non-idempotent behavior and the need for pre-resolving IDs, which is important for the agent to understand the side effects and prerequisites.

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. It starts with a clear one-line purpose, then groups related information: when to use, alternatives, behavioral warnings, and return value. Every sentence earns its place, and the use of bullet points for behavioral notes improves readability. It is front-loaded with the core purpose and usage, making it easy to scan.

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 there is an output schema and 9 parameters (1 required), the description provides essential context: the non-idempotent behavior, the need to resolve IDs beforehand, and the return value structure (confirmation, created ID, complete record, and that structuredContent.id is reusable for chaining). This covers the risk of duplicate creation and the dependency on external lookups, which are not evident from the schema alone. The description is complete for an agent to correctly invoke the tool without missing critical steps.

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%, meaning every parameter has a description in the schema. The tool description does not enumerate the parameters but mentions that relation IDs and state/type IDs need to be resolved beforehand, which adds context beyond the raw schema names (e.g., 'state' as an integer ID). However, most parameter descriptions in the schema are minimal (e.g., 'Ville', 'Email de la société'), and the description does not provide additional details like required format or examples. Since the schema already covers each parameter, the baseline is 3, and the description adds marginal value by highlighting the ID resolution requirement.

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 (Crée) and resource (société dans BoondManager), and clearly states the purpose: adding a company that does not yet exist. It distinguishes itself from sibling tools by explicitly naming `boond_companies_update` for modification and `boond_companies_search` for pre-checking existence, making it clear what this tool does and does not do.

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 explicitly states when to use this tool ('pour ajouter un(e) société inexistant(e)') and provides alternatives: it directs to use `boond_companies_update` for existing records and `boond_companies_search` first to verify non-existence. This is clear usage guidance with specific conditions and alternative tools, which is exactly what is needed.

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 déclarent déjà destructiveHint=true, mais la description ajoute des précisions essentielles : irréversibilité sans corbeille côté API, comportement conditionnel selon la capacité elicitation du client MCP, et structure de retour avec deleted=false et reason en cas de refus utilisateur. Aucune contradiction avec les annotations n'est présente.

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?

Le texte est structuré en sections courtes et front-loaded : action, conditions d'usage, alternative, avertissement, comportement de confirmation, retour. Chaque phrase apporte une information nécessaire pour un outil destructif, sans répétition inutile.

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?

La description couvre tous les aspects critiques pour un outil de suppression : déclenchement légitime, vérification préalable, alternative non destructive, irréversibilité, gestion de la confirmation utilisateur et format de retour. Rien d'essentiel ne manque.

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 couvre 100% de l'unique paramètre id avec type, pattern et description en français. La description n'ajoute pas de sémantique supplémentaire sur le paramètre lui-même ; la recommandation de vérifier l'ID relève de l'usage, pas de la définition du paramètre.

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 commence par 'Supprime définitivement un(e) société de BoondManager', un verbe d'action précis avec une ressource claire. Le suffixe _delete et le titre 'Supprimer un(e) société' distinguent l'outil des autres opérations sur les sociétés.

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?

La section 'Quand' précise que la suppression ne doit avoir lieu que sur demande explicite de l'utilisateur et après vérification de l'ID avec boond_companies_get. La section 'Plutôt que' nomme explicitement boond_companies_update comme alternative pour une désactivation, ce qui guide le choix de l'agent.

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 that without a `tab`, only the base record is returned, not a merge of all tabs, and that an unknown ID yields a raw BoondManager error. It also states it is read-onlyais, which is already in annotations. It adds some value beyond annotations, though it doesn't cover authentication or rate limits.

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, well-organized with bullet points for when/where to use and return behavior. Every sentence adds value; no fluff. Ideal length and structure for an agent-facing description.

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 read-only nature, the tool is fully described: when to use, when not to, tab behavior, error on unknown ID, and response format (JSON). The annotation already covers read-only. There is no missing critical information.

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 adds context for the `tab` parameter (specific tabs like information, technical-data) and notes that without it you get the base record. However, the input schema already describes parameters well, so the description only slightly enhances. The unknown-ID error is about parameter id, which is useful but not deeply detailed.

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 crisp statement of purpose: 'Récupère la fiche complète d'une société par son ID.' It is obvious what the tool does and how it differs from the list-level search tool.

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?

Explicitly positions the tool as a follow-up to `boond_companies_search`, tells the agent when NOT to use it (unknown ID, use search instead), and even warns that the ID must be a real one, never guessed. This is ideal routing information.

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