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

The description goes well beyond the annotations by disclosing that the call is non-idempotent, that the API does not deduplicate requests on the same dates, and that the created absence starts in a waiting-for-validation state rather than being immediately validated. These are important behavioral traits 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 with clear sections for when to use, what to use instead, key behavioral notes, and return value. Every sentence carries useful information, 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 creation tool with no output schema and only negative annotations, the description covers the essential operational aspects: what it creates, how periods are determined, the non-idempotent behavior, the validation workflow, and what the response contains. An agent has enough context 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantic context by explaining the relationship between absencesPeriods and startDate/endDate, including the fallback behavior when absencesPeriods is omitted. This clarifies a subtle interaction that the schema alone does not convey.

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 object: 'Crée une demande d'absence' for a resource, and lists examples (congés, RTT, maladie). It also distinguishes itself from boond_absences_update, so an agent can immediately tell creation apart from modification.

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 the exact scenario for using this tool, and 'Plutôt que' explicitly names boond_absences_update as the alternative for modifying an existing request. It also clarifies that validation state is handled elsewhere via boond_validations_search, 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by noting it is read-only, that the raw response is reduced to absence types and request scalars, and that the response includes the resource and workUnitTypesAllowed. 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 well structured with clear front-loaded purpose, then 'Quand', 'Plutôt que', and 'Returns' sections. Every sentence serves a distinct purpose: what it does, when to use it, what to use instead, and what the response contains.

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

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

Despite lacking an output schema, the Returns section enumerates the response contents: resource, agency, absence types with reference, label, and activityType, plus defaults. Combined with the explicit usage timing and sibling differentiation, an agent has enough context to select and invoke the tool correctly.

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

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

The input schema is fully described (100% coverage) and already explains that agencyId is optional and deduced from the resource, while resourceId is required by the API. The description does not add new parameter-level semantics, but with complete schema coverage the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: it returns the allowed absence types for a resource (RTT, maladie, congés payés, with their codes) and the default values of an absence request. It also explicitly distinguishes itself from boond_timesheets_default, so an agent can tell exactly what this tool provides.

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

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

Usage guidance is explicit and actionable: use it BEFORE boond_absences_create because workUnitTypeReference is only published by GET /absences-reports/default, and prefer it over boond_timesheets_default when the codes are needed from the absence perspective. It even states that no other tool provides absence types, leaving no ambiguity.

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 flag destructiveHint: true, but the description goes well beyond that: it warns the deletion is irreversible with no trash, explains the confirmation flow when the MCP client supports elicitation (and the alternative direct deletion otherwise), and specifies the return shape including deleted: false on refusal. It also mentions the rights-check to avoid 403s. This is rich, non-redundant behavioral context.

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

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

The description is structured with clear sections (when, rather-than, safety, warning, return format) and uses bullet points. It is a bit long, but every sentence serves a purpose – no filler. Front-loaded with the core action, then conditions, then details. Efficient for a destructive tool with complex behavior.

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 delete tool with an output schema and destructive annotations, the description covers everything needed: the action, conditions, alternative, safety checks, irreversibility warning, confirmation behavior, and return contract. No significant gap remains for an agent to call it correctly.

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

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

The schema already describes `id` with its numeric pattern, so baseline is 3. The description adds a usage prerequisite (verify the ID via boond_absences_get) but does not add new meaning about the parameter itself. That instruction is more about workflow than parameter semantics, so the score stays at the 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 precise action: 'Supprime définitivement un(e) demande d'absence' – a permanent delete. It clearly distinguishes from boond_absences_update, which is for deactivating or changing state without destruction. This leaves no ambiguity about what the tool does or how it differs from its most similar 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?

Explicit 'Quand' condition: only on explicit user request, and after verifying the ID with boond_absences_get. It also names the alternative (boond_absences_update) and states why that is usually the better choice. Additionally, it recommends checking boond_rights_get to avoid a 403. This is a model of 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 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 carry readOnlyHint/idempotentHint/destructiveHint, and the description adds genuine behavioral context beyond them: the resourceId→keywords COMP<id> conversion quirk (API has no dedicated parameter), the fields parameter being a pure MCP-side projection never sent to the API, and the hard pagination refusal beyond pageSize 500 / page 100. These are non-obvious runtime behaviors an agent must 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?

Purpose is front-loaded and the structure is logical: purpose → when/alternatives → API quirk → return → fields note → pagination. The bullets keep it scannable. It is fairly dense but every section earns its place; only minor redundancy with schema (pagination defaults are repeated from the schema, though the 'refus beyond limit' detail is new).

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?

No output schema exists, and the description only states 'Returns: Liste des demandes d'absence correspondantes' without detailing the result structure. For a search tool the list-of-absences return is largely implied, and the description covers the key non-obvious behaviors (fields projection, resourceId conversion, pagination refusal, perimeter join logic). Slightly more output-structure detail would be ideal but is 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% so baseline is 3, but the description adds real meaning beyond the schema: it explains the required startMonth/endMonth format, the resourceId conversion to keywords COMP<id>, the fields projection behavior (replaces summary, unknown names ignored), and the narrowPerimeter ET-vs-OU join semantics. The resourceId quirk alone is high-value information not derivable from 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?

States a specific verb ('Recherche des demandes d'absence'), a precise resource, and the key filter dimensions (période, ressource, état de validation, périmètre). It explicitly differentiates from siblings: boond_planning_absences_search for the calendar view and boond_validations_search for pending validations, so an agent can pick this tool 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?

Provides explicit 'Quand' (when to use) and 'Plutôt que' (rather than) guidance, naming the two relevant sibling tools and the condition that selects them (calendar view vs pending validations). This is textbook routing guidance with no inference required.

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?

With annotations already covering read-only/idempotency, the description adds real behavioral value: partial update semantics and the exception that absencesPeriods replaces all existing periods. However, absencesPeriods is not present in the input schema and is disallowed by additionalProperties:false, which slightly undermines the 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, front-loaded with the core action, and uses short labeled sections plus two focused bullets. 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?

Given no output schema, describing the return as confirmation plus updated record is helpful. The tool is nearly complete, but the reference to absencesPeriods creates a schema/description mismatch that an agent would have to resolve.

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 parameters. The description adds a useful partial-update note, but its mention of absencesPeriods is confusing because that field cannot be provided via this schema, so it does not clearly improve parameter understanding.

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

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

The description opens with 'Met à jour une demande d'absence existante, identifiée par son ID', giving a precise verb, resource, and identifier-based scope. This is clearly distinct from the sibling boond_absences_create, which creates rather than updates.

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 the tool ('pour corriger les dates, le motif ou le commentaire d'une demande déjà déposée') and names the alternative, boond_absences_create, with the condition that selects it (absence doesn't exist yet).

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?

Annotations already declare readOnlyHint=false, so the write nature is structured data; the description adds genuine context beyond that: the mandatory dependsOn attachment, the 422 failure on missing/invalid attachment, companyId's conditional acceptance, and the API-required positioningId tied to positioning-related action types. It discloses error conditions not visible elsewhere, though it stops short of describing auth needs or side effects like counts.

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 short, dense sentences, each earning its place: purpose, routing, constraint set, return. The most important scoping information is front-loaded and the constraint sentence packs the validation rules efficiently with no filler.

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

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

For a 12-parameter creation tool with intricate mutual-exclusivity and conditional-requirement logic and no output schema, this description is complete: it covers the entity types, the update alternative, validation failure modes, positional requirements, and the return value (created action with ID). An agent has everything needed to call 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?

Schema coverage is 100%, so baseline is 3, but the description adds real relational meaning beyond the schema: it ties the five ID params to the dependsOn relation, states the mutual-exclusivity rule among them, clarifies that companyId is only a complement to contactId, and explains positioningId's API requirement with the exact 422 code. This is genuinely additive semantic information about parameter relationships.

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

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

The description opens with a specific verb+resource ('Crée une nouvelle action … dans BoondManager') and enumerates the valid parent entities (contact, candidat, ressource, opportunité, projet). It explicitly names the sibling boond_actions_update, so an agent can distinguish create from update/delete without opening a 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 description explicitly routes the agent: 'Plutôt que : boond_actions_update pour compléter une action déjà enregistrée plutôt que d'en créer un doublon.' It names the alternative tool and the exact condition that should select it, plus documents hard constraints (mutual exclusivity, 422 failure). Nothing is left to 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 though annotations already mark destructiveHint=true, the description adds critical context: the operation is irreversible with no API-side trash, a rights check can avoid a 403, and elicitation-capable clients will trigger user confirmation with structuredContent.deleted set to false on refusal. This goes well 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 well-structured with clear sections: core action, when to use, preferred alternative, safety notes, confirmation behavior, and return contract. Every sentence carries meaningful safety or routing information, and the irreversible warning is prominently placed.

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 mutation tool, the description covers all essential context: explicit user consent, ID verification, permission pre-check, irreversibility, conditional confirmation flow, and return-value semantics. There is no meaningful gap an agent would face when deciding whether and how to call this tool.

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

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

The schema covers 100% of the single parameter with a description, so the baseline is 3. The tool description does not add new parameter syntax or meaning, though it sensibly advises verifying the ID before deletion via boond_actions_get, which is usage guidance rather than parameter semantics.

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

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

The description opens with a precise verb and resource: "Supprime définitivement un(e) action de BoondManager." It clearly states a permanent delete operation, which distinguishes it from related siblings like boond_actions_update and boond_actions_get without requiring the agent to infer anything.

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 (only on explicit user request, after checking the ID with boond_actions_get) and when not to (prefer boond_actions_update for deactivating or changing state). It also points to boond_rights_get as a pre-flight permission check, giving the agent actionable routing and prerequisites.

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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral details beyond this: the keyword conversion for entity IDs, the pagination limits (pageSize 1–500, page 1–100) with refusal beyond those, and the fact that the `fields` parameter is a projection never sent to the API. This enriches the agent's understanding of how the tool behaves without contradicting 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 fairly long but well-structured: it opens with the core purpose, then provides 'Quand' and 'Plutôt que' guidance, and closes with notes on `fields` and pagination. Each sentence earns its place and is front-loaded with the most important information. It is not bloated; the length is justified by the tool's complexity.

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

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

For a tool with 26 optional parameters, no required fields, and no output schema, the description covers the essential context: when to use, what it returns, and key behavioral caveats. It does not explicitly describe the response structure (e.g., fields available in the summary), but the schema provides parameter details. The description is complete enough for an agent to invoke the tool correctly for typical searches, though it could mention how `sort`/`order` interact with 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 the baseline is 3. The description provides a high-level overview of parameter categories (entity, type, period, perimeter) and explains the `fields` and pagination semantics, but most parameter details (e.g., date patterns, enums) are already in the schema. The description does not add significant meaning beyond what the schema provides; it mostly summarizes and clarifies a few points.

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 verb 'Rechercher' and the resource 'actions' with a detailed list of filter categories (entity, type, period, perimeter). It explicitly differentiates itself from entity-specific action tabs by naming the siblings (boond_candidates_actions, boond_companies_actions, etc.) and the use case (multiple entities). This is a specific, unambiguous 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 provides explicit 'Quand' (when) and 'Plutôt que' (rather than) guidance, telling the agent to use this tool for scanning history across multiple entities and to prefer entity-specific tabs when the entity is known. It also notes that entity ID filters are converted to keywords, clarifying an API quirk. This is exemplary 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description adds important behavioral detail: only provided fields are modified, no relations are sent, existing dependsOn/positioning/calendar sync is preserved, and `text` replaces rather than appends. This is exactly the kind of non-obvious behavior an agent needs.

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 dense but efficient: main action, partial-PUT semantics, alternative, safety warning, use case, and return value, all in a compact, well-organized structure. Every sentence earns its place.

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

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

For an update tool, the description is complete enough: it covers the operation type, the scope of changes, the behavioral guarantees about relations, the alternative to create, and the return value. The annotations and schema cover the rest.

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

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

The input schema already documents all parameters with 100% coverage, so the description does not need to re-explain them. It adds value by stating that omitted relation fields are preserved and that `text` is a replacement operation, which gives the agent a clearer mental model of partial updates.

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: "Met à jour une action existante dans BoondManager" and clarifies the partial-PUT semantics. It also explicitly differentiates itself from `boond_actions_create`, making the boundary between update and create obvious.

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 directly tells the agent when not to use this tool: "Plutôt que : `boond_actions_create` si l'action n'existe pas encore." It also contrasts the update with delete + recreate, explaining that update is the safe path when preserving calendar/agenda data matters.

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 'Écriture non idempotente', consistent with idempotentHint=false, and adds a useful reliability caveat: the body was inferred from models.advantage and is 'non éprouvé sur un tenant de test'. It also tells the agent the return contains a confirmation and advantage ID. It does not cover auth or errors, but annotations already cover read-only/destructive aspects.

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/alternative, caveats, and return value are each in short labeled blocks. There is no filler, and the most important usage constraint 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 12-parameter create operation with full schema descriptions and an output schema, the description supplies the key workflow context, the deduplication warning, non-idempotence, and an implementation caveat. It does not enumerate validation or error behavior, but nothing essential for selecting and invoking the 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?

Schema coverage is 100% and every parameter already has a description in the input schema. The prose adds a high-level grouping via 'models.advantage' and mentions relationships (resource/contract/project/delivery), but it does not add new per-parameter semantics beyond the schema. 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 opens with a specific action and resource: 'Attribue un avantage ... à une ressource', with concrete examples (tickets restaurant, mutuelle, véhicule). It also differentiates from siblings by saying to use it after boond_advantages_default and instead of boond_advantages_search first.

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 workflow guidance: run boond_advantages_default first to know types and amounts, and do not call boond_advantages_search first because the API does not deduplicate. This is clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it is a GET request ('GET /advantages/default') and that the response is returned 'telle quelle', plus a clear description of the payload contents (pre-filled JSON with included advantage types). 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 concise and well-structured: it opens with the primary purpose, then clarifies when to use it versus a sibling, and concludes with a brief note on HTTP method and return format. Every sentence serves a purpose with no redundancy.

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

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

Given the tool's simplicity (a read-only getter for defaults), the annotated safety profile, and full schema coverage, the description is complete. It explains the return value ('JSON de l'avantage vide pré-rempli, avec les types d'avantage inclus'), covers usage timing, and meets the needs 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 description coverage is 100%, so all four parameters are documented in the input schema. The description adds no detailed semantics beyond the schema—it only hints that the response is tied to a resource. The baseline of 3 is appropriate because the schema does the heavy lifting.

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 ('Renvoie') and resource ('valeurs par défaut d'un avantage pour une ressource'), clearly identifying what the tool provides. It explicitly contrasts with boond_advantages_search and situates itself before boond_advantages_create, making sibling differentiation unambiguous.

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

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

Explicitly states when to use ('AVANT boond_advantages_create') and when not to ('Plutôt que boond_advantages_search pour les avantages déjà attribués à la ressource'). Also notes the read-only nature, leaving no ambiguity about the tool's role.

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?

Beyond the readOnlyHint/idempotentHint annotations, the description reveals important runtime behavior: the underlying route is GET /resources/{id}/avantages, fields is a client-side projection never sent to the API, and page/pageSize beyond the limits are refused. 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 structured with a one-line purpose, an alternative-usage note, then compact bullets for fields and pagination. Every sentence carries distinct information and the most important constraint (resourceId required, no global endpoint) appears near the beginning.

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 filtered list tool with full parameter schema coverage and safety annotations, the description is complete: it covers the required parameter, the endpoint constraint, the type filter format, projection behavior, and pagination limits. The short 'Returns' line is sufficient given that no output schema exists but the result type is a list of the resource's advantages.

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 describes all parameters at 100% coverage, the description adds genuinely new semantics: the API route implied by resourceId, the <reference>_<agencyId> format for advantageTypes, the MCP-side behavior of fields, and precise pagination limits. This goes well beyond the baseline schema content.

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—'Liste les avantages ... d'une ressource'—and immediately names the closest sibling, boond_resources_advantages, with the condition under which this tool should be preferred. This makes the tool's purpose and its distinction from siblings explicit.

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 tells the agent to use this tool instead of boond_resources_advantages when starting from a specific resource, and states that resourceId is mandatory because no global GET /advantages endpoint exists. It also recommends using fields for large pages and documents pagination refusal behavior, giving concrete selection and invocation 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?

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=false, but the description goes further by stating 'Lecture seule', clarifying that GET /alerts returns configuration not occurrences, noting no filters/pagination, and explaining that `fields` is client-side projection never sent to the API. This is rich behavioral context beyond annotations.

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

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

The description is long but every section serves a purpose: main purpose, when to use, alternatives, technical details, return structure, and parameter guidance. It uses clear labels ('Quand:', 'Plutôt que:', 'Returns:', 'fields:') and front-loads the primary use case. No redundant or filler 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?

The tool is relatively complex (configuration vs. occurrences, mapping to multiple search tools), and the description covers all necessary aspects: the meaning of `period`, `perimeter`, state IDs, and the absence of filters/pagination. It also explains the output structure and provides the `fields` parameter semantics. With an output schema present, return values are already defined; the description fills in the behavioral context needed 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?

Although the schema fully describes the `fields` parameter (100% coverage), the description adds meaningful semantics: it explains that `fields` replaces the summary with only listed attributes, that unknown names are ignored, and that it should be used on large pages. This goes beyond the schema's description and helps the agent use the parameter effectively.

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 lists alert indicators configured on the user's dashboard, with specific examples (contract endings, trial periods, CRA/notes/absences not validated, upcoming actions). It distinguishes itself from sibling search tools by explaining it returns configuration, not occurrences, and explicitly notes the difference from `boond://alerts/me`.

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

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

It provides explicit usage guidance: 'Quand : en premier, pour « qu'est-ce qui demande mon attention aujourd'hui ? »' and 'Plutôt que :' naming alternatives. It also maps each indicator type to the corresponding search tool and parameters, leaving no ambiguity about when to use this vs. 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?

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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds substantial context beyond that: the single API endpoint behavior, server-side caching with TTL 1h configurable via BOOND_DICTIONARY_TTL_MS, sub-tree extraction by dotted path, isError: true with faulty path on miss, and the invalid legacy 'states/resources' slash form. 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 long but logically structured with clear section headers (Quand, Plutôt que, API behavior, Chemins usuels, Returns) and is front-loaded with the core purpose. The common-paths list is arguably the most actionable content for an agent. Minor deduction for length, but every section earns its place.

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

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

Complete for this tool: no output schema exists, so the description explains the return format ('souvent un tableau {id, value, …}, ou isError: true'). With 1 well-documented parameter, clear annotations, and coverage of purpose, usage, behavior, paths, and errors, nothing an agent needs to call 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 coverage is 100% for the single parameter dictionaryType, which is already well documented with examples and the slash-form caveat. The description goes further with a 'Chemins usuels' list enumerating ~15 concrete paths (setting.state.resource, setting.tool, country, languages, etc.), giving agents far more than 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?

The description opens with a specific verb+resource: 'Récupère un dictionnaire de référence BoondManager (états, types, pays, devises, langues, outils, expertises, ...)'. It clearly states what the tool retrieves and lists concrete dictionary categories. None of the ~200 sibling tools perform dictionary lookups, so it is easily distinguished.

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?

Has an explicit 'Quand' section stating when to use it (to translate a BoondManager state/type between integer ID and label before filtering a search) and a 'Plutôt que' section naming the alternative: boond://dictionary/* resources for common tables, with the condition that those suffice and only non-published tables require this tool. This is exemplary when/when-not/alternatives 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, 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 adds crucial context: irreversibility, absence of trash, confirmation flow contingent on elicitation capability, and the returned deleted flag semantics. It also explains how a refusal cancels the call. No contradiction with annotations; it enriches 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 well-structured with clear sections (Quand, Plutôt que, bullets, Returns). It packs essential information without redundancy. Each sentence adds value, and the most critical facts (permanent delete, alternatives) are 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?

Given the single parameter, existing output schema, and annotations covering destructive behavior, the description goes beyond the minimum. It covers usage conditions, alternatives, rights check, irreversibility, confirmation behavior, and return format. Nothing essential is missing for an agent to invoke correctly.

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

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

Schema coverage is 100%, so the id parameter is already documented. The description does not add additional meaning about the parameter beyond the schema, but it does emphasize verifying the ID via another tool, which is more of a usage guideline than parameter semantics. 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+resource ('Supprime définitivement un(e) candidat') and clearly distinguishes from the sibling update tool by explaining when to use delete vs update. It also notes the permanence and lack of trash, making the purpose unambiguous.

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

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

Explicitly states when to use (on explicit user request after verifying ID with boond_candidates_get) and when not to (prefer update for deactivation). Names the alternative tool and the rights-check tool (boond_rights_get), providing 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?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds valuable behavioral context: without `tab`, only the base record is returned rather than a merge of tabs; an unknown ID returns the raw BoondManager error; and the ID must come from a search, never from guessing. This meaningfully informs agent expectations.

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

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

The description is front-loaded with the primary action and then organizes supporting guidance into clear 'Quand', 'Plutôt que', bullet notes, and a Returns line. Each sentence carries useful information, and there is no redundant 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 read-only getter with two parameters and no output schema, this description is complete: it identifies the ID source, explains the optional tab parameter, describes the response shape at a useful level, states the error behavior, and declares read-only semantics. An agent has enough 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?

The schema already describes both parameters with 100% coverage, so the baseline is 3. The description adds extra semantic value by clarifying that `tab` targets a specific tab and that omitting it returns only the base record, not an aggregate. This exceeds the schema alone without needing to fully compensate for a coverage gap.

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

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

The description opens with a specific verb, resource, and identifier ('Récupère la fiche complète d'un(e) candidat par son ID numérique'), making the tool's core function unmistakable. It also explicitly contrasts itself with boond_candidates_search and boond_find, which differentiates it from the most likely sibling alternatives.

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

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

The description states exactly when to use the tool ('après un boond_candidates_search') and when not to ('Plutôt que : boond_candidates_search si l'ID n'est pas connu... ou boond_find pour résoudre un nom / un e-mail en ID'). It also explains the optional tab behavior, giving an agent clear selection criteria.

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

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

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?

Even with annotations declaring read-only, open-world, and idempotent behavior, the description adds meaningful runtime facts: fields is a client-side projection never sent to the API, unknown field names are ignored, page sizes beyond 100 are refused, and hired candidates disappear from this search. These details materially change how an agent should invoke and interpret the 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 long, but deliberately structured: scope first, sibling distinction second, then compact bullet groups covering the full parameter space. Every block adds practical value, and the length is justified by 36 optional filters; it is not padded, though a shorter summary of the most common paths would make it slightly easier 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 the tool's complexity, the output schema, and the annotation coverage, the description is complete: it covers the main filter families, projection behavior, pagination limits, result shape, and detail-tool routing. An agent has everything needed to decide when to call it and how to construct a valid request.

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 describes every parameter, the description adds actionable grouping and composition knowledge: '#AND#' for tools, languageId|levelId format, perimeterDynamic shortcuts, perimeterManagersType main/hr, period values, and geoDistance range. It explains why certain dictionaries matter and how to express common searches, which goes well beyond the raw schema.

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

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

The description opens with a specific verb and resource, 'Recherche des candidats dans BoondManager avec filtres serveur', and immediately distinguishes it from boond_resources_search by noting that candidates and resources are separate repositories and that a hired person stops being findable here. This gives an agent a crisp, non-ambiguous identity for the 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?

It explicitly tells the agent when to prefer this tool over boond_resources_search, and names boond_candidates_get and tab tools for follow-up detail. The bulleted use cases map abstract user goals (e.g. 'Mes candidats', technical profile, sourcing, period) to concrete parameter combinations, so an agent can pick filters without guessing.

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.