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

With no annotations, the description carries the full burden. It does add one useful behavioral fact — 'Une seule reponse, deja calculee' tells the agent this is a single, pre-computed read-style response rather than an iterative/streaming operation. However, it says nothing about permissions, side effects, rate limits, or freshness of the computation.

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?

Two compact sentences, front-loaded with the core purpose followed by the returned outputs. No filler, though the second sentence's value overlaps with the output schema.

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

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

For a 2-parameter analysis tool with an output schema, the description covers purpose and outputs adequately (return values needn't be restated). The notable gap is candidats_max, whose behavior and bounds are left entirely unexplained.

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 only 50%: mission_id is documented in the schema, but candidats_max (the cap on returned candidates, default 3, max 10) is undocumented in both schema and description. The description adds no parameter meaning and does not compensate for the 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 gives a specific verb ('Evalue') and resource ('quels collaborateurs peuvent couvrir une mission') and enumerates the analysis dimensions returned (score d'adequation, ecarts de competences, cout estime, alerte budget). This is clearly distinct from the lookup/mutation siblings (obtenir/rechercher/reserver_collaborateur), though it never names them explicitly.

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

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

Usage is implied by the purpose (analyse staffing coverage for a given mission), but there is no explicit when-to-use guidance, no prerequisites, and no routing to or away from siblings like rechercher_collaborateurs. The agent must infer the trigger condition.

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?

No annotations are provided, so the description carries the burden. 'Fiche détaillée' plus the listed fields make clear this is a read/retrieval operation and disclose the substantive return content, but it says nothing about read-only semantics, auth requirements, or behavior when the id is unknown.

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

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

A single front-loaded sentence with no filler; the returned-field list is the essential information and nothing 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?

With no output schema, the description usefully enumerates the key returned fields, so an agent knows what it gets back. It could still mention error/not-found behavior, but for a one-param read tool it is largely complete.

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

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

Schema coverage is 100% and the single 'id' parameter is fully documented in the schema with an example ('c-001'), so the description adds nothing about it. Baseline 3 is appropriate when the schema does the work.

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+resource (retrieve a collaborator's detail sheet) and enumerates the returned content (rated skills, TJM, languages, monthly availability), which distinguishes it from the search-oriented sibling rechercher_collaborateurs. It does not explicitly name or contrast with siblings, keeping it short of a 5.

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

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

Usage is only implied: fetch a full profile for a known collaborator. There is no explicit statement of when to use this instead of rechercher_collaborateurs (search) or reserver_collaborateur (booking), and no prerequisites are given.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose two useful traits beyond the schema: results are a short list and are sorted by skill level then availability. However, it says nothing about authentication requirements, rate limits, empty-result behavior, or what constitutes 'disponible', which are relevant for a staffing search.

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?

Two sentences, both earning their place: the first states purpose and filter axes, the second states the return shape and ordering. Front-loaded and free of redundancy.

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

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

With six parameters, no required fields, and no output schema, the description should say more about what the returned collaborator entries contain and how vacancy/jours_min interact. It covers the ranking rule and result size but leaves the returned fields and matching semantics unspecified.

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

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

Schema description coverage is 100%, with each of the six parameters documented (format for mois, enum values for agence, bounds for limite, jours_min, niveau_min, lowercase convention for competence). The description only names three of the six filter axes and adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

The description gives a specific verb (Recherche) and resource (collaborateurs) plus the three filter axes (competence, agence, mois), so the agent knows exactly what it returns. It does not, however, explicitly differentiate itself from siblings like obtenir_collaborateur or analyser_staffing_mission, which an agent must infer.

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

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

Usage is implied by the verb 'recherche' and the filter parameters, so an agent can guess this is the discovery step before reserver_collaborateur. There is no explicit when-to-use statement, no mention of when to prefer obtenir_collaborateur for a single known person, and no exclusions.

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

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

With no annotations, the description carries the full burden and does disclose one meaningful trait: explicit failure when collaborator, mission, or capacity are invalid. However, for a mutation it omits idempotency, permission requirements, and whether it overwrites or coexists with existing reservations.

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?

Two tight sentences with the action front-loaded and the failure condition following. No filler, though it could be marginally sharper about the mutation's side effects.

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 4-required-param mutation with no annotations and no output schema, the description covers purpose and failure mode but leaves conflict handling, permissions, and post-condition behavior unstated. Adequate but with clear gaps.

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

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

Schema coverage is 75%, with mission_id, collaborateur_id and jours already documented and mois self-describing via a pattern. The description loosely maps to all four inputs but adds no syntax or semantic detail beyond the schema, so the baseline 3 is correct.

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+resource: placing a day reservation on a collaborator for a given month. The purpose is immediately clear and distinguishable from the read-only siblings (obtenir/rechercher/analyser). It stops short of 5 because it never names or contrasts with those 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?

No when-to-use guidance, no prerequisites, and no routing to alternatives. The mention that it fails on capacity hints that a pre-check might be relevant (e.g. analyser_staffing_mission), but that connection is left entirely to inference.

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