france-data-mcp

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by stating that at least one of nom, codePostal, or code is required, which is a key behavioral constraint not fully captured in the input schema (no required parameters).

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

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

The description is three sentences long, front-loaded with purpose and source, then constraints, then aliases. Every sentence adds value with no redundancy or fluff.

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

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

The description covers purpose, constraints, and aliases well, but with no output schema, it could mention what the tool returns (e.g., a list of communes with basic fields). This omission slightly reduces completeness for a tool with 5 parameters.

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 semantic value beyond the schema by providing aliases (e.g., q/query → nom) and explicitly stating the requirement for at least one parameter. The schema also includes examples, but the description's aliases enhance discoverability.

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

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

The description clearly states the tool searches French communes by name, postal code, or INSEE code, and is ideal for autocomplete. It is specific but does not explicitly differentiate from sibling get_commune_by_code, which might be more appropriate for exact code lookup.

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 minimal usage guidance: it notes the tool is ideal for autocomplete and mentions the data source. However, it does not specify when to use this tool over siblings like get_commune_by_code, nor does it state when not to use it.

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

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

Annotations already indicate readOnlyHint, idempotentHint, and openWorldHint. The description adds valuable behavioral details: data source (Annuaire santé Ameli, synced weekly), latency (~1 week for new CDS), cache behavior (5 min server-side), and the effect of `include_freshness`. It also explains the output structure (LookupResult discriminated by `found`). This goes well beyond annotations, providing a rich behavioral profile.

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

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

The description is a single paragraph but well-organized with key information front-loaded (purpose, differentiator, output structure). Each sentence adds value—failure conditions, source, alternative tool, aliases. It is slightly dense but avoids fluff. A bit more structuring (e.g., bullet points) could improve, but it is efficient overall, earning a 4.

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

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

Given the tool has an output schema and the description provides detailed coverage of inputs, outputs, failure modes, data source, freshness, and relationships to other tools, it is highly complete. The description explains the discriminated union, latency, and when to use alternatives, leaving no obvious gaps. A strong 5.

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 extra context: for `num_finess`, it mentions accepted aliases (numFiness, finess, etab_finess). For `include_freshness`, it explains the opt-in nature, the added field, and the negligible cost. This enhances understanding beyond the schema alone, warranting a 4.

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

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

The description clearly states the action: 'Récupère le détail d'un Centre de Santé (CDS) par son numéro FINESS.' It distinguishes from the sibling tool `etablissement_by_finess` by highlighting the specific data fields exposed (carte_vitale, APCV, specialties). This meets the 5-level: specific verb+resource and differentiator from siblings.

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

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

The description explicitly advises when not to use this tool: 'Pour les structures non-CDS, utiliser `etablissement_by_finess`.' It also explains when the lookup may return not found (non-CDS or very recent CDS). While it doesn't compare to all 33 siblings, the guidance provided is clear and actionable, earning a 4.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds valuable context: coordinates are centroïdes of communes (≈3 km avg), no schedules/tariffs, and aliases for parameters. 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 relatively long but well-structured with clear sections. Every sentence adds value, and the main function is front-loaded. Minor reduction in score due to length, but still efficient.

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

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

Given the complexity (8 parameters, output schema exists), the description covers all essential aspects: data source, update frequency, filters, edge cases (deprecated codes), and limitations (no schedules/tariffs). It is complete for agent understanding and usage.

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 baseline is 3. The description adds meaning beyond the schema by explaining the any-of logic for specialite_codes, the practical use of accepte_carte_vitale (audits), and the deprecated status of type_etab_codes ['125']. It also notes accepted aliases for parameters.

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 searches for Centres de Santé within a geographic radius using PostGIS ST_DWithin. It distinguishes itself from the sibling tool `etablissements_finess_in_radius` by listing specific exposed fields (carte_vitale, APCV, specialties) and explicitly mentions the differentiation.

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

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

The description provides explicit guidance on when to use this tool (for CDS, not other establishments) and names the alternative `etablissements_finess_in_radius` for filtered family=124. It also states what the tool does NOT provide (horaires/tarifs), giving clear context for appropriate usage.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is known safe. Description adds detailed behavior: returns two addresses, score_dice (with null case), statut with four cases explaining divergence, and handles not_found for non-CDS. No contradictions.

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

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

Description is long but well-structured with bullet points for statut cases and clear examples. Could be slightly more concise, but the detail is justified given 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?

Given output schema exists and the tool has multiple status cases, description fully explains each statut, score_dice behavior, and the not_found scenario with alternative guidance. Very 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?

Only one parameter num_finess, with schema description covering format. Description adds semantics that the finess must correspond to a CDS, which is not in the schema, enriching 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?

Description clearly states it compares addresses from CNAM vs FINESS for a given num_finess, and distinguishes itself by noting it is the 'equivalent côté centre de santé de compare_raison_sociale_finess_vs_rpps'.

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

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

Explicitly says when to use (signal a move propagated by one source but not the other), provides an example, and states when not to use (non-CDS finess) with an alternative tool (etablissement_by_finess).

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 set readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds detailed behavioral context: it returns two labels and a comparison status, describes the three possible statut values ('exact_match', 'divergent_after_normalization', 'rpps_absent'), and explains the not_found case. No contradictions.

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 introductory sentence, bullet-pointed statut explanations, and no redundant text. It could be slightly more concise, but each 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 the presence of an output schema, the description still covers all essential aspects: use case, return format, edge cases (not found), and statut details. It is complete for a simple tool with one parameter.

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% coverage with a clear description for num_finess ('exact 9-digit number'). The description does not add new parameter information beyond that, but schema coverage is high, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool compares 'raison sociale' between FINESS DREES and RPPS/Annuaire Santé ANS for a given num_finess. It uses a specific verb ('compare') and resource, and distinguishes itself from sibling tools like compare_adresse_cnam_vs_finess by focusing on name comparison.

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

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

The description explicitly states it is a 'primitive brute SANS interprétation métier' and explains when to use it (e.g., to detect rebranding after M&A). It also clarifies what it does not do (does not indicate acquisitions) and provides alternative context.

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

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

Beyond annotations (readOnlyHint, idempotentHint, etc.), the description adds significant behavioral detail: the data source (DGFiP DVF actual geolocated sales), that it returns quartiles and volume, the exclusion of commercial properties, and the proxy nature for professional premises. 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 dense but well-structured: first sentence defines main output, then exclusions, then source, then proxy note, then usage caveat. It is slightly long but every sentence adds value. Front-loaded with the core function and key constraints.

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 returns multiple statistics (median, quartiles, volume) and has an output schema, the description sufficiently covers what the tool does, its limitations, source, and appropriate usage. It is complete for an AI agent to select and 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?

The input schema already has 100% description coverage for all parameters (lat, lon, rayon_km). The description does not add new parameter-specific information; it only describes the overall output. Baseline score of 3 is appropriate as 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 clearly states the tool returns median residential property price per m², quartiles, sales volume, and period for a given point and radius. It explicitly distinguishes itself by specifying 'RÉSIDENTIEL bâti — maisons + appartements UNIQUEMENT, PAS les locaux commerciaux/professionnels', differentiating from tools that might return commercial prices or other real estate data. The verb 'coût du foncier' plus 'prix médian au m²' is specific and unambiguous.

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

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

The description provides clear context: it is for business case implantation but warns not to integrate into an attractiveness note. It also notes that for professional premises, the residential price is a proxy. However, it does not explicitly mention when to use this tool over siblings like 'dynamique_immobiliere' or others, though the exclusion of commercial properties implicitly guides usage.

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

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

Annotations declare readOnlyHint=true and idempotentHint=false. The description adds behavioral details: a 5-minute server cache, a single SELECT cost at worst on ingest_log, and the fact that live sources are not listed. This informs the agent about performance and data freshness behavior 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 well-structured, front-loading the main purpose and listing details in subsequent sentences. It is fairly long but every sentence adds value. Minor redundancy could be trimmed, but overall clear and concise.

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

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

Given no input parameters and an existing output schema, the description thoroughly explains all aspects: the sources, returned fields, usage context, alert thresholds, excluded sources, and caching behavior. It is complete and leaves no 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?

With 0 parameters and schema coverage 100%, baseline is 4 per guidelines. The description explains the output fields and staleness thresholds, adding meaningful context for interpreting results, though no parameters are present.

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 identifies the tool's purpose: returning data freshness for specific ingested sources (FINESS, Ameli, RPPS, Centres de Santé). It lists the exact sources and the fields returned, and distinguishes from sibling tools that perform specific queries or analyses.

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

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

The description explicitly states typical usage before territorial audits or time analyses. It provides concrete alert thresholds for staleness (e.g., >90 days for FINESS) and names which sources are excluded (live APIs). This gives 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 read-only, idempotent, and non-destructive. The description adds significant behavioral details: no automatic business interpretation, empty results without error if ANS/Ameli codes are confused, default category (Civil), and the source data license. This provides a clear operational understanding 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 long but well-structured with sections for different targets and warnings. It is front-loaded with the core purpose and uses bold for emphasis on critical points. Every sentence adds value given the tool's complexity, though it is not minimal.

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 (11 parameters, no output schema), the description covers input semantics, constraints, and data sources. However, it does not describe the output structure (e.g., fields in the response, whether it returns density value, population, raw counts). This is a gap as the agent cannot infer the return format from the lack of 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?

With 82% schema description coverage, the baseline is 3, but the description substantially enriches parameter semantics. It explains conditional logic (code_dept alone vs with nom_commune), unsupported codes for Paris/Marseille/Lyon, aliases for parameter names, and cross-field dependencies (e.g., famille required when cible=etablissements). The description compensates for the remaining 18% undocumented parameters by providing context that the schema lacks.

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 computes health density per 100,000 inhabitants by cross-referencing counts (RPPS or FINESS) with INSEE population data. It distinguishes itself from sibling tools by focusing on aggregation at department or commune level, which is a unique capability among the sibling tools (e.g., professionnels_in_radius returns individual professionals).

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

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

The description provides extensive internal usage guidance (required parameters, conditional semantics, warnings about Paris/Marseille/Lyon and code mismatches) but does not explicitly compare this tool to sibling alternatives. While it implies the tool is for density calculations, it lacks explicit 'when to use this instead of other tools' advice.

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 readOnly, idempotent, non-destructive. The description adds significant behavioral context: the tool never fails for missing commune data, it combines multiple sources, and it mentions coarse permit data in dense areas. This goes beyond annotation information.

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 reasonably concise for its complexity, front-loaded with the main purpose. It could be slightly more structured, but it effectively communicates the tool's functionality without unnecessary verbosity.

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 (multiple sources, edge cases, two output registers) and the presence of an output schema, the description is very complete. It covers the overall approach, edge cases, and output contents, leaving no major 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 100% with clear descriptions for all three parameters. The description adds minimal extra detail (e.g., radius used for 'calcul par rayon'), meeting 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 clearly states the tool's purpose: assessing real estate dynamics and growth potential of a zone. It specifies the three official sources combined and the two output registers ('note' and 'info'), distinguishing it from siblings which likely focus on single sources.

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 situational guidance, such as relying on AU zones and land sales in dense cities due to coarse building permit data. It also explains behavior when the commune is not found. However, it lacks explicit 'when not to use' instructions or comparisons to 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 declare readOnlyHint, idempotentHint, destructiveHint=false, so safety is clear. The description adds behavioral details: it calls inspect_site (costly, cap at 3), checks M&A signals via entreprise_by_siren, and produces a couverture flag per competitor. However, it does not describe return format or pagination, so slightly less than perfect.

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 lists and bold terms. It is informative but not overly verbose; every sentence adds value. A minor improvement could be trimming redundancy (e.g., 'Cap dur') but overall efficient.

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

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

Given the tool's complexity (combines multiple internal tools) and no output schema, the description fairly complete. It covers what checks are performed, the cap, error handling, typical inputs, and data sources. Missing explicit output structure, but the couverture flag is mentioned.

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. The description adds context: 'max' default is 3, and 'finess' are typically the top 3 from another tool. It also explains the token cost cap ties to 'max'. This adds meaningful guidance beyond the schema.

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

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

The description clearly states the tool performs an in-depth investigation of top competitors, specifying what it checks (status, team size, history, M&A, parent group). It distinguishes itself from siblings like inspect_site and entreprise_by_siren by being a composite tool that calls them internally. The verb 'enquête' and the enumeration of checks provide a precise 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?

Explicitly states when to use: 'Typiquement appelé sur concurrents.top[0..2].finess renvoyés par panorama_implantation_complet.' Also provides constraints: hard cap max=3, token cost warning, and error handling (one failing competitor doesn't cancel others). This is excellent 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 provide readOnlyHint, openWorldHint, etc. The description adds significant behavioral context: return type (LookupResult discriminated), possible etablissements truncation, meaning of enrichmentStatus values, and that 1-2 API calls are made. 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 well-structured with sections for purpose, output format, and warnings. It is somewhat long but every sentence adds value. Could be slightly more concise, but front-loads key info.

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 output schema exists, the description fully explains the discriminated union (found: true/false), all relevant fields (nombreEtablissements, enrichmentStatus, etc.), and edge cases (not_found, ambiguous, truncation). Comprehensive coverage.

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

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

Schema describes the single parameter 'siren' as 'SIREN exact, 9 chiffres.' with 100% coverage. The description repeats 'SIREN (9 chiffres)' but adds no extra meaning 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 clearly states the tool retrieves French company details by SIREN, listing key fields (raison sociale, NAF, finances, dirigeants, établissements) and the data source (DINUM). It distinguishes itself from siblings like 'etablissement_by_siret' (by SIRET) and 'entreprises_in_radius' (exhaustive enumeration).

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 advises when to use alternatives: 'Pour énumération exhaustive multi-département, utiliser `entreprises_in_radius`'. It also mentions the rate limit (~1 req/s) and recommends reading 'enrichmentStatus' for completeness.

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

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

Annotations (readOnlyHint=true, etc.) are already provided, and the description adds significant context: source (DINUM Recherche Entreprises), what is returned (CA, dirigeants, etc.), the behavior of the two modes, the constraint that proximity mode does not support administrative filters, and the effect of includeDirigeants. No contradictions.

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 into three paragraphs: general purpose, mode details, and parameter note. It is front-loaded with the main action. While it is fairly long, every sentence adds value and no information is redundant. Slightly more conciseness could be achieved, but it is acceptable.

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 complexity (10 parameters, two modes, output schema exists), the description covers all necessary aspects: mode exclusivity, parameter combinations, limits (radius 50 km), a specific performance optimization (includeDirigeants), and the data sources. An agent can correctly select and invoke this tool without ambiguity.

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 inline descriptions, so baseline is 3. The description adds value beyond the schema by explaining which parameters belong to which mode, that q and codePostal/departement are exclusive with lat/lon/radiusKm, and the practical use of includeDirigeants for payload reduction. This extra context raises the score.

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

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

The description clearly states it searches French companies with filters (NAF, postal code, department, geographic radius), specifies the two exclusive modes (proximity and administrative), and lists the data returned (CA, dirigeants, etc.). It distinguishes from siblings like entreprise_by_siren or etablissements_in_radius by focusing on companies and the dual-mode 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 details two exclusive modes: proximity (lat+lon+radiusKm, optionally naf) and administrative (q and/or naf+codePostal/departement). It states that mixing modes is rejected with an error, provides radius limit (50 km), and explains the payload reduction option (includeDirigeants). This gives clear when-to-use guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. Description adds: data freshness delay, truncation of raison_sociale (~38 chars), email always null. No contradictions; adds valuable 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?

Description is front-loaded with main purpose, but the single paragraph includes multiple notes that could be structured (e.g., bullet points). Still concise given the amount of information, with no wasted 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?

Output schema exists, annotations are present, description covers return format, data freshness caveat, truncation issue, email null, and cross-references. Complete for a lookup tool with 2 parameters.

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 clear parameter descriptions. Description adds minimal extra meaning: explains include_freshness as opt-in with negligible cost, but does not expand on num_finess. Baseline 3 is appropriate as 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?

Description clearly states it retrieves complete details of a healthcare establishment by FINESS number, listing fields (raison sociale, category, address, GPS, phone) and return type (LookupResult discriminated by found). Distinguishes from siblings like etablissements_finess_by_categorie.

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 DREES repository has 1-2 month delay, recommends cross-checking with ARS for emerging structures (CPTS, MSP) and via SIREN/SIRET for full legal name. Provides concrete when-to-use and limitations.

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

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

Annotations already declare readOnly=true, idempotent=true, non-destructive. Description adds significant behavioral context: the tool queries INSEE V3.11 API, returns a discriminated LookupResult (found true/false with specific fields), describes two not_found scenarios (API key missing, SIRET not found in SIRENE or diffusion partielle), explicitly states no GPS coordinates are returned, and explains rate limiting behavior. 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?

Description is detailed with well-structured sections (return format, error cases, sibling distinction, limitations, rate limit). However, it is somewhat verbose (multiple paragraphs); some sentences could be condensed. Front-loaded with purpose and key details, earning a 4.

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

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

Given the tool's simplicity (1 param, output schema present, rich annotations), the description covers all essential aspects: return type, error handling, source, limitations (no coords), rate limit, and comparison with sibling tool. No gaps for an AI agent to misunderstand usage.

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 has 100% coverage for the single parameter 'siret' (string, 14 digits). Description reinforces that SIRET must be exact 14 digits and adds context about format expectations. While schema already documents the parameter, the description provides meaningful usage context (exactness) justifying a score above baseline 3.

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

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

The description clearly states it retrieves details of an establishment by SIRET (14 digits) via the INSEE SIRENE API, listing specific fields returned (e.g., raison sociale, NAF, address, status). It explicitly differentiates from sibling 'entreprise_by_siren' by noting that this tool returns a single establishment site while the sibling returns the legal unit plus its establishments.

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 when-to-use: retrieving details of a specific establishment by SIRET. Contrasts with 'entreprise_by_siren' for legal unit vs. establishment. Advises on detecting closed SIRET still active on FINESS by checking 'actif' and 'dateFermeture'. Notes rate limit (30 req/min) with server-side retry handling. Offers alternative tools for geocoding ('geocode_adresse', 'entreprises_in_radius').

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 destructiveHint. The description adds valuable behavioral context beyond annotations: email always null, raison_sociale truncated, and that imagerie family often returns 0. 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 well-structured, starting with purpose, then constraints, then caveats. While slightly long, every sentence adds value. It efficiently communicates complex parameter relationships without redundancy.

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

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

Given the complexity (6 parameters, 24 enums, output schema exists), the description covers all important caveats: limitations of FINESS data (email null, truncated names), counting behavior (principal category only), and special cases (imagerie family). Output schema exists, so return value explanation is not needed.

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

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

Schema description coverage is 100%, so baseline is 3. However, the description adds meaningful semantics beyond the schema: explains XOR strict logic, combination rules, abbreviation handling for nom_commune, and the effect of include_freshness. This elevates the score to 4.

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

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

The description clearly states that the tool lists FINESS establishments by family, with optional department or commune filtering. It distinguishes itself from radius-based tools by explicitly stating 'Pas de rayon — pour énumération exhaustive d'une zone administrative,' which helps the agent select the correct tool among siblings.

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

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

The description provides explicit guidance on when to use the tool (enumeration of administrative zone), including parameter constraints like XOR strict between departement, code_insee, and nom_commune. It also notes that no parameter means entire France, and gives an alternative for cross-checking via other 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 signal read-only, idempotent, non-destructive. Description adds crucial caveats: email always null, raison_sociale abbreviation, family filtering limitation (périmètre), imagerie returning 0, and cache behavior. No contradictions.

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

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

Description is comprehensive but somewhat long and not front-loaded. Every sentence adds value, but could be more concise with bullet points or shorter sentences for easier scanning.

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?

Output schema exists (not shown) so return value explanation not needed. Description covers all key aspects: purpose, parameters, data source, limitations (email, abbreviation), filter behavior, and performance (cache). Addresses edge cases like imagerie and famille filtering.

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 3. Description adds significant context beyond schema: explanation of families filtering nuance, email null, raison_sociale truncation, include_freshness purpose, and radius limits.

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 clearly states it searches FINESS healthcare establishments within a radius using PostGIS. It lists 24 filterable families and data source. While it doesn't explicitly differentiate from sibling radius tools (e.g., entreprises_in_radius), the entity type (FINESS establishments) is distinct enough.

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

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

No explicit guidance on when to use this tool vs. alternatives like centres_sante_in_radius or professionnels_in_radius. The description focuses on behavior but omits selection criteria.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, matching the description's non-destructive nature. Description adds value by detailing data sources, matching logic, version-specific behavior, and caveats 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?

Description is detailed but not overly verbose. Every sentence provides useful information (purpose, methodology, version notes). Could be slightly more concise, but front-loading core purpose is effective.

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 6 params (100% schema coverage) and presence of output schema, the description covers purpose, metric, usage, methodology, caveats, and version behavior. It is contextually complete for a complex 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?

Schema coverage is 100% with clear descriptions. Description adds significant context, especially for familles (auto-derivation, relationship to NAF) and naf (examples). This goes beyond 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 clearly states the tool compares FINESS DREES and SIRENE DINUM coverage in a radius, providing a ratio. It specifies use cases (over/under-declaration) and distinguishes from siblings like etablissements_finess_in_radius by focusing on coverage ratio rather than listing.

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?

Explains when to use (detect discrepancies) and includes methodology, caveats, and parameter guidance (auto-derivation of familles). However, it does not explicitly mention when not to use or list alternative 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?

Les annotations indiquent déjà que l'outil est en lecture seule et idempotent. La description ajoute des informations comportementales importantes : source des données, précision, et signification des champs de sortie (score, confidence_low, type). Aucune contradiction avec les 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?

Deux phrases concises qui commencent par l'essentiel : l'action principale. Aucun mot superflu, chaque phrase apporte une information utile.

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?

Malgré l'absence de schéma de sortie, la description explique suffisamment le format des résultats (score, confidence_low, type) pour qu'un agent puisse les interpréter. Elle couvre également la source et la précision, ce qui est complet pour un outil de géocodage en lecture seule.

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 % : chaque paramètre a une description. La description de l'outil n'ajoute pas d'information supplémentaire sur les paramètres au-delà de ce qui figure déjà dans le schéma. Note de base de 3 justifiée.

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 géocode une adresse française en coordonnées GPS, précise la source (IGN Géoplateforme) et la précision (numéro de rue). Cela le distingue de son outil frère 'reverse_geocode' qui fait l'inverse.

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 explique comment interpréter les résultats : fiabilité selon le score, champ confidence_low pour les correspondances douteuses, et granularité via le type. Cependant, elle ne donne pas de contexte explicite sur quand utiliser cet outil plutôt que des alternatives comme 'reverse_geocode'.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds value by detailing the discriminated return type and the not_found behavior with a suggestion for alternative tool, but 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 very concise with four lines, front-loaded with the core purpose, and each sentence adds necessary information without redundancy.

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

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

Given the low complexity, high annotation coverage, and presence of output schema, the description fully covers the return behavior and fallback, leaving no 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 100% with examples. The description adds alias information (code_insee/codeInsee/insee) that is not in the schema, enhancing understanding beyond the schema definition.

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' and the resource 'commune par son code INSEE'. It distinguishes from sibling 'autocomplete_commune' by mentioning it for disambiguation.

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 tells the agent what to do when the commune is not found (use autocomplete_commune), providing clear guidance on fallback behavior.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds detailed behavioral context: it reads multiple sources, mentions the cross-referencing approach, version details (V0.7.0), and cost breakdown (RPC, SELECT, parallel calls). 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 well-structured with sections for purpose, version details, usage examples, output format, and cost. While slightly long, it front-loads the key purpose and provides valuable context without unnecessary verbosity.

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

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

Given that an output schema exists and the input parameter is fully covered, the description provides complete context: explains the output structure (LookupResult with found flag, finess view, siret_timelines), addresses versioning, and mentions cost and lack of caching. The tool's complexity is well-handled.

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?

With 100% schema coverage, the description adds no additional parameter semantics beyond what the schema provides (exact 9-digit FINESS number). The parameter description in the schema is sufficient, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool reconstructs the complete timeline of a healthcare establishment by cross-referencing multiple data sources (FINESS, RPPS, DINUM, INSEE). It distinguishes from sibling tools like 'etablissement_by_finess' by focusing on historical reconstruction rather than just current data.

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 three typical use cases (tracing history after merger/acquisition, identifying exact closure dates, understanding rebranding cascades), which helps identify when to use the tool. However, it does not explicitly contrast with alternatives or state when not to use it.

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

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

Annotations already declare readOnlyHint, destructiveHint=false, and idempotentHint. The description adds valuable context: it's an aggregator with parallel sub-calls, returns LookupResult with sections, handles truncation for professionals (not count), and describes edge cases (missing FINESS, unavailable historique). 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 relatively long but well-structured with sections and bullet points. It includes examples and explicit guidance. While not extremely concise, 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 the tool's complexity (aggregator with multiple sub-calls, optional parameters, edge cases) and the presence of an output schema, the description fully covers return format, failure modes, performance considerations, and aliases. It leaves no critical 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 100%, so baseline is 3. The description adds significant value: explains that rpps_limit is a sample (not total count) with truncated flag, that historique_detail reduces payload by ~7K tokens, and mentions aliases for num_finess. This enhances understanding 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 explicitly states it provides a '360 view of a health establishment in 1 call' and aggregates four types of data (identification, administrative status, professionals, history). It distinguishes from siblings by noting it replaces three individual tools (verifier_site_actif, rpps_dans_etablissement, historique_etablissement) with a single call.

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 (prospection, audit territorial, CRM enrichment) and when not (for specific needs like just verdict or history, prefer individual tools). It also provides guidance on payload weight and suggests setting historique_detail=false for batch usage.

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

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

Adds significant behavioral details beyond annotations: pagination with limit/total/truncated, perimeter restrictions (libéraux conventionnés only), consequence of wrong codes (empty without error), data freshness option, and caching. 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 comprehensive but somewhat lengthy; however, every sentence is informative and the structure (see, warning, referential details, pagination, perimeter) is logical. Could be slightly more concise without losing 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?

Complete for a complex tool: covers purpose, usage, all parameters behavior, pagination, perimeter restrictions, exclusions, data source, and legal note. Output schema exists, so return values are not needed.

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

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

With 100% schema coverage, the description still adds substantial meaning: explains each referential with examples (e.g., '10' = Médecin side ANS vs Neurochirurgien side Ameli), defaults, and the effect of include_specialites=false on token count.

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

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

The description clearly states the tool's purpose: 'Découverte des nomenclatures de codes du serveur' (discovery of server code nomenclatures), distinguishing it as the unique tool per referential and noting it should be called before filtering other 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?

Explicit guidance: 'à appeler avant de filtrer un autre tool plutôt que deviner les codes'. Warns against mixing codes across referentials and specifies which referential to use for which sibling tools (e.g., ameli_specialites for professionnels_in_radius).

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 readOnly, openWorld, idempotent, non-destructive. Description adds parallel aggregation, degradation flags ('ok', 'partiel', 'indisponible'), internalized pitfalls (PLM mode for big cities, precise count for prescripteurs), and source references. 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 dense and well-structured with section list and workflow steps. Minor redundancy (e.g., 'Renvoie des RÉSUMÉS...' restates, but key info). Front-loaded with purpose.

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

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

Despite no output schema, the description fully covers return values (summaries, degradation flags), edge cases (partial failure, anchorage failure), and internal logic (parallel execution, pitfalls). Sufficient 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?

All 4 parameters have descriptions in schema (100% coverage). Description adds critical context: XOR relationship between point and adresse, code_insee with point, default rayon_km=5, and behavior when point is used (skip geocoding).

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's an 'étude d'implantation labo' that aggregates 7 sections in parallel, replacing 15 individual MCP calls. It lists each section and explicitly distinguishes from sibling tools by being the orchestration entry point.

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 workflow: call this tool to start, then handle partial/indisponible sections with unitary tools, then enrich top 3 concurrents. Also specifies when total failure occurs (anchorage failure) and that it returns summaries, not raw lists, and no business interpretation.

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?

Description adds significant behavioral context: returns no business interpretation (no 'désert médical'), granularity mix (commune vs department), PLM cities unsupported, 'demande' block null for DOM communes, and sources/update frequency. Annotations already indicate readonly, idempotent, non-destructive, but description enriches with these 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?

Description is long but well-structured: summary first, then version updates, granularity mix, PLM warning, aliases, sources. Could be slightly more concise (version numbers may be unnecessary for agent), but front-loaded purpose.

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

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

Given complexity (multiple data sources, mixed granularity, special cases) and no output schema, description covers result blocks (population, densities, FINESS, demande) and null cases, error conditions (PLM, departement alone), and version behavior. It is complete enough for agent to use 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%, but description adds meaning: 'code_insee' notes PLM unsupported, 'departement' is hint only, 'nom_commune' combinable with departement, no abbreviations, 'finess_familles' explains default and effect of empty array. These details go beyond schema.

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

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

The description clearly states the tool aggregates multiple data sources into one call for a French commune, replacing 7-10 individual MCP calls. It distinguishes from siblings like 'profil_iris' and 'densite_sante' by providing a holistic overview.

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 (single commune, replaces many calls) and when not to (Paris/Lyon/Marseille not supported, use individual tools at department level). Also explains parameter usage: 'departement' as hint only, error if used alone; granularity mix warns against confusing commune and department ratios.

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 goes well beyond annotations by explaining auto-detection of granularity, return type (LookupResult), data sources (INSEE RP 2022, Melodi), and specific behaviors for communes fusionnées, IRIS types, and missing departments. 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 detailed and well-structured with bullet points, but slightly verbose. However, it front-loads the core purpose and uses formatting for readability.

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 complexity of multiple granularities and edge cases, the description is comprehensive. It covers all scenarios (commune, department, IRIS, special cases like PLM, Mayotte) and references the 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% for the single parameter 'code', but the description greatly enriches it by explaining length-based auto-detection, providing examples, and detailing the IRIS code structure (e.g., '751103701'). Adds substantial meaning beyond the schema.

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

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

The description clearly states the tool's purpose: population lookup for communes, departments, or IRIS by INSEE code. It explicitly names the French administrative levels and distinguishes from sibling tools like 'profil_iris'.

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 when-to-use guidance for population counts at various granularities and when-not-to-use (detailed demographic profiles -> 'profil_iris'). Also warns about edge cases like PLM arrondissements and Mayotte absence.

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

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

The description adds significant behavioral context beyond annotations: fallback to ANS FHIR API, geo_precision semantics, source field differentiation, cache behavior, and data freshness details. No contradiction with readOnlyHint (true) or other 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 three paragraphs and somewhat verbose, but each sentence provides necessary information. It is front-loaded with the main purpose, though some technical details (e.g., geo_precision values) could be more succinct.

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 output schema exists, the description effectively covers key behavioral details: multi-site results, fallback, source distinction, freshness options. It is complete for an ID-based retrieval tool with moderate complexity.

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

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

The input schema covers 2 parameters with 50% description coverage. The description adds meaning by detailing the rpps_id format (11-12 digits, prefix pattern) and explaining that include_freshness only affects 'db' source. This compensates for the missing schema description on rpps_id.

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

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

The description clearly states the tool retrieves a professional's full record by national identifier, specifies the identifier format (11-12 digits, '81' prefix), and notes it returns multiple entries for multi-site practices. This distinguishes it from sibling tools like rpps_search_by_name.

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

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

The description implies usage when a specific rpps_id is known, but does not explicitly state when not to use it or mention alternative tools for search or radius queries. The context is clear enough for an agent to infer appropriate use.

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 annotations (read-only, idempotent, non-destructive), the description elaborates on geo-precision (77% address vs 23% centroid), distance calculation (haversine), deduplication logic, and data freshness. It fully discloses limitations like identical centroid distances within a commune.

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 lengthy but well-structured with sections (PERIMETRE, HORS PERIMETRE). Every sentence adds value for a complex tool with 9 parameters. It is front-loaded with the main purpose. Slightly verbose but 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?

Given the tool's complexity, 9 parameters, and a rich output schema, the description covers all needed aspects: tool purpose, parameter usage, output structure (sites[], geo_precision, distance_km), legal constraints, and source freshness. It leaves no significant 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 100%, but the description adds substantial meaning: explains the `precise_only` semantics, the distinction between `type_ps_codes` and `specialite_codes`, deduplication behavior, and the `include_freshness` parameter. It provides context beyond the schema descriptions.

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

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

The description clearly states it searches for liberal health professionals (conventionnés) within a geographic radius. It specifies the source (Annuaire santé Ameli) and distinguishes from sibling tools that cover other provider types (e.g., RPPS, centres de santé) by explicitly stating the perimeter and exclusions.

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 when-to-use guidance (e.g., use `specialite_codes` for specific professions, `precise_only` for short radii) and when-not-to-use (for all-status counts, see Annuaire Santé ANS). It also explains multi-site behavior and deduplication, helping agents choose the right parameters.

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

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

Annotations already declare readOnly, idempotent, and not destructive. Description adds scope details (libéraux conventionnés, exclusives), update frequency (MAJ hebdomadaire), and legal reuse requirements. No contradictions.

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

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

Description is fairly long but well-structured with clear sections (filtering, pagination, scope, source). Every sentence adds value, though could be slightly more concise.

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

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

Given 7 parameters, comprehensive annotations, and an output schema, the description is complete. It covers scope, pagination, deduplication, freshness, legal citation, and out-of-scope 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?

All 7 parameters are described in the schema (100% coverage). Description adds extra context: explains type_ps codes, recommends specialite_code over type_ps_code, and references lister_nomenclature for full lists.

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 'professionnels de santé libéraux conventionnés d'un département' with optional filters. It distinguishes from spatial siblings like 'professionnels_in_radius' and RPPS-based 'professionnels_rpps_par_dept'.

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 when-to-use (administrative enumeration), when-not (pas de rayon), and alternatives (e.g., Annuaire Santé for all statuses). Includes pagination, deduplication, and filter hierarchy 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 indicate read-only, open-world, idempotent, non-destructive. Description adds context on geo_precision levels, hybrid vs precise mode, coverage percentages, and freshness opt-in. There is no contradiction with annotations. Description adds value beyond annotations.

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

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

Description is long but well-structured with bold text, bullet points, and clear sections. It is front-loaded with main purpose. Though verbose, every sentence is informative and necessary given tool complexity. Could be slightly more concise but overall justified.

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 10 parameters, nested objects, and presence of output schema, the description is highly complete: covers data source, precision types, code references, filter options, usage warnings, and even includes URL for nomenclature. No gaps identified.

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?

With 80% schema coverage, description provides extensive additional semantics: explains precise_only behavior and recommended thresholds, lists mode_exercice_codes values, details include_agents_publics and include_etudiants categories with percentages and reference, warns about code namespace confusion. Adds meaning far beyond 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?

Description states tool finds health professionals (PS) via RPPS, covering all statuses (liberal, salaried, mixed, replacements). It explicitly differentiates from sibling 'professionnels_in_radius' which covers only liberal conventionnés. Verb 'trouve' and resource 'PS dans un rayon via RPPS' are specific.

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

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

Description gives extensive guidance: when to use precise_only (short radii), warns against mixing ANS and Ameli codes, explains data precision types and their appropriate use (e.g., centroide_commune not for individual ranking). It names the alternative Ameli tool and provides filter recommendations.

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?

Description adds rich behavioral context beyond annotations: pagination via offset/truncated, geo_precision field interpretation, optional filters with default category (Civil), opt-in for agents publics/étudiants, code nomenclature distinction, and data freshness option. Annotations already declare readOnlyHint, etc., and description is consistent.

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?

Front-loaded with purpose and alternative. Every sentence adds necessary information: pagination, geo precision, filters, code warning, source. No fluff, well-structured for its 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?

Given complexity (9 params, pagination, geo precision, code distinctions), description covers all important aspects: pagination, geo precision, filter options, code warnings, source. Output schema exists, so return values not needed. Includes reference URL for categories.

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?

Despite high schema coverage (78%), description adds significant meaning: explains the default category and percentages, warns about ANS vs Ameli codes, and clarifies the effect of include_agents_publics and include_etudiants. Also advises using lister_nomenclature for code discovery.

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 states clearly: 'Liste tous les PS d'un département via RPPS (libéraux + salariés).' It explicitly distinguishes from sibling 'professionnels_par_specialite_dept' for liberal only. Verb and resource are specific.

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

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

Explicitly advises when not to use: 'Pour les libéraux conventionnés uniquement, préférer professionnels_par_specialite_dept (Ameli).' Also provides pagination instructions, code usage warnings, and suggests 'lister_nomenclature' for discovering ANS codes.

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 safe, idempotent read. Description adds that output is a LookupResult discriminated by 'found', details proxy calculation for revenu_median_pondere, data sources (INSEE RP 2022, FILOSOFI 2021), and coverage limitations (communes ≥5000 hab). No 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?

Well-structured with clear separation of modes via bullet points. Slightly long but every sentence adds essential information. Front-loaded with purpose.

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

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

Covers all aspects: dual modes, input constraints, output structure (LookupResult), data provenance, coverage caveats, and proxy calculations. No missing context despite complexity.

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 concise descriptions. Description adds behavioral context: lat+lon vs code_iris exclusivity, rayon_km modes, and the meaning of computed fields (e.g., revenu_median_pondere as proxy). Exceeds baseline of 3.

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

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

The description clearly states it provides demographic profiles at the IRIS (neighborhood) level for location assistance, distinguishing between single-IRIS and basin modes. It contrasts with siblings like 'population' (simple commune/department counts).

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 explains two modes (with/without rayon_km), specifies input constraints (exactly one of point or code_iris), and advises using 'population' for simpler population needs. Covers invalid cases (not_found).

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 extensively details behavioral traits: algorithm (Sørensen-Dice on bigrams), score computation, verdict thresholds, and output format including the `skipped` field. Annotations already indicate read-only, open-world, idempotent, non-destructive; the description adds value with the internal logic and edge cases.

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

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

The description is well-structured with clear sections and bullet points, making it easy to read. It is slightly lengthy (four paragraphs) but each part serves a purpose. Some algorithmic details could be condensed, but overall it is efficient.

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

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

Given the tool's complexity and the presence of an output schema, the description provides a complete picture: input, algorithm, output format (including handling of null cases like 'not_found' vs empty candidates). 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?

The single parameter 'num_finess' is fully described in the schema (9-digit string). The description adds context about how it is used to fetch FINESS data, but does not provide additional semantic constraints beyond the schema. With 100% schema coverage, a score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: cross-referencing FINESS and SIRENE data and computing a coherence score for FINESS-SIRET matching. It uses specific verbs ('Croise', 'calcule') and identifies the resource (FINESS, SIRENE). The tool is distinct from siblings, none of which perform this reconciliation.

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 the tool is useful 'pour confirmer/infirmer un appariement num_finess ↔ SIRET avant prospection ou cross-check qualité', providing clear context. It does not, however, mention when not to use it or suggest alternative tools, but the specificity is sufficient.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint true, and destructiveHint false. Description adds valuable behavioral context: coverage limitation, null return meaning 'no result not error', and data source attribution. No contradictions.

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

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

Description is two sentences, concise, and front-loaded with the primary purpose. Every sentence adds value (purpose, source, coverage, special return behavior). 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, description mentions that out-of-zone coordinates return null, which partially addresses return behavior. However, it does not specify the format of the returned address. Still, for a simple tool with good annotations, it is nearly complete.

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

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

Input schema has 100% description coverage for both parameters (lat and lon with WGS84). Description does not add additional semantics beyond what the schema provides. Baseline 3 is appropriate since schema already explains parameters.

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 clearly states 'reverse geocoding' and retrieves nearest address from GPS coordinates. Specifies data source (IGN Géoplateforme) and coverage, distinguishing it from sibling tool geocode_adresse which does forward geocoding.

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 clear context on coverage (France métropolitaine + DOM) and behavior for out-of-zone coordinates (returns null). Does not explicitly state when to use versus alternatives, but the tool's purpose is self-evident and no other sibling does reverse geocoding.

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

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

The description adds significant behavioral context beyond annotations: it explains that coords and distance_km are null, the output is compact, the default category, opt-in behavior for agents publics and étudiants, and includes data source and license. No contradictions with annotations (readOnlyHint, idempotentHint, etc.).

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 purpose and well-structured into sections (purpose, output, categories, opt-ins, references). It is longer than necessary but every sentence provides value. Could be slightly more concise, but overall efficient for the 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?

Given the parameter count (5), output schema existence, and many siblings, the description is extremely complete. It covers purpose, usage, parameter semantics, behavioral notes, data source, and references. It also complements the output schema by explaining what is null and why.

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

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

The description adds meaning to parameters like include_agents_publics and include_etudiants with category percentages and examples, and explains num_finess format. However, the 'limit' parameter is not explicitly described in the description, though the schema provides basic type. Given low schema coverage (20%), the description compensates well but misses limit.

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 'Liste les PS rattachés à un établissement FINESS' with a specific verb and resource. It explains the tool's role as a pivot between RPPS and FINESS and explicitly differentiates from spatial tools by noting that coords are null, and suggests using 'etablissement_by_finess' for geolocation.

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

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

The description explicitly states when to use: to answer 'qui travaille dans ce labo / hôpital / clinique ?'. It provides explicit guidance on when not to use (for spatial queries) and names an alternative. It also explains opt-in parameters and default category, and discusses data coverage and limitations.

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 readOnlyHint, idempotentHint, etc. Description adds important behavioral details: sorting by match_score, truncation flag, geo_precision field with precision values, category filtering (default Civil with opt-ins for agents publics and étudiants). 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 comprehensive but well-structured, with clear sections for usage, sorting, truncation, geo_precision, categories, and source. Each sentence adds value; no redundancy. However, it is relatively long, earning a 4 rather than a 5.

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

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

Given the tool's complexity (7 parameters, output schema exists, annotations present), the description covers all essential aspects: purpose, usage, behavioral details (sorting, truncation, geo_precision), parameter semantics, categories, and data source. It is sufficient for correct selection and 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 71%, and description adds context beyond schema descriptions: explains nom is required, departement code format (including Corse and DOM/COM), purpose of include_freshness (adds freshness metadata), and category opt-ins. The example clarifies how nom and departement are used together.

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 finds a healthcare professional by identity using trigram matching tolerant to accents/typos. It provides a concrete example ('Dr Martin à Paris') and distinguishes itself from sibling tools that search by radius or specialty.

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 guidance on when to use: with example input, clarifies required field (nom) and optional refiners (prenom, departement). Warns about homonyms without departement and suggests filtering. Does not explicitly state when not to use, but context is clear.

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

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

Annotations declare readOnlyHint, idempotentHint, destructiveHint false. Description adds cost details (RPC, SELECT, DINUM calls) and explains version-specific fixes and edge cases. No 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?

The description is well-organized with paragraphs and bullet points, but quite verbose with technical details like version numbers and distances. Could be more concise without losing key information.

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

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

Given the complexity (multi-source, two verdicts, output schema), the description covers all important aspects: logic, edge cases (succession, collocation), cost, and output format. Very 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?

Only one parameter 'num_finess' with schema description 'Numéro FINESS exact (9 chiffres).' Description does not add further semantics. Since schema coverage is 100%, baseline is 3.

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

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

The description explicitly states it 'Vérifie si un établissement de santé FINESS est encore en activité' and details cross-referencing multiple sources. This distinguishes it from sibling tools like 'etablissement_by_finess' which likely returns general info.

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

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

The description provides extensive logic (lookup steps, two verdicts, handling of successions) but does not explicitly state when to use this tool vs alternatives. The detailed algorithm helps the agent infer correct usage.

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