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

Les annotations indiquent déjà readOnly, openWorld, idempotent. La description ajoute que l'outil nécessite un abonnement à l'API « ROME 4.0 - Fiches métiers », ce qui est une information comportementale utile au-delà des annotations. Pas de contradiction.

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 fait trois phrases concises : fonction principale, cas d'usage, condition d'accès. Chaque phrase apporte une information utile sans redondance.

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

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

Pour un outil à 2 paramètres sans schéma de sortie, la description est complète : elle explique ce que contient la fiche (groupes de compétences et savoirs) et mentionne l'abonnement requis. La structure de la réponse n'est pas décrite, mais l'absence de schéma de sortie rend cela acceptable.

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

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

La couverture du schéma est de 100 %, donc le schéma documente déjà les paramètres. La description n'ajoute pas de signification supplémentaire au-delà de ce qui est dans le schéma (code ROME, format de sortie).

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

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

La description indique clairement que l'outil récupère la fiche métier détaillée (Fiche ROME) avec les groupes de compétences et savoirs pour un code ROME. Elle se distingue des outils frères (ft_get_metier, ft_get_offre, etc.) par sa spécificité.

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

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

La description fournit des contextes d'utilisation concrets: préparation de CV, identification de compétences, compréhension des attendus. Manque toutefois une mention explicite des cas où ne pas l'utiliser ou des 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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's disclosure of subscription requirement adds some context beyond annotations. However, it does not elaborate on other behavioral aspects like rate limits or data freshness. No contradictions with annotations.

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

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

The description is only two sentences: one for the core functionality with example, and one for the prerequisite. No redundant words. Front-loaded with purpose and example. Excellent conciseness.

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 (2 parameters, no output schema) and rich annotations, the description covers the key aspects: purpose, code format, subscription requirement. It does not describe the response format parameter, but that is covered by schema enum. Overall, it is sufficiently complete for an agent to use 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 50%: 'code' parameter has a description and pattern, 'response_format' has an enum but no description. The description adds meaning for the 'code' parameter (format example) but does not mention 'response_format' at all. Baseline 3 is appropriate as schema does some work but description could add more.

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 'Récupère' (retrieves) and the resource 'fiche d'un métier ROME 4.0 par son code'. It specifies the code format (5 characters, ex. 'M1607') and what is included (libellé, définition, accès, arborescence). This is specific and distinguishes the tool from siblings like ft_search_metiers.

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 mentions the prerequisite of subscription to the API. However, it does not provide guidance on when to use this tool versus its sibling 'ft_get_fiche_metier', which appears to have a very similar purpose. No explicit when-not or alternatives are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds error behavior (404) and return format options, which goes beyond annotations. No contradictions; description complements structured hints.

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, front-loaded with purpose, no fluff. Efficiently conveys function, inputs, outputs, and error conditions. Every sentence adds value.

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, description adequately lists returned fields. Covers error scenario. With annotations providing safety and idempotency, additional details (e.g., rate limits, pagination) are not critical. Completeness is adequate but not exhaustive.

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% (both parameters documented). Description adds real-world context (example '209WHZN') and explains purpose of the ID. Does not add new semantics for response_format beyond enum values. 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?

Description explicitly states it retrieves full details of a job offer by ID, lists returned fields (title, company, location, etc.), and distinguishes from sibling tool ft_search_offres which returns offer lists. Clear verb 'Récupère' + resource 'détail complet d'une offre'.

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?

Describes when to use: after obtaining ID from ft_search_offres. Implicitly suggests using ft_search_offres for listing and this tool for details. Mentions error 404 for invalid or expired IDs, providing context for error handling. No explicit alternatives or exclusions, but clear enough.

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 behavioral context beyond annotations: it reveals the tool returns a mapping (codes ↔ libellés), hints at large result sets for 'communes', and implies the need for client-side filtering. No contradictions; the description enriches the agent's understanding of 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 extremely concise: four sentences in French with no filler. The first sentence states the core purpose, the second justifies importance, the third lists all types, and the fourth provides a practical tip. Every sentence adds value. 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?

Given the tool has no output schema, the description adequately explains the return type (codes ↔ libellés) and includes all necessary usage context (available types, tip for long lists). The annotations cover safety and idempotency. A slight gap is the lack of detail on output format or pagination behavior, but the description is sufficient for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds minimal added meaning beyond the schema: it echoes the 'filtre' parameter indirectly by suggesting filtering for 'communes' and mentions the default limit is 100 (not in schema). However, it does not elaborate on the exact semantics or constraints beyond what the schema already provides.

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

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

The description uses a specific verb ('Restitue' meaning 'returns') and resource ('référentiel de codes'), clearly stating it lists a reference table of code-to-label mappings for job offers. It explicitly enumerates all 16 available types, making the tool's scope unambiguous. The description distinguishes this from sibling tools (e.g., ft_search_offres, ft_search_metiers) by focusing on static reference data rather than search or prediction.

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 explains when to use the tool: 'Indispensable pour traduire un nom en code' and provides concrete examples (finding INSEE code of a town, contract type codes). It also offers a practical tip for handling the 'communes' list. While it does not explicitly state when not to use it or name alternatives, the context sufficiently guides the agent.

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

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

Annotations already mark the tool as readOnly, openWorld, idempotent, and non-destructive. The description adds important behavioral context: it returns predictions sorted by score, requires an API subscription ('Nécessite l'abonnement à l'API « ROMEO 2 »'), and allows adjusting thresholds. No contradictions with annotations.

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

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

The description is two concise paragraphs, front-loaded with the verb and resource in the first sentence. Every sentence adds value: purpose, use with siblings, output behavior, threshold guidance, and subscription requirement. 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?

Given no output schema, the description explains the return format (predictions sorted by score). It covers the required subscription, parameter guidance (seuilScore), and the primary use case. It is sufficiently complete for a prediction tool of moderate complexity, though it could mention pagination or error handling.

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 describes 3 of 4 parameters (75% coverage). The description adds usage guidance for seuilScore ('Ajustez … pour ne garder que les prédictions fiables') but does not significantly enhance the semantic meaning of intitule or nbResultats 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 starts with a specific verb ('Utilise ROMEO 2 pour rapprocher') and clearly states the resource (intitulé to ROME codes). It distinguishes from siblings by explicitly offering to convert free text into codes usable by ft_search_offres and ft_search_entreprises, which no other sibling tool does.

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

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

The description gives clear context: 'C'est le meilleur moyen de convertir … en code ROME exploitable par ft_search_offres et ft_search_entreprises.' It also advises adjusting seuilScore for reliability. Although it does not explicitly list when not to use it, the sibling tools are sufficiently different (get_offre, search_metiers) that the main use case is unambiguous.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds valuable context: the search is case/acent-insensitive, the ROME codes are 5 characters, and the referential contains 532 métiers. This goes beyond annotations but could elaborate on error handling or rate limits.

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

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

The description is a single paragraph but logically structured: main purpose, output format, interoperability, search behavior, alternative recommendation, and prerequisite. Each sentence contributes meaning, though it could be slightly more terse without losing clarity.

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 presence of an output schema (not shown but indicated), the description adequately covers input, behavior, output usage, and alternatives. It provides sufficient context for an AI agent to understand when and how to use the tool effectively.

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 descriptions for both parameters. The description adds value by explaining how the output codes are used in other tools, providing examples for the query parameter, and stating the case-insensitivity behavior. This enhances understanding beyond 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 clearly states the verb 'recherche' (search), the resource 'métier dans le référentiel ROME 4.0', and the output 'codes ROME correspondants'. It differentiates from the sibling tool ft_predict_rome by noting when to use the alternative for finer semantic matching.

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 (free text search), when not to (prefer ft_predict_rome for semantic matching), and provides context about how results feed other tools (ft_search_offres, ft_search_entreprises). Also mentions a subscription requirement, which is a necessary prerequisite.

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

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

The description discloses key behaviors such as real-time search, pagination details, maximum result depth, and error codes (400, 403). It also explains special cases for Paris/Lyon/Marseille commune codes. Annotations already indicate readOnlyHint=true and idempotentHint=true, and the description consistently portrays a safe, read-only operation. While it covers many aspects, it does not mention rate limits or data freshness beyond 'temps réel', which prevents a top score.

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

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

The description is well-structured with a clear purpose sentence, a bulleted parameter list, examples, and error information. However, it is somewhat verbose; some parameter details are repeated (e.g., commune code explanation appears both in the bullet and later). The front-loading of purpose is good, but conciseness could be improved.

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 (18 parameters, zero required, multiple interdependent filters) and the presence of an output schema, the description covers all necessary aspects: what it returns (paginated summaries with total), pagination, error handling, and examples. The description is fully sufficient for an AI agent to 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 already has 100% coverage with descriptions for all 18 parameters. The description adds significant value by grouping parameters, explaining constraints (e.g., allowed characters for motsCles, co-dependency of salaireMin and periodeSalaire), and clarifying edge cases (e.g., arrondissement codes for Lyon). Examples further illustrate parameter usage.

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 'Recherche multicritères dans les offres d'emploi France Travail (temps réel). Renvoie une liste paginée de résumés d'offres + le total de résultats correspondants.' This verb+resource combination precisely defines the tool's function, and it distinguishes from sibling tools like ft_get_offre (single offer retrieval) and ft_search_metiers (job type search).

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

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

The description provides excellent guidance on when to use the tool, including examples, pagination limits (max 1150 results), and references to sibling tools for auxiliary lookups (e.g., ft_predict_rome for ROME codes, ft_list_referentiel for geographic codes). However, it does not explicitly state when not to use this tool versus alternatives like ft_get_offre, missing a clear exclusion statement.

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