france-data-mcp

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

Annotations (readOnlyHint, idempotentHint) already indicate safety. The description adds behavioral context: the data source (geo.api.gouv.fr) and alias parameters for flexibility. 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 concise with two short paragraphs, no redundant information. It front-loads the tool's purpose and adds alias details efficiently.

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

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

For a search tool with no output schema, the description covers input well but does not describe the return format (e.g., fields, structure). Given the tool's simplicity, this is a minor gap.

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 alias mappings ('q'→'nom', etc.) and clarifies the 'au moins un' constraint, providing 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 verb 'Recherche' (search) and resource 'communes françaises' with specific search criteria (nom, code postal, code INSEE). It also positions the tool for autocompletion, distinguishing it from siblings like 'get_commune_by_code' which is for exact 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 explicitly requires at least one search parameter ('Un (au moins) parmi... est requis'), which guides proper usage. It also suggests the tool is ideal for autocompletion, but does not mention when not to use it or explicitly compare 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?

The description adds significant behavioral context beyond annotations: the discriminated `LookupResult` response, explicit failure modes, cache behavior (5min server-side), data freshness opt-in, and legal source attribution. Annotations already indicate read-only and idempotent, but the description enriches this.

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

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

The description is well-structured and contains all essential information, but is slightly verbose with repeated explanations of the `found` states. Minor trimming could improve conciseness without losing clarity.

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

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

Given the output schema exists, the description adequately covers the behavior: payload overview for found cases, failure messages, source and sync details, cache, alias, and data freshness options. No gaps for a fetch-by-ID 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?

100% schema parameter coverage is already present, but the description adds value by specifying the exact 9-digit format for `num_finess`, listing accepted aliases, and explaining the opt-in nature and behavior of `include_freshness`.

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 details of a health center (CDS) by FINESS number. It distinguishes itself from the sibling `etablissement_by_finess` by highlighting the specific CDS-related fields it exposes (carte_vitale, APCV, specialites).

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

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

Explicit guidance is provided on when to use this tool vs. `etablissement_by_finess` for non-CDS structures. It also explains the `found: false` scenario for non-CDS or very recent CDS, and mentions the data source and sync frequency.

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?

Discloses behavioral traits beyond annotations: coordinates are centroid-based (~3km average), source syncs weekly from CNAM, specialite_codes uses 'any-of' matching, accepte_carte_vitale is quasi-total so mainly useful for false, type_etab_codes include deprecated codes, and include_freshness adds caching details. No contradiction with annotations (readOnlyHint=true), and description adds significant behavioral context.

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

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

The description is relatively long (~200 words) but well-structured with paragraphs and bullet points. It front-loads the main purpose and then details filters, coords, and limitations. While slightly verbose, the complexity (8 params, sibling differentiation, legal mentions) justifies the length. Minor reduction possible, 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?

Covers source, sync frequency, legal mention, filters, edge cases (deprecated type, aliases), and approximation of coordinates. Does not explicitly describe output structure, but an output schema exists (not shown) to handle that. Given the richness of information and presence of output schema, 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?

Although schema coverage is 100%, the description adds substantial extra meaning: explains Annexe A for specialite_codes with examples, notes quasi-total CV acceptance for accepte_carte_vitale, clarifies type_etab_codes as standard/deprecated, details include_freshness opt-in and caching, and lists aliases for radius/lat/lon. This enriches parameter 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 clearly states the tool searches for 'Centres de Santé' within a geographic radius using PostGIS ST_DWithin, specifies the source (Annuaire santé Ameli), and explicitly distinguishes from sibling tool 'etablissements_finess_in_radius' by highlighting exposed fields like carte_vitale, APCV, and specialties. It defines CDS and gives legal context, making the purpose highly 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?

Provides explicit when-to-use and when-not-to-use guidance: differentiates from 'etablissements_finess_in_radius' by noting additional fields, advises pivoting via 'etablissement_by_finess' for address precision, and states that hours/tariffs/secteur are unavailable (removed post-2025). Also explains filter semantics and alias acceptance, giving clear context for correct 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?

The description discloses the tool's nature as a 'primitive brute' without business interpretation, details the statut field and its values, and notes that score_dice can be null. Annotations already indicate safe read-only behavior, and the description adds context about output format 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 bullet points for statut values and clear separation of sections. While slightly long, every sentence adds necessary context. It is front-loaded with the core 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 the presence of an output schema, the description still provides rich behavioral context, including output format, status meanings, data freshness caveats, and fallback behavior for missing data. It is comprehensive for a comparison tool.

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

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

The input schema has 100% coverage with a clear description for num_finess. The tool description does not add further parameter-level details beyond what the schema already provides, so it meets the baseline but does not exceed it.

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 addresses of a health center from two sources (CNAM vs FINESS DREES) for a given num_finess. It explicitly names the sibling tool compare_raison_sociale_finess_vs_rpps as an equivalent for a different field, distinguishing it from 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?

The description explains when to use the tool (to detect unsynchronized moves between sources) and when not to use it (for non-CDS organizations, pointing to etablissement_by_finess). It also provides background on data synchronization delay.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds substantial value by detailing the return format (discriminated union with 'found' and conditional 'statut'), explaining status values ('exact_match', 'divergent_after_normalization', 'rpps_absent'), and stating the behavior when num_finess is absent from FINESS DREES. This exceeds what annotations provide.

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

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

The description is well-structured with a clear purpose, usage hint, and bulletized status explanations. It front-loads the main purpose and adds necessary detail without fluff. Slightly verbose but every sentence contributes 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 (comparing two data sources, multiple status conditions, discriminated output), the description covers all essential aspects: what it does, when it's useful, what it returns in each case, and what it avoids. The presence of an output schema (not shown) further complements completeness.

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% (parameter 'num_finess' described as 9-digit exact number). The description does not add new semantic information about the parameter beyond what the schema already provides. 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' from FINESS DREES and RPPS for a given FINESS number. It distinguishes itself from sibling tools like 'etablissement_by_finess' and 'professionnel_by_rpps' by focusing on cross-reference comparison. The verb 'compare' and the specific data sources are explicit.

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

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

The description provides context for usage: it explains that RPPS reflects rebrandings faster than FINESS DREES, and explicitly states that the tool does not interpret the divergence (leaves decision to caller). It also clarifies what the tool does NOT do (e.g., not saying who bought whom). However, it does not mention alternative tools or 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?

Les annotations déclarent readOnlyHint, idempotentHint, destructif=false. La description ajoute des comportements concrets : elle produit médiane, quartiles, volume, période. Elle précise aussi que les prix sont résidentiels et peut servir de proxy. Pas de 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?

La description est un paragraphe unique en français, relativement concis mais contenant plusieurs informations utiles. Elle aurait pu être structurée en points pour plus de clarté, mais reste efficace sans être trop longue.

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?

L'outil a un schéma de sortie, la description n'a donc pas besoin de détailler la structure de retour. Elle explique ce qui est fourni (médiane, quartiles, volume, période, source). Compte tenu de la complexité des métriques, la description est complète.

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

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

Le schéma de paramètres a une couverture de description de 100% (lat, lon, rayon_km avec valeurs par défaut et limites). La description n'ajoute pas d'informations supplémentaires sur le format ou l'utilisation des paramètres. Le score de base 3 est approprié.

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

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

La description spécifie clairement que l'outil calcule le prix médian au m² résidentiel bâti (maisons+appartements) pour une zone donnée, distinguant explicitement des locaux commerciaux. Le verbe d'action est implicite mais le but est très précis. Il se différencie des outils frères qui sont centrés sur la santé, les communes, etc.

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 donne des instructions explicites : utiliser comme proxy pour les locaux professionnels, ne pas intégrer dans une note d'attractivité car le coût d'installation est distinct. Elle mentionne la source (DGFiP DVF) et le contexte d'utilisation (business case).

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 indicate readOnlyHint=true and destructiveHint=false. The description adds context: cache server (5 minutes), cost (1 SELECT), and implicitly confirms read-only nature. 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 and front-loaded, but slightly verbose with enumerated sources. However, every sentence adds value, so minor deduction.

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, the description need not detail return values, but it does anyway. It provides typical use, alert thresholds, caching, and cost—completely covering the tool's context.

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

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

There are zero parameters; schema coverage is 100% (empty). The description fully compensates by explaining return fields and interpretation, adding value beyond the empty 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 returns freshness of ingested data dumps, listing each source (FINESS, Ameli, etc.) and the fields returned. It distinguishes itself from sibling tools since no other sibling focuses on data freshness.

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 usage: 'avant un audit territorial ou une analyse temporelle', with specific alert thresholds for each source (staleness_days >90 for FINESS, >14 for Ameli, etc.). Also clarifies which sources are excluded (LIVE sources).

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

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

Beyond the readOnlyHint, openWorldHint, idempotentHint, and destructiveHint annotations, the description adds critical behavioral context: it warns of RangeError for Paris/Marseille/Lyon, silent empty results with wrong codes, default category (Civil), opt-in for agents publics/etudiants, and that no interpretation (e.g., 'desert medical') is returned.

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 and detailed but well-structured with sections, bold key terms, and examples. It could be more concise without losing clarity, but the structure aids parsing.

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

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

Given the tool's complexity (11 parameters, no output schema), the description covers all aspects: methodology, parameter constraints, limitations, defaults, warnings, and references to complementary tools (lister_nomenclature). No gaps detected.

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 82% (high), but the description adds significant semantics beyond the schema: conditional semantics of code_dept, default for mode_exercice_codes, semantics of include_etudiants/include_agents_publics, and warnings about Paris/Marseille/Lyon. It does not fully compensate for the remaining 18% but adds clear value.

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 computes health density per 100,000 inhabitants for professionals or establishments at department or commune level, with explicit differentiation between the two cible targets and reference to siblings via methodology details.

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

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

The description provides explicit when-to-use guidance, including mandatory famille for etablissements, warnings against mixing code systems, a note that Paris/Marseille/Lyon commune-level is unsupported, and recommendation to use compare_national. It also implies distinctions from sibling tools that list counts rather than compute density.

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, destructiveHint), the description details edge-case behavior: coastal points return 'indisponible' for permits but still serve AU zones and land data, and the tool never fails. It also explains output registers (note, info, geojson) and their purposes.

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 that efficiently covers purpose, sources, output, and edge cases. It is front-loaded with the main action. While somewhat lengthy, every sentence adds value 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?

The description is complete for a complex tool: it covers three data sources, two output registers, geojson, and handling of missing data. With an output schema present, lack of return value details is acceptable.

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

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

Input schema has 100% coverage with descriptions for lat, lon, and rayon_km. The description does not add significant new meaning beyond the schema; it reinforces the context of point-and-radius analysis. 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's purpose: 'Dynamique immobilière et potentiel de croissance d'une zone (point + rayon)' and lists specific data sources and output registers. It distinctively positions the tool among siblings by detailing its unique combination of permits, PLU zones, and land sales.

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 context for when to rely on alternative data: 'En ville dense les permis-commune sont grossiers → s'appuyer sur zones AU + terrains'. It also addresses edge cases like coastal points. However, it does not explicitly name alternative tools or state when not to use this tool.

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

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

Annotations indicate read-only, idempotent, non-destructive. Description adds critical behavioral details: hard cap at 3, token cost warning, and that a failing competitor does not cancel others. No contradiction with annotations.

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

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

The description is structured in three paragraphs covering purpose, constraints, and usage. It is somewhat lengthy but every sentence provides valuable information 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 no output schema, the description thoroughly explains what each FINESS returns (status, team size, history, M&A signals, parent group, coverage flag) and lists data sources. It is complete for an agent to understand inputs, outputs, and behavior.

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

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

Schema coverage is 100%, but description adds meaning: finess array is typically top 3 competitors from a previous step, and max is a hard cap defaulting to 3. This contextualization aids correct invocation beyond raw schema.

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

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

The description clearly states it performs an in-depth investigation of top competitors, detailing specific data points (status, team size, history, M&A, parent group). It distinguishes itself from sibling tools by being a composite tool that uses multiple sources like inspect_site and entreprise_by_siren for enrichment.

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 typical use case: called on FINESS numbers from 'concurrents.top[0..2]' returned by 'panorama_implantation_complet'. Also provides constraints (max=3, expensive inspect_site calls) and behavior on failure, giving clear guidance on when and how to 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?

Annotations indicate readOnlyHint, idempotentHint, and no destruction. The description adds rich behavioral details: enrichment status meanings (success, partial, failed, not_attempted), potential truncation of etablissements, cost of 1-2 API calls, and rate limit of ~1 req/s. 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 and front-loaded with the core purpose. It includes necessary details (return format, enrichment logic, alternatives) but is slightly verbose; however, every sentence adds value, 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 complexity (discriminated union output, enrichment status, edge cases), the description covers all necessary context: return format, possible lookupStatus values, enrichment behavior, alternative tool, and API constraints. The output schema exists but the description adds the discriminated union details, making it complete.

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

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

Schema description coverage is 100% with a clear 'SIREN exact, 9 chiffres.' The description repeats the format but adds no new meaning beyond the schema, so 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 'Récupère le détail d'une entreprise française par son SIREN', specifying the verb and resource. It distinguishes from siblings by explicitly recommending 'entreprises_in_radius' for exhaustive multi-département 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 provides explicit when-to-use (valid SIREN for company details) and when-not-to-use (exhaustive multi-département, use alternative). It also explains edge cases like not_found due to INSEE diffusion and notes rate limits, giving clear context for decision making.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive nature. The description adds behavioral traits: two exclusive endpoints, rejection of invalid parameter combinations, bounded radius, payload reduction with includeDirigeants, and backward compatibility. It also mentions the data source (DINUM Recherche Entreprises) and provides NAF code examples. 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 two distinct paragraphs (overview and mode details). It front-loads the main purpose and then provides specifics. However, it is slightly verbose with examples of NAF codes and the payload reduction rationale, which could be shortened. It earns a 4 because it is organized but could be more terse.

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 10 parameters, no required parameters, and an output schema (not visible but mentioned), the description covers all necessary contexts: two modes, parameter restrictions, payload reduction, data source, and error handling. An AI agent has sufficient information to select and invoke the tool correctly. No gaps are evident.

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 beyond the schema. It explains the exclusive modes and parameter groupings (e.g., proximity mode uses lat, lon, radiusKm, and optionally naf; administrative mode uses q, naf, codePostal, departement). It clarifies that includeDirigeants strips dirigeants for token economy. These details are not in 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 it searches French companies with specific filters (NAF, postal code, department, or geographic radius). It distinguishes two exclusive modes and covers all sectors. The verb 'recherche' and resource 'entreprises' are explicit, and the tool is differentiated from siblings like 'centres_sante_in_radius' and 'etablissements_finess_in_radius'.

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 the two mutually exclusive modes (proximity and administrative) and which parameters are allowed in each. It states that combining certain parameters (e.g., q with lat/lon) is rejected with an error. It also bounds radiusKm to 50 km and explains the includeDirigeants option for payload reduction. However, it does not explicitly compare the tool to siblings like 'entreprises_by_siren' for other use cases, so it loses a point.

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. The description adds: LookupResult discriminated by found, email always null, truncated raison_sociale, and freshness lag. 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: purpose first, then return format, then notes. Each sentence adds value. Could be slightly tighter, but 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 the tool has only 2 parameters, full schema coverage, existing output schema, and annotations covering safety, the description fully explains all behavioral nuances (null email, truncated name, data lag) and cross-referencing needs. Nothing missing.

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

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

Schema coverage is 100%. The description adds context: num_finess must be 9 digits, include_freshness is opt-in with cache 5min. This adds meaning beyond 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 the tool retrieves full details of a healthcare establishment by FINESS number, listing specific fields (raison sociale, adresse, GPS, etc.). It implicitly distinguishes from sibling tools like etablissements_finess_by_categorie and etablissements_finess_in_radius by focusing on a single establishment 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 does not explicitly specify when to use this tool vs alternatives. It provides cross-checking advice (ARS, SIREN/SIRET) but lacks explicit when-to-use or when-not-to-use guidance relative to siblings.

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 goes beyond annotations (readOnlyHint, etc.) by detailing return format (LookupResult with found true/false cases), error messages (missing API key, not found, diffusion partielle), and behavioral constraints (no GPS coordinates, rate limit).

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 well-structured with clear sections, emoji warnings, and bullet-like formatting. Though lengthy, every sentence adds value; front-loaded with main 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 output schema exists, description explains both cases (found/not found). Covers edge cases (API key missing, diffusion partielle) and provides cross-tool comparison. Fully adequate for context.

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 'siret' is fully covered by schema (100% description), and the description adds value by restating '14 chiffres' and reinforcing that it's used for lookup. No additional parameter documentation needed.

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

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

The description specifies the verb 'Récupère' and resource 'établissement par son SIRET', lists data fields (raison sociale, NAF, dates, etc.), and distinguishes from sibling 'entreprise_by_siren' by clarifying it returns a single site vs legal unit with list.

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 this tool vs 'entreprise_by_siren' and 'geocode_adresse' for coordinates. Provides guidance on interpreting 'actif: false' for FINESS cases. Also notes rate limit (30 req/min) and server-side handling.

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

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

No contradiction with annotations (readOnly, idempotent, etc.). Adds key behavioral details: email always null, raison_sociale truncated, perimetre field meaning, imagerie returns 0, nom_commune resolution logic, and include_freshness effect.

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 sections (list, version notes, source notes, caveats). Front-loaded with purpose. Slightly verbose due to enum list repetition 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 complexity (6 params, 1 required, output schema, many siblings), description covers all aspects: filters, behavior, caveats, cross-references, and data quality notes. 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?

While schema coverage is 100%, description adds significant meaning: explains XOR strict, combined use of departement as disambiguation hint, nom_commune resolution via geo API, abbreviation rules, and the effect of include_freshness beyond schema defaults.

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 lists FINESS establishments by family (categorie) with optional department/commune filters. Explicitly distinguishes from radius-based siblings ('Pas de rayon') and provides scope for exhaustive administrative 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?

Provides explicit when-to-use (enumeration without radius), when-not (avoids imagerie due to zero results), and alternatives (cross-check with SIREN/SIRET for legal name). Also explains parameter interaction (XOR constraints, combinational hints).

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 readOnlyHint and idempotentHint annotations, the description discloses critical behavioral traits: email is always null, raison_sociale is abbreviated, imagerie family typically returns 0, the filtering 'lens' based on principal category, and the effect of include_freshness parameter. 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 longer than ideal but each sentence adds necessary context about edge cases and limitations. It is well-structured with notes introduced by 'Note:' and 'Lentille:'. A slightly tighter edit could improve conciseness without losing 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 tool's complexity (6 parameters, 24 families, output schema exists), the description covers essential edge cases and provides cross-referencing advice. It mentions perimetre field in output, but since output schema is present but not shown publicly, the description complements well.

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

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

Schema coverage is 100%, and the description adds significant meaning beyond schema descriptions: explains that familles filter by principal category, clarify radius_km behavior, describe the include_freshness opt-in and caching, and note that imagerie returns 0. This greatly aids agent understanding.

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

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

The description explicitly states the tool searches for FINESS healthcare establishments within a geographic radius using PostGIS ST_DWithin, and lists all 24 available families. It clearly distinguishes from sibling tools by specifying the FINESS dataset, unlike other tools focused on different datasets like centres_sante or entreprises.

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 does not explicitly state when to use this tool versus alternatives among the 30+ sibling tools. It provides indirect guidance by explaining limitations and suggesting cross-checking for full legal names, but lacks explicit usage context or exclusion criteria.

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

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

The description enriches beyond annotations by detailing the auto-derivation of familles, NAF↔famille matching logic, version-specific behavior, and the metric calculation. This adds significant behavioral context without contradicting annotations.

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

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

The description is well-structured, starting with purpose, then methodology, then version details. It is slightly verbose but each sentence contributes meaningful information. The front-loading 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 the tool's complexity (multi-source ratio, auto-derivation, version nuances), the description covers methodology, caveats, and behavioral details thoroughly. An output schema exists, and the description does not need to explain return values.

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 parameters have schema descriptions (100% coverage). The tool description adds value by explaining auto-derivation for 'familles', truncation for 'max_unites_legales', and example NAF codes, going beyond the schema's basic descriptions.

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

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

The description clearly states the tool compares coverage between FINESS DREES and SIRENE DINUM in a radius, with a defined metric (ratio). It distinguishes itself from siblings like 'reconcilier_finess_sirene' by focusing on geographic coverage rather than entity-level 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 states the utility: detecting sur-déclaration or sous-déclaration. It provides methodological context and caveats, implying when to use. However, it does not explicitly list alternative tools or conditions 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?

Beyond annotations (readOnlyHint, idempotentHint, etc.), the description explains crucial behavioral details: how to assess geocoding confidence with score thresholds, the meaning of confidence_low, and granularity interpretation via type. 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 highly concise: two paragraphs, no filler. The first sentence states the core action, followed by essential clarifications on output fields. 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?

Despite the absence of an output schema, the description fully explains the output fields (score, confidence_low, type) and their interpretation. For a simple geocoding tool with 3 parameters, this is complete and sufficient for an agent to use it correctly.

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

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

Input schema covers all 3 parameters with descriptions (100% coverage). The description adds no further semantics to the input parameters, focusing instead on output fields. Baseline 3 is appropriate as the schema already documents parameters adequately.

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 geocodes a French address to GPS coordinates, specifying the source (IGN Géoplateforme) and precision (street number). It distinguishes itself from siblings like 'reverse_geocode' by focusing on forward geocoding of addresses.

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 usage guidance on interpreting the response via score, confidence_low, and type fields, including explicit warnings ('ne PAS utiliser point pour une décision quand confidence_low: true'). However, it does not compare to sibling tools or specify when to use this geocoder over others.

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, openWorldHint, and destructiveHint. The description adds behavioral context about the discriminated return type (LookupResult) and the fields included. This is useful but does not significantly expand beyond the annotation coverage.

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

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

The description is concise with two sentences. It front-loads the primary purpose and then adds necessary details about return type and error handling. No extraneous 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 single parameter, presence of output schema, and strong annotations, the description is complete. It covers purpose, parameter details, return structure, and fallback behavior, leaving no gaps for this simple tool.

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

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

The schema already describes the 'code' parameter with an example. The description adds value by listing accepted aliases (code_insee, codeInsee, insee) and providing multiple examples of valid INSEE codes, which aids correct invocation.

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' (retrieve) and the resource 'commune' by code INSEE. It distinguishes from the sibling tool `autocomplete_commune` by mentioning it for disambiguation when not found.

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: use this tool to retrieve a commune by INSEE code. It also advises using `autocomplete_commune` for disambiguation when the commune is not found, which helps the agent decide between siblings.

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

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

Beyond the annotations (readOnly, idempotent, etc.), the description discloses detailed behavioral traits: the specific data sources used (FINESS, RPPS, DINUM, INSEE), the cost in terms of API calls, the fact that it includes closed SIRETs, and that there is no cache. This adds significant transparency about what happens during execution.

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 first sentence stating the main purpose, followed by a version note, typical usage, output format, and cost. Although it is somewhat lengthy, every section adds valuable information and there is no redundancy. The information density is high.

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 covers the input, output format, behavior, typical uses, and cost. It does not explicitly address error conditions or edge cases, but the provided information is sufficient for an AI agent to correctly invoke the tool in typical scenarios.

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 describes the single parameter 'num_finess' as a 9-digit exact number with 100% coverage. The description does not add any additional semantics or constraints beyond what the schema provides, so it meets the baseline but does not exceed it.

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 that the tool reconstructs the complete timeline of a healthcare establishment by cross-referencing multiple data sources. It distinguishes itself from siblings like 'etablissement_by_finess' by focusing on historical changes rather than current state, and includes typical use cases that clarify its specific role.

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

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

The description provides three typical usage scenarios (post-merger history, exact closure date, rebranding cascade) that serve as clear guidance on when to use this tool. While it does not explicitly list alternatives or state when not to use it, the scenarios implicitly differentiate it from current-state tools. This is strong contextual 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, idempotent, and non-destructive behavior. The description adds detailed behavioral context: parallel sub-calls, caching, a p95 cost of ≤600ms, payload size (~7K tokens), and conditions for `found: false` and `historique` availability. 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 fairly long but well-structured, starting with a summary, moving to use cases, return format, cost, and parameters. Every sentence contributes useful information, though some technical details could be slightly condensed. The structure enables quick 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?

Given the tool's complexity (three sub-calls, multiple sections, optional parameters), the description comprehensively covers return format (`LookupResult` with `found` flag, four sections), edge cases (e.g., `historique` unavailable when no SIRET candidate), and payload alternatives. Output schema exists but description still adds necessary context.

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 significant semantics: explains `num_finess` format, `rpps_limit` meaning (sample size, not total, with `truncated` flag), and `historique_detail` effect on payload. It also mentions accepted aliases (`numFiness`/`finess`/`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 it provides a 360-degree view of a health establishment, aggregating multiple data sources. It explicitly distinguishes itself from siblings like `verifier_site_actif`, `rpps_dans_etablissement`, and `historique_etablissement` by stating it replaces these individual tools, and contrasts with `panorama_sante_territoire`.

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 use cases (prospection, audit territorial, CRM enrichment) and advises against using it for targeted needs, recommending individual tools instead. It also suggests setting `historique_detail: false` for batch usage due to heavy payload.

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 substantial behavioral context beyond annotations: pagination details, scope (libéraux conventionnés only), exclusions, source and update frequency, and consequence of mixing codes (empty response).

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 sections: purpose, warnings, referentiel details, pagination, scope. Every sentence adds value; slightly long but not verbose 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?

Highly complete given tool complexity: explains all parameters, pitfalls, scope, exclusions, source, and update frequency. 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?

Schema coverage is 100% with descriptions for all 5 parameters. The description adds value by explaining referentiel-specific contexts (e.g., profession_code only for rpps_savoir_faire) and pagination behavior, justifying above-baseline 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?

Clearly states the tool lists nomenclature codes from the server, with specific verb 'Découverte des nomenclatures' and resource. Distinguishes from siblings by being a prerequisite for filtering 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?

Explicitly instructs to call before filtering rather than guessing codes, warns about distinct nomenclatures and not mixing codes. Provides precise usage for each référentiel and which sibling tools they apply to.

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 detailing degradation mechanism with couverture flags, return format (summaries only), special handling for Paris/Lyon/Marseille (plm_mode=true), precision of prescripteurs counts, and the total rejection on geocoding failure (RangeError). Annotations already indicate readOnly, idempotent, non-destructive; description adds crucial behavioral context.

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

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

The description is long but every sentence is informative. It is front-loaded with the core purpose, then details each section, degradation, pitfalls, and workflow. No fluff; each word earns its place. Structure is logical and easy to parse.

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

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

Given the tool's complexity (7 sections, degradation, fallback), the description is remarkably complete. It explains what each section contains, how to interpret couverture flags, when to use fallbacks, and the workflow for post-processing. The output format is adequately described as summaries only. No gaps that would leave an agent guessing.

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 detailed descriptions (100% coverage). The main description adds value by explaining the XOR relationship between point and adresse, the default rayon_km of 5, and that geocoding uses IGN. It also clarifies that code_insee is needed with point. This complements the schema without being redundant.

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: a comprehensive lab implantation study that aggregates 7 sections in parallel, replacing ~15 individual MCP calls. It specifies the verb ('Étude d'implantation labo'), the resource (address, geocoding, and data sections), and distinguishes it from siblings by being the composite 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?

The description explicitly tells when to use this tool: as the first call to start a study, then follow up with individual tools for partial/indisponible sections and 'enrichir_concurrents' for the top 3 competitors. It also states that this replaces ~15 individual calls, guiding the agent to prefer this over many siblings.

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 (readOnly, idempotent, etc.), the description adds critical behavioral context: mixed granularity (commune vs département), unsupported cities (PLM), no business interpretation returned, and data sources. No contradiction with annotations.

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

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

The description is long but well-structured with sections and bullet points. It is front-loaded with the main purpose, though it includes version numbers and technical details that could be trimmed. Reasonably concise 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 complexity (4 params, no output schema), the description is very complete. It explains aggregation levels, unsupported cities, error behavior, data sources, and references to sub-fields like 'niveauEtablissements' and 'demande'. Covers all important aspects.

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 significant value: examples for 'code_insee', disambiguation hints for 'nom_commune', warning for 'departement' alone, and default values for 'finess_familles'. This goes beyond schema definitions.

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 provides a 'Panorama santé' of a French commune in one call, aggregating multiple data sources. It distinguishes from siblings by noting it replaces 7-10 individual MCP calls.

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 when to use this tool (e.g., for a commune panorama) and when not to (e.g., Paris/Lyon/Marseille, use individual tools at département level). It also provides alternatives like 'profil_iris' for detailed queries and warns against using 'departement' alone.

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?

Discloses return format (LookupResult with 'found' discrimination), data sources (INSEE RP 2022, Melodi), code auto-detection, special cases (PLM, Mayotte, commune fusionnée), and orientation for errors, adding value beyond readOnlyHint and idempotentHint 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?

Well-structured with bullet points, clear sections, and no redundancy. Every sentence provides essential context despite thoroughness.

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?

Completely covers input, behavior, output (despite output schema existing), error handling, data sources, and alternatives, making the tool fully understandable for correct invocation.

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

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

With 100% schema coverage, the description adds extensive detail: length auto-detection, examples, special codes (2A, 976), and instructions for PLM arrondissements, far exceeding schema-based documentation.

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

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

The description clearly states the tool's purpose: to return population data for communes, departments, or IRIS based on INSEE code length. It differentiates from sibling tools like profil_iris for detailed demographics and autocomplete_commune for fused communes.

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 provides when to use (population totals), when not to use (detailed profiles, fused communes, PLM arrondissements, Mayotte), and names alternative tools (profil_iris, autocomplete_commune).

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 (readOnly, idempotent), the description discloses multiple entries per professional, geo_precision field, automatic FHIR fallback, source distinction, and freshness parameter scope. 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 and efficient, but slightly lengthy. Each sentence adds value, though it could be more compact without losing 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 tool's complexity and existing annotations, the description covers purpose, ID format, multi-site behavior, geo_precision semantics, fallback, source, freshness, cache, and license. Output schema exists, so return values need not be detailed.

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 significant meaning beyond the schema: clarifies rpps_id format (11/12 digits, prefix '81'), explains include_freshness only affects 'db' source. With 50% schema coverage, it compensates well.

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 complete professional profile by national ID (rpps_id), specifying the ID format. It distinguishes from sibling tools which are for search by name, radius, or department.

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 context on output structure and fallback, but does not explicitly state when to use this tool versus alternatives like rpps_search_by_name or professionnels_rpps_in_radius. The usage is implied but not contrasted.

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 detail beyond annotations: explains geo_precision types, distance calculation (haversine), multi-site behavior, deduplication, caching, and data freshness. 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?

Description is lengthy but well-structured with paragraphs and bolded terms. Every sentence contributes necessary information, though it could be slightly trimmed. Front-loaded with key details.

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

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

Given the output schema exists, the description does not need to explain return values. It covers geocoding precision, multi-site, dedup, source, legal reuse, and out-of-scope professionals. Complete for a tool with 9 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. Description adds value by explaining broadness of type_ps_codes, recommending specialite_codes for precision, clarifying dedup behavior, and referring to main description for precise_only. Does not contradict or unnecessarily repeat.

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 in a radius, but does not explicitly distinguish from sibling tools like 'professionnels_rpps_in_radius' which uses a different data source. However, the mention of 'Annuaire santé Ameli' implies the source.

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 'precise_only' for short radii, when to use 'specialite_codes' over 'type_ps_codes', limitations of distance (bird flight), and what is out of scope (hospital employees, salaried biologists). Also directs to 'lister_nomenclature' for 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 declare readOnlyHint, idempotentHint, and destructiveHint. Description adds behavioral details: pagination (offset, truncated), deduplication (dedupe_by_ps), data source freshness (include_freshness), and legal reuse constraints. 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?

Although long, every sentence serves a purpose. It begins with core purpose, then explains parameters, taxonomy, usage tips, perimeter, and source. Well-structured and front-loaded with essential 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 7 parameters and an output schema, the description covers all necessary context: filtering, pagination, deduplication, scope, source, and legal notes. No gaps for an agent to misuse the 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%, baseline 3. Description adds value: explains why prefer specialite_code over type_ps_code, provides example codes, clarifies pagination mechanics, and describes deduplication behavior. This goes beyond 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 the tool lists liberal health professionals in a department with optional filters, specifying it is for administrative enumeration and not by radius. This distinguishes it from siblings like professionnels_in_radius.

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 (administrative enumeration, not radius), advises using specialite_code for precise targeting, recommends lister_nomenclature for exhaustive codes, and clarifies perimeter (only liberal conventionnés) and out-of-scope (hospital, salaried).

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 behavioral details beyond the annotations (readOnlyHint, idempotentHint): the hybrid mode combining precise and centroide results, the exact semantics of distance_km, the data_freshness opt-in, and server-side cache (5 min). 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 every sentence serves a purpose. It is front-loaded with the core distinction from the sibling tool, then parameter details, then behavioral notes. Could be slightly more structured (e.g., bullet points), but is clear and free of 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?

Given the tool's complexity (10 parameters, nested objects, multiple geo_precision modes, code mismatches), the description is remarkably complete. It covers output fields (geo_precision, distance_km), data freshness, code references, and provides a URL for professional categories. The presence of an output schema (not shown) further reduces burden, but the description already suffices.

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 80% (high), baseline 3. The description adds significant value for key parameters: explains precise_only in depth with usage threshold, clarifies include_freshness as opt-in to avoid payload weight, and gives examples for profession_codes. The nested center object is adequately described in schema, so no extra needed. Overall, adds meaningful context.

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 this tool finds healthcare professionals in a radius using the RPPS database, and explicitly distinguishes it from the sibling tool 'professionnels_in_radius' (which uses Ameli and only includes libéraux conventionnés). The 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?

The description provides extensive guidance: when to use precise_only (recommended for short radii), how geo_precision categories affect use, and critical warnings about not mixing ANS and Ameli codes. It also suggests using lister_nomenclature to discover codes and explains the default category and opt-in for 'agents publics' and 'étudiants'.

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, openWorldHint, idempotentHint, destructiveHint=false. Description adds: lists all PS, pagination behavior, geolocation precision with geo_precision field, category defaults and opt-ins, critical warning about ANS vs Ameli code mismatch, source and license. 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?

Description is long but every sentence is informative. Structured with clear sections: purpose, alternative, pagination, geolocation, filters, categories, nomenclature warning, source. Slightly verbose but well-organized and front-loaded.

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

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

Given the complexity (9 params, output schema exists, annotations present), the description is extremely complete. Covers pagination, geolocation precision, category inclusion, nomenclature warnings, and cross-references other tools. Fully adequate for correct agent 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 coverage is 78% (high). Description adds meaning: explains default category (Civil, C, ~97%), opt-in for agents publics and etudiants, geo_precision field in results, warning about ANS/Ameli code confusion, and reference to lister_nomenclature for discovering ANS codes. This is valuable context 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 lists all health professionals (PS) in a department via RPPS, including both liberal and salaried. It distinguishes from the sibling tool professionnels_par_specialite_dept by noting that the latter is for liberal conventioned only via Ameli.

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 to use this tool vs. the sibling: 'Pour les libéraux conventionnés uniquement, préférer professionnels_par_specialite_dept (Ameli).' Also explains pagination with offset until truncated=false, and provides guidance on filters and category opt-ins.

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

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

Annotations already set readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds critical behavioral details: the proxy nature of `revenu_median_pondere` (population-weighted average, not a true median), coverage limitations (FILOSOFI only for communes ≥5000 hab), and the geographic centroid logic for basin aggregation. 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 and bullet-point style. Every sentence provides necessary information (modes, data sources, limitations). Could be slightly shortened without losing content, but the structure aids 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 tool's complexity (two modes, aggregation logic, data sources, multiple output fields), the description covers all essential aspects: input constraints, mode behaviors, output fields, data freshness, and limitations. An output schema exists, so return values need not be detailed. The description is complete for an AI agent to use correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value beyond schema: explains the mutual exclusivity of point vs code_iris, the effect of rayon_km on mode (ilot vs bassin), and the output structure (LookupResult with mode, revenu_median_pondere, etc.). It does not add syntax or format details already in 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 defines the tool as providing demographic profiles at the IRIS level, specifying data sources (INSEE RP 2022 + FILOSOFI 2021) and differentiating it from sibling tools like `population` (simple population) and `panorama_sante_territoire` (broader health panorama). The verb 'Profil démographique' and resource 'QUARTIER (IRIS)' 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?

The description explicitly explains two modes (with/without `rayon_km`) and gives guidance on when to use alternatives: 'Pour une simple population de commune/dept, utiliser `population`.' It also clarifies input constraints (exactly one of point or code_iris) and the optional parameter.

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 context beyond the annotations, such as the public nature of the algorithm, the weighting of sub-scores, and the detailed output structure including the 'skipped' field. It does not contradict the 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 thorough but somewhat lengthy, containing multiple paragraphs and bullet points. While well-structured, it could be more concise. However, the detail is warranted given the complexity of the tool.

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 (context signals indicate 'Has output schema: true'), the description covers all essential aspects: algorithm, scoring logic, output fields (candidates, skipped, score_global), and differentiation between no candidates and rejected candidates. It is complete for the 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?

The single parameter 'num_finess' is well-documented in the schema (9-digit exact number). The description provides context on how it is used (to retrieve FINESS data) but does not add new semantic information beyond what the schema already covers. Schema coverage is 100%, so 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's purpose: cross-referencing FINESS and SIRENE data to compute a coherence score for candidate SIRETs. It also explains the use case (confirmation/infirmation before prospection) and distinguishes itself from sibling tools by detailing its unique scoring algorithm.

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

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

The description explains when to use the tool (before prospection or quality cross-check) and clarifies the meaning of the 'skipped' field to differentiate scenarios. However, it does not explicitly mention when not to use it or list direct alternatives among siblings.

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 out-of-zone coordinates return null (not an error), specifies coverage area, and identifies the data source. Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint, which are consistent with the description.

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

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

The description is two sentences: the first states the core purpose, the second provides essential caveats. It is concise, front-loaded, and every sentence adds value 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?

For a simple two-parameter tool with no output schema, the description covers return value behavior (null for out-of-range), data source, coverage area, and error handling. It is complete for the tool's 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 has 100% parameter description coverage (lat, lon described as WGS84). The description adds overall context but does not provide additional parameter-specific details beyond what the schema already offers. A baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: reverse geocoding from GPS coordinates to nearest address. It specifies the data source (IGN Géoplateforme) and coverage (France métropolitaine + DOM), distinguishing it from siblings like geocode_adresse. The behavior for out-of-zone coordinates is also clarified.

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 usage context by stating coverage limitations and the return of null for out-of-zone coordinates, implying when not to use the tool. However, it does not explicitly name alternatives or provide when-not-to-use guidelines relative to siblings.

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, and non-destructive. The description adds significant behavioral context: coords and distance_km are null (not spatial), default category Civil with percentages, opt-ins for agents publics and etudiants with percentages, and data freshness opt-in. It also cites source and license. 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 clear front-loading: first sentence states core purpose. Each subsequent sentence adds value (output format, categories, opt-ins, reference). It is slightly lengthy but every part earns its place. Minor redundancy in category explanations could be trimmed.

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 5 parameters and an output schema, the description covers essential behavioral aspects: explains that coords are null, default categories, opt-ins with percentages, data freshness, and source. With an output schema present, missing output field details are acceptable. The description is complete for the tool's purpose.

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 only 20% (only include_freshness described). The tool description compensates by explaining num_finess format, and the semantics of include_agents_publics and include_etudiants with percentages and examples. However, it does not mention the limit parameter, leaving a gap.

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

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

The description clearly states the tool lists healthcare professionals (PS) attached to a FINESS establishment using specific verb 'Liste les PS rattachés'. It distinguishes itself as a pivot between RPPS and FINESS, directly answering 'qui travaille dans ce labo / hôpital / clinique ?'. It contrasts with sibling tools like etablissement_by_finess by noting it is not 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 provides explicit when-to-use guidance: for finding professionals in an establishment. It gives when-not-to-use advice, stating for geolocation to pivot via etablissement_by_finess. It explains default categories and opt-in filters, and discusses coverage of salaried workers. This helps an agent decide between this and 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 declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. Description adds sorting by match_score, meaning of scores <0.3, truncated flag, and geo_precision field interpretation. 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 paragraphs and bullet points, front-loading purpose and usage. It is somewhat long but every sentence adds value. Slight redundancy in explaining geo_precision twice could be merged.

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 (7 parameters, output schema exists), the description covers all necessary aspects: purpose, usage, behavioral nuances, parameter details, output interpretation (match_score, truncated, geo_precision), categories, source, and license. 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?

Schema coverage is 71%, but description adds extensive meaning: explains 'limit' default and max, 'departement' format (including Corsica and DOM/COM), and 'include_freshness' with details about data_freshness field structure and caching. Describes boolean parameters 'include_etudiants' and 'include_agents_publics' with category percentages and reference URL.

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 health professional by identity using trigram matching tolerant to accents/typos, with an example. It distinguishes from sibling tools like 'professionnels_in_radius' and 'professionnel_by_rpps' which are geospatial or exact RPPS lookup 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?

Explicitly specifies that 'nom' is mandatory, and 'prenom' and 'departement' refine the search. Provides an example 'Dr Martin à Paris'. Warns about homonyms when departing is omitted and advises filtering by department or first name for common names. Also explains opt-in categories.

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 beyond annotations: the M&A fix, co-localization logic, two distinct verdicts, fallback mechanisms, and cost. Annotations provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint but the description adds rich context. 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 lengthy but well-structured with sections (V0.16 fix, Logique, Format de retour, Coût). It is front-loaded with the main purpose. Some redundancy could be trimmed, but for a complex tool 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 tool's complexity (multiple data sources, two verdicts, M&A edge cases), the description is remarkably complete. It covers input, algorithm, output format (LookupResult), and cost. The presence of an output schema supplements but the description adds necessary context for the agent to understand the tool's behavior.

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

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

Schema coverage is 100% (single parameter num_finess with description). The description mentions the parameter in the return case when num_finess is absent, but does not add new syntax or format details. Baseline 3 is appropriate since schema already covers meaning.

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: "Vérifie si un établissement de santé FINESS est encore en activité..." with specific verb "vérifie" and resource "établissement de santé FINESS". It distinguishes itself from sibling tools like etablissement_by_finess and reconcilier_finess_sirene by focusing on activity verification with cross-referencing logic.

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 context (checking activity status) and describes the algorithm steps, but does not explicitly state when to avoid this tool or suggest alternatives. Given the complexity and the presence of sibling tools, a clear when-to-use/when-not-to-use statement would improve it.

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