France Data MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.26.3
Disambiguation4/5
Despite 34 tools, each has a clearly defined purpose with detailed descriptions that differentiate them (e.g., etablissement_by_finess vs centres_sante_by_finess, or professionnels_in_radius vs professionnels_rpps_in_radius). Minor potential confusion between some radius and category tools, but generally distinct.
Naming Consistency4/5
Most tools follow a consistent snake_case verb_noun or noun_preposition pattern (e.g., etablissement_by_finess, professionnels_in_radius, geocode_adresse). A few deviate (data_freshness, enrichir_concurrents) but remain readable and predictable overall.
Tool Count4/5
34 tools is high but justified by the server's broad scope covering establishments, professionals, communes, comparisons, composites, and utilities. Each tool addresses a specific need; no obvious redundancy. Could be slightly trimmed but still reasonable.
Completeness4/5
Covers most aspects of French health data: FINESS, SIRENE, RPPS, Ameli, population, geocoding, nomenclature, composite panoramas. Minor gaps like no establishment name search or direct lab search, but these are covered indirectly via filters and existing tools.
Average 4.7/5 across 34 of 34 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 24 of 25 community issues answered or closed in the last 6 months
- 93 commits in the last 12 weeks
- Last stable release on June 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, which the description aligns with by stating it 'reconstitue' and 'lit'. The description adds behavioral context like data sources, cost (number of calls), and absence of cache, which goes beyond annotations. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a bold version note, bulleted usage examples, and logical sections (purpose, cost, format). It is slightly verbose but 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, output schema mentioned, and annotations covering safety/idempotency, the description is quite complete. It explains the multi-source nature, typical use cases, cost, and no cache. It covers the essential context an AI agent needs to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the sole parameter `num_finess`, so the baseline is 3. The description does not add meaning beyond the schema (it only mentions 'Numéro FINESS exact (9 chiffres)'), which matches the schema description. No additional semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it reconstitutes the complete timeline of a healthcare establishment by cross-referencing multiple sources, clearly distinguishing it from sibling tools like etablissement_by_finess (current data) and reconcilier_finess_sirene (different operation). The verb 'reconstitue' and resource 'timeline' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides three typical use cases (tracing history after merger, identifying exact closure date, understanding rebranding cascades) and mentions costs and no cache. It does not explicitly state when not to use or compare alternatives, but the use cases imply appropriate context. Clear guidance overall.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Au-delà des annotations (readOnly, idempotent), la description détaille le comportement : détection des SIRET fermés listés actifs, logique de résolution avec distance géodésique, deux verdicts distincts, gestion des successions, coût estimé des appels. Aucune contradiction avec les annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Le texte est long et structuré en sections, mais contient des détails superflus comme le numéro de version (V0.16) et des explications très techniques qui auraient pu être abrégées.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
La description couvre l'ensemble des aspects : sources de données, étapes de la logique, format de sortie, détection des successions, cas d'absence de résultat. Un schéma de sortie existe, donc les détails du retour sont suffisants.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Un seul paramètre (num_finess) dont le schéma fournit déjà une description complète (9 chiffres). La description n'ajoute pas d'information supplémentaire sur le paramètre, mais la couverture du schéma étant totale, le score de base de 3 est approprié.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
La description précise l'action ('Vérifie si un établissement de santé FINESS est encore en activité') et le recours à plusieurs sources, ce qui la distingue clairement des outils frères comme 'etablissement_by_finess' ou 'reconcilier_finess_sirene'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
La description suggère une utilité pour l'audit territorial mais n'explicite pas quand privilégier cet outil par rapport aux alternatives, ni les cas où il ne faut pas l'utiliser.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds significant behavioral context: it explains the return value is a discriminated union (LookupResult), details the three possible statuses (exact_match, divergent_after_normalization, rpps_absent), and describes the behavior when num_finess is not found (found: false with lookupStatus). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, utility, status explanations, and a note on return format. While it is somewhat lengthy, every sentence contributes necessary detail. It is front-loaded with the main action, making it efficient for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and the existence of an output schema (LookupResult), the description thoroughly explains all possible return scenarios and their meanings. It covers edge cases (not found, absent RPPS) and clarifies the discrimination of the output, leaving no ambiguity about the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter (num_finess) with a description 'Numéro FINESS exact (9 chiffres).' The description reinforces this exact format but does not add new meaning beyond what the schema provides. Since schema coverage is 100%, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: comparing the raison sociale from FINESS DREES against that from RPPS/Annuaire Santé ANS for a given num_finess. It specifies the verb 'compare' and the two specific resources, and it distinguishes itself from sibling tools by focusing on this niche comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when the tool is useful (e.g., detecting rebranding discrepancies after M&A) and notes a limitation (it does not determine who acquired whom). However, it does not explicitly state when to avoid using this tool or mention alternatives among the sibling tools, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), description discloses token consumption (~7K per call), hard cap on competitors, partial failure handling via coverage flag, and sub-tools used. Adds substantial 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but well-structured: overall purpose, per-competitor details, cap, coverage flag, typical usage, sources. Slightly long but efficient with front-loaded key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description mentions return fields (coverage flag, status, etc.). However, output structure is not fully specified, which is a gap for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters, but description adds significant meaning: finess as top competitors by distance, max as hard cap default 3 with rationale (token usage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a deep investigation of top competitors, listing specific data points (status, team size, recent history, M&A signals, parent group) and distinguishing it from sibling tools like inspect_site and entreprise_by_siren which are sub-calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions typical usage: 'Typiquement appelé sur concurrents.top[0..2].finess renvoyés par panorama_implantation_complet' and imposes a hard cap of 3, but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safety (readOnlyHint=true, destructiveHint=false). The description adds behavioral details: uses IGN Géoplateforme, covers specific regions, and returns null for out-of-range coordinates. There is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and front-loaded. It conveys purpose, source, coverage, and edge-case behavior in two clear sentences without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose, source, coverage, and null behavior. However, since there is no output schema, the description could mention the format of the returned address (e.g., string or structured object) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with basic descriptions for lon and lat. The description adds context about coordinates being in WGS84 but does not provide additional semantic meaning beyond what the schema already conveys. The null behavior is beneficial but not parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs reverse geocoding from GPS coordinates to find the nearest address, specifying the data source (IGN Géoplateforme) and geographical coverage. It effectively differentiates from sibling tools like geocode_adresse (forward geocoding) by focusing on the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions when to use the tool (reverse geocoding) and provides important usage context: coverage limited to metropolitan France and DOM, and that coordinates outside this area return null (not an error). However, it does not explicitly list alternative tools for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides extensive behavioral detail beyond annotations: the algorithm (Sørensen-Dice on bigrams), scoring formula, verdict thresholds, and output structure including the skipped field. It also notes the algorithm is public and no proprietary value. This fully satisfies transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and well-structured with clear sections (intro, logic, algorithm note, format). While a bit long, every part adds value. It is front-loaded with purpose and provides all necessary details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, full schema coverage, and an output schema (not shown but mentioned), the description is highly complete. It covers algorithm, scoring, verdicts, and nuanced output like skipped. The agent has all needed context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter num_finess is fully described in the schema as 'Numéro FINESS exact (9 chiffres)'. The description does not add further detail for this parameter, but the schema coverage is 100%, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it crosses FINESS DREES with SIRENE INSEE and calculates a coherence score using Sørensen-Dice. It distinguishes itself from siblings like etablissement_by_finess and finess_sirene_coverage_in_radius by focusing on reconciliation with a detailed scoring mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is useful for confirming/rejecting a num_finess ↔ SIRET mapping before prospecting or quality cross-check. It provides clear context but does not explicitly list when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 useful context: the data source (geo.api.gouv.fr), alias mapping for parameters, and a recommendation for 'boostPopulation'. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short paragraphs. It front-loads the purpose and then provides essential usage details. Every sentence adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 no output schema, the description provides sufficient context: purpose, required parameters, aliases, data source, and a recommendation. It covers all necessary information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all 5 parameters. The description adds alias mapping (e.g., 'q' maps to 'nom') and a usage tip for 'boostPopulation'. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches French communes by name, postal code, or INSEE code, and explicitly mentions it is ideal for autocompletion. This distinguishes it from sibling tools like 'get_commune_by_code' which likely returns a single commune.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that at least one of 'nom', 'codePostal', or 'code' is required, lists aliases, and recommends using 'boostPopulation' for ambiguous names. However, it does not explicitly state when not to use this tool or provide alternatives, but the context of autocomplete is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond annotations, including that 'email' is always null, 'raison_sociale' is abbreviated, the families filter uses principal category only, and 'imagerie' typically returns zero. It also explains data freshness and caching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured, starting with purpose then adding specifics and warnings. Each sentence adds value, though it could be slightly more concise or use bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, no output schema provided but referenced), the description covers edge cases, data sources, limitations, and cross-references. It is complete for an agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the input schema covers all parameters with descriptions, the description adds valuable meaning: it explains the families filter's lensing effect, the abbreviation of raison_sociale, and the behavior of include_freshness. Schema coverage is 100%, but the description goes beyond.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for FINESS health establishments within a geographic radius using PostGIS ST_DWithin, with filtering by families. It lists 24 specific family values and distinguishes itself from siblings by focusing on spatial search and FINESS data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for spatial FINESS searches but does not explicitly state when to use this tool over alternatives like 'etablissements_finess_by_categorie' or 'centres_sante_in_radius'. No when-not or exclusion advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true, indicating a safe, read-only, idempotent operation. The description adds valuable behavioral context: computation of ratio, methodology, version-specific auto-derivation, and matching nuances (e.g., Hopital Franco-Britannique example). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and provides structured information using separate lines. It includes methodology, caveats, a version note, and an example. While each sentence adds value, it is somewhat verbose and could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (comparison of two data sources, version-specific behavior), the description covers purpose, usage methodology, caveats, and parameter behavior. The presence of an output schema means return values need not be explained. The description is comprehensive for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description enhances understanding by explaining the auto-derivation logic for `familles` when omitted, the truncation behavior of `max_unites_legales`, and mapping between NAF and families. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares FINESS DREES and SIRENE DINUM coverage in a geographic radius, specifying the metric (ratio) and use cases (over/under declaration). This distinguishes it from sibling tools like etablissements_finess_in_radius or entreprises_in_radius which likely list individual entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (detect coverage discrepancies) and provides context on parameter behavior (auto-derivation of familles, matching logic). It implies alternatives exist but does not explicitly name sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnly, idempotent, etc.) are already present, and the description adds critical context beyond them: score ranges for reliability, the meaning of confidence_low, and the type hierarchy. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured paragraphs. The first is concise; the second contains necessary detail about output reliability. Slightly verbose but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main geocoding behavior and output interpretation. Lacks error handling or what happens if address not found, but overall adequate for a simple geocoding tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 value by explaining how the output fields (score, confidence_low, type) relate to usage, helping infer parameter influence. However, it does not explicitly detail the adresse format or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states the tool geocodes French addresses to GPS coordinates, specifies the source (IGN Géoplateforme), and mentions precision at the house number level. This clearly distinguishes it from siblings like reverse_geocode and autocomplete_commune.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed guidance on interpreting the score and confidence_low fields to determine reliability, and explains the type granularity. However, it does not explicitly compare with alternative tools like autocomplete_commune or give when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotence. Description adds value by detailing the output structure (found true/false) and parameter aliases. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, well-structured, and front-loads the purpose. All sentences add value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description adequately covers return behavior and disambiguation hint. Complete for the tool's functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers code parameter well (100% coverage). Description adds alias information (code_insee, codeInsee, insee) not present in schema, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves a commune by its INSEE code. Specifies output structure (LookupResult discriminated by found) and distinguishes from sibling autocomplete_commune by mentioning disambiguation on not found.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides when to use (precise code) and what to do on not found (use autocomplete_commune). Could be improved by explicitly stating not to use without exact code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively covers behavioral details beyond annotations: fallback to live API, multiple entries per PS, geo_precision values, source field, freshness parameter behavior. Annotations already mark it as read-only and idempotent, and description adds rich context. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but concise, with each sentence contributing unique information. It is front-loaded with the main purpose and structured to cover ID format, multiple sites, geo-precision, fallback, and freshness. Slightly verbose but acceptable given complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple sites, geo_precision, fallback, output schema present), the description covers all necessary aspects: how results are structured, how to interpret geo_precision, source, freshness, and fallback behavior. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes include_freshness (50% coverage). The description compensates fully by explaining the rpps_id format (11-12 digits, prefix '81' for newer IDs) and clarifying the behavior of include_freshness (adds data_freshness field). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the complete profile of a health professional by national RPPS ID, including ID format details, multiple sites, and geo-precision. It effectively distinguishes from sibling tools like 'rpps_search_by_name' and 'professionnels_in_radius' which focus on search or radius queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you have an RPPS ID and need the full profile. However, no explicit when-to-use, when-not-to-use, or alternative tool recommendations are given. The description focuses on behavior rather than guiding selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive, idempotent, and open-world. The description adds valuable context: the data source (DGFiP DVF), that it covers only residential properties, and the proxy warning for commercial use. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise given the amount of information, but it could be slightly more streamlined. It front-loads the main output and uses clear language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema existing, the description explains what data is returned (median, quartiles, volume, period) and provides caveats. For a simple query tool with few parameters, this is complete and sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for lat, lon, and rayon_km. The description mentions 'point + rayon' but does not add significant meaning beyond the schema. Baseline 3 per rules for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns median price per m² for residential built properties, including quartiles, sales volume, and period. It specifies the source (DGFiP DVF) and distinguishes itself from siblings focused on health, demographics, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: it's for residential land costs only, for professional premises it's a proxy, and it should NOT be integrated into an attractiveness note because installation cost is distinct from market potential. This tells the agent when and when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate safe, read-only, idempotent, and open world behavior. The description adds valuable context: how it combines sources, handles missing commune data by still returning AU zones and land sales, and that it never crashes. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 150 words but is well-structured and front-loaded with the main purpose. Every sentence adds value, though it could be slightly more concise without losing essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of combining three sources and handling edge cases, the description is remarkably complete. It explains input parameters, output registers (note, info, geojson), special cases (dense cities, coastal points), and sources.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description does not add extra meaning beyond what the schema already provides (lat, lon, rayon_km). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool assesses real estate dynamics and growth potential using three official sources. It distinguishes itself from sibling tools which are mostly health-related, making its unique function evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use (for real estate dynamics and growth potential) and provides guidance on relying on AU zones and land sales in dense cities. Also explains how the tool handles coastal or isolated points, offering clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description details the number of API calls (1-2), rate limit (~1 req/s), and the nuanced behavior of `etablissements` truncation with `enrichmentStatus` fields. This adds significant value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (purpose, return format, warnings) and front-loaded. Every sentence adds value, though slightly verbose for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and complexity (enrichment status, truncation), the description covers the return format, error cases, and limitations comprehensively. Leaves little ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter `siren` with schema description 'SIREN exact, 9 chiffres.' The description reinforces this with 'exact, 9 digits' and context, adding slight value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a French company by SIREN, listing specific fields (raison sociale, NAF, etc.). It distinguishes from sibling tools like `entreprises_in_radius` by mentioning exhaustive enumeration alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use (to get company details) and provides an alternative (`entreprises_in_radius`) for multi-department cases. Also notes rate limits. However, it does not compare against all siblings, but the main distinction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Les annotations déclarent readOnlyHint et idempotentHint. La description ajoute des détails comportementaux importants : deux endpoints distincts, bornage du rayon à 50 km, comportement du paramètre includeDirigeants (suppression de la liste pour alléger le payload), et indication que la combinaison de paramètres incorrecte génère une erreur explicite. Aucune contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
La description est raisonnablement concise pour un outil complexe à 10 paramètres. Elle est structurée en paragraphes avec des listes numérotées. Chaque phrase apporte de l'information. Quelques redondances mineures (ex: répétition de 'deux modes EXCLUSIFs').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Avec un schéma de sortie présent, des annotations complètes, et une description couvrant les modes, les contraintes, les sources et une fonctionnalité spéciale (includeDirigeants), l'outil est entièrement documenté. Rien d'essentiel ne manque.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
La couverture du schéma est de 100%, donc la base est 3. La description ajoute une valeur significative en expliquant les deux modes et en détaillant le comportement de includeDirigeants (backward-compat, utilité pour l'énumération volume). Cela va au-delà du schéma.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
La description indique clairement qu'il s'agit d'une recherche d'entreprises françaises avec filtres NAF, code postal, département ou rayon géographique. Elle mentionne les secteurs couverts et la source. Cela la distingue des outils de santé ou d'établissements dans la liste des frères.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
La description explique les deux modes exclusifs (proximité et administratif) avec les paramètres associés et les combinaisons rejetées. Elle ne mentionne pas explicitement quand utiliser cet outil par rapport à ses frères, mais le contexte (entreprises vs santé) est implicite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite comprehensive annotations (readOnlyHint, idempotentHint, etc.), the description adds significant behavioral context: source API, return format (LookupResult with found/not_found cases), error messages for missing key or SIRET, and the fact that GPS coordinates are not returned. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (function, return format, sibling differentiation, rate limit). Front-loaded with essential details. Slightly verbose but justified by the depth of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (1 param) and presence of output schema, the description covers all necessary aspects: purpose, behavior, return values, error cases, rate limits, and alternatives. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'siret' described as 'SIRET exact, 14 chiffres.' The description merely reiterates this format, adding minimal additional semantic value beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves establishment details by SIRET, listing specific fields (raison sociale, enseigne, NAF, dates, status, adresse, effectif). It also distinguishes from sibling 'entreprise_by_siren', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use this tool versus 'entreprise_by_siren' (specific establishment vs legal unit). Provides guidance on detecting closed SIRETs still active in FINESS. Mentions rate limit (30 req/min) and alternatives for geolocation ('geocode_adresse', 'entreprises_in_radius').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, idempotent. The description adds value by explaining coverage (RPPS exposes link when declared, hospital employees well covered), output compression (null coords), and default category (Civil ~97%). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but each sentence adds value. It is front-loaded with purpose and structured logically: purpose, output details, coverage, opt-ins, source. Minor redundancy but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, output schema exists), the description covers all essential aspects: purpose, parameter usage (including opt-ins), output limitations (null spatial fields), and data source/reference. It is complete enough for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 20%, so description compensates. It explains num_finess (9 digits), include_etudiants (adds 2.5% category), and include_agents_publics (adds 0.3% category) with percentages and examples. limit and include_freshness are not described in text, but include_freshness has its own schema description. Overall adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists professionals attached to a FINESS establishment, specifies the exact resource (PS rattachés, num_finess), and distinguishes from sibling tools by being a RPPS↔FINESS pivot. It answers a specific question ('qui travaille dans ce labo/hôpital/clinique ?').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (find professionals by establishment) and when not to use (for spatial queries, since coords and distance_km are null). It provides alternatives (etablissement_by_finess for geoloc) and explains opt-in parameters and default behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Au-delà des annotations (readOnlyHint, idempotentHint, openWorldHint), la description précise la source (Annuaire santé Ameli), la synchronisation hebdomadaire (CNAM), le cache de 5 min pour le paramètre `include_freshness`, et le comportement exact pour `found: false`. Aucune contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
La description est structurée en paragraphes bien distincts (but, différenciation, comportement, source, alias). Elle reste concise malgré la richesse d'information ; chaque phrase apporte une information utile sans redondance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tous les aspects du comportement sont couverts : cas `found: true` vs `false`, source et fraîcheur des données, mention légale, alias, et renvoi vers le sibling approprié. La présence d'un output schema connu complète l'information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Le schéma couvre déjà 100% des paramètres. La description ajoute une valeur significative : les alias pour `num_finess` (numFiness/finess/etab_finess) et l'explication détaillée du paramètre `include_freshness` (opt-in, cache, champ `data_freshness`). La note sur le coût négligeable améliore la compréhension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Le verbe 'Récupère' est spécifique, la ressource 'Centre de Santé (CDS) par son numéro FINESS' est clairement identifiée. La différenciation explicite avec le sibling `etablissement_by_finess` et l'énumération des champs distinctifs (carte_vitale, APCV, spécialités) éliminent toute ambiguïté.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
La description indique précisément quand utiliser ce tool vs `etablissement_by_finess` : pour les structures non-CDS, il faut utiliser l'autre outil. Elle détaille aussi le cas `found: false` (pointant vers hôpital, EHPAD, labo ou CDS récent). Les alias acceptés sont listés.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent. Description adds: returns discriminated `LookupResult` with `found` flag, explains each status in detail, notes 'Primitive brute SANS interprétation métier'. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with sections (Utilité, Statut, Format) and front-loaded purpose. Every sentence adds value, though slightly long. Could be condensed but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, annotations, output schema, and single parameter, the description covers all necessary aspects: purpose, usage, status interpretation, and alternative tool. Complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single parameter `num_finess`. Description adds context: exact 9 digits, and that non-CDS numbers will return `not_found`. Provides more meaning than schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares addresses from CNAM and FINESS for a health center, with a specific verb ('compare') and resource ('adresse'). It distinguishes from sibling tool `compare_raison_sociale_finess_vs_rpps` by highlighting the equivalence for centers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: signals unsynchronized moves, explains statuses, and advises using `etablissement_by_finess` for non-CDS establishments. It tells 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive, idempotent. Description adds context: data freshness parameter behavior, stale data, null email, abbreviation. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: main purpose, then details, then notes on data quality and limitations. Not overly verbose, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations, schema, and output schema exist, description covers return types, special cases (not found), data freshness, and cross-references. No gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has full coverage with descriptions. Description adds meaning for include_freshness (explains effect, cache, cost) and notes num_finess is the exact 9-digit number. Slightly above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool retrieves detailed establishment info by FINESS number, enumerating fields like raison sociale, address, GPS. It distinguishes from siblings (e.g., etablissement_by_siret) by its unique identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states DREES data is 1-2 months stale, recommending cross-checks with ARS for emerging structures. Notes email is always null and raison_sociale is abbreviated, suggesting alternatives for full legal name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, non-destructive, idempotent, open-world. The description adds significant behavioral detail: parallel sub-calls, caching, payload size (~7K tokens), behavior when FINESS not found (returns specific structure), and the fact that historique may be unavailable. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections (purpose, usage, format, cost, aliases). It is relatively long but each part serves a purpose (e.g., cost/payload details are relevant for selection). Could be slightly trimmed, but not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, output schema, multiple sub-calls, caching), the description covers all necessary aspects: return format, error cases, aliases, performance considerations, and usage examples. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds meaning: for 'rpps_limit' it explains that 'professionnels.count' equals the sample size and 'truncated' flags excess; for 'historique_detail' it clarifies payload reduction. This exceeds the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Vue 360 d'un établissement de santé en 1 appel' and explicitly names the three individual MCP calls it replaces. It identifies the tool as an aggregator that combines FINESS, SIRENE, RPPS, and INSEE data into a single call, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases: prospection, audit territorial, batch CRM enrichment. It also advises when not to use it: 'Pour les besoins ciblés (juste le verdict, juste l'historique), préférer les tools individuels.' This provides clear when-to and when-not-to guidance with references to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide basic traits; description adds rich behavioral details: parallel execution, degradation flags, geocoding failure throws RangeError, special handling for big cities, and precision notes for prescripteurs and cds.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structured with clear sections: overview, replacement of calls, degradation, pitfalls, workflow. Slightly verbose in places but well-organized and front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description comprehensively explains output format (summaries only), each section's content, failure modes, and follow-up steps. Lists sibling tools for fallback. Highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all 4 parameters with descriptions (100% coverage). Description adds context: XOR constraint between adresse and point, need for code_insee with point, and default rayon_km. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a lab implantation study in one call, aggregating 7 sections in parallel. It distinguishes itself from siblings by replacing ~15 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this tool to start a study, then use unitaries for partial/indisponible sections, then enrich top 3 competitors. Also warns about degradation and no business interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral details beyond annotations: auto-detection of granularity by code length, return structure (LookupResult with found field), edge cases (fusion -> found:false, Mayotte absent), 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections for each granularity. It is front-loaded with the core purpose. Every sentence provides useful information, justifying the length for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all code types, returns structure, data sources, and edge cases. Given the output schema exists (not shown), the description is complete and provides sufficient context for correct tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description enriches the parameter meaning by explaining auto-detection, code length mappings, aliases, and examples. This adds value beyond the schema description, so it earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves population data for commune, département, or IRIS based on INSEE code length. It distinguishes from siblings like profil_iris and autocomplete_commune, specifying that this tool is for population counts while profil_iris provides detailed demographic profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use (population totals) and when not (detailed demographics use profil_iris; fused communes use autocomplete_commune). It also notes that PLM arrondissements and Mayotte are not supported, and gives alternative handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, and open-world hints. The description adds substantial behavioral context beyond annotations: data source and weekly sync (Ameli), coordinate precision (~3km average), absence of hours/tariffs/sector info, alias acceptance, and cache behavior for include_freshness. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: starts with core purpose, then differentiator, source/legal, volume, filters, caveats, and aliases. It is front-loaded with the most important information. While somewhat lengthy, every sentence earns its place by adding necessary detail. Slightly more concise could be achieved, but it remains clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, output schema exists, annotations present), the description covers all relevant aspects: purpose, differentiation, filter semantics, coordinate precision implications, data freshness opt-in, and legal source attribution. It fully equips an AI agent to decide when and how to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description significantly enriches parameter semantics. It explains specialite_codes match any-of logic, accepte_carte_vitale filtering rationale, type_etab_codes default/deprecated status, limit range, and include_freshness opt-in with cache details. Alias for lon/lat and radius_km further aid usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches for Health Centers (CDS) within a geographic radius using PostGIS ST_DWithin. It distinguishes from sibling tool 'etablissements_finess_in_radius' by highlighting specific fields like carte_vitale, APCV, and specialties. The verb 'recherche' and resource 'Centres de Santé' are specific, and the scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives, such as the differentiator from 'etablissements_finess_in_radius'. It explains filter logic (any-of for specialties, boolean for carte_vitale, type codes) and caveats about coordinate precision (centroid vs. exact address). Parameter aliases are also noted, aiding correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cache duration (5 minutes) and cost (1 SELECT). Annotations indicate readOnlyHint=true, which aligns with description. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose and structured into logical sections: sources, fields, usage, alerts, exclusions. Each sentence adds information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive coverage of all aspects: returns, usage, cache, cost, live source exclusion. Output schema exists, so description doesn't need to detail every field, but it sufficiently explains the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so description adds value by confirming no input needed and detailing output fields. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns freshness of specific data dumps (FINESS DREES, etc.) with fields and cadences. Distinguishes from sibling tools by focusing on data freshness meta-information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage scenario (before territorial audit or temporal analysis) and specific alert thresholds for each source (e.g., staleness_days > 90 for FINESS). Also clarifies that live sources are excluded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds important behavioral context: it uses INSEE Melodi population data (2023 census), does not return business interpretation (e.g., no auto 'desert medical'), defaults to Civil category, and notes that commune-level density is unavailable for Paris/Marseille/Lyon. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with bullet points, bold text, and logical sections. It is front-loaded with the core purpose. While verbose, every sentence adds value given the tool's complexity. A slight reduction could improve conciseness, but it remains clear and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and high complexity, the description is remarkably complete. It covers scope selection, filtering options, special cases (Paris/Lyon/Marseille), nomenclatures, data sources, and aliases. The only minor gap is not explicitly listing all possible `famille` values, but it provides representative examples and indicates extensibility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 82% schema coverage, the description adds significant meaning beyond the schema: explains conditional semantics of `code_dept`, re-emphasizes mandatory `famille` for 'etablissements', provides examples for `profession_code` and `savoir_faire_code`, and explains defaults for `mode_exercice_codes` and `include_*` options. This compensates for the 18% schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes health density per 100,000 inhabitants, specifying the targets (professionals via RPPS or establishments via FINESS) and geographic scopes (department or commune). It distinguishes itself from siblings by focusing on density calculations, not just listings or searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each parameter: when `cible` is 'professionnels' vs 'etablissements', conditional semantics for `code_dept` (scope vs hint), and special handling for Paris/Marseille/Lyon. It warns about not mixing ANS and Ameli codes and directs to `lister_nomenclature` for code discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds pagination behavior, truncation, caching, data_freshness opt-in, and warns that mixing codes returns empty without error. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long but well-structured with clear sections and warnings. Every sentence adds unique value, but could be slightly more concise. However, given the complexity, the length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, usage, parameter details, behavioral notes, exclusions, source attribution, and pagination. Output schema exists, so return values are not needed. Completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value for each parameter: detailed explanation of referentiel options, limit's interaction with total/truncated, include_freshness payload effect, include_specialites token savings, and profession_code default and edge cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool is for discovering server code nomenclatures, with a clear verb ('Découverte des nomenclatures') and resource. It distinguishes the three referentials and their specific purposes, and differentiates from siblings by warning against guessing codes and cross-referencing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: call before filtering, distinct nomenclatures, do not mix codes across referentials, pagination tips, and which tools use which nomenclature. Also notes excluded categories and source attribution requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by disclosing mixed granularity (commune vs department), no automatic business interpretation, version info, limitation for PLM cities, error for invalid inputs, and the meaning of 'niveauEtablissements' field. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence contributes valuable information; it is well-structured with version notes and clearly separated sections. Could be slightly more concise but justified by tool complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description sufficiently explains return values (population, densities, FINESS count, DEMANDE block) and critical behavioral details like error cases and granularity, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters have schema descriptions (100% coverage), and the description adds significant context: XOR relationship between code_insee and nom_commune, departement as hint only, default values for finess_familles, and examples for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool aggregates multiple health data for a French commune in one call, listing specific data sources (population, densities, FINESS, DEMANDE) and explicitly mentions it replaces 7-10 individual MCP calls, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use (single commune panorama) and when-not-to-use (Paris/Lyon/Marseille not supported, suggests individual tools at department level), explains that using 'departement' alone raises an error, and mentions alternative tool 'profil_iris' for district-level detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds beyond: data source (Annuaire santé Ameli), weekly updates, legal reuse requirements, deduplication behavior, pagination, and the optional freshness field cost. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: main purpose, then details on codes, pagination, deduplication, scope, source. Every sentence adds value, though slightly verbose; could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 1 required, output schema present, the description covers scope, source, update frequency, legal requirements, pagination, deduplication, freshness, and references other tools for code lists. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
100% schema coverage and description adds extra context for each parameter: e.g., prefers specialite_code over type_ps_code for precision, explains dedupe_by_ps lists addresses in sites[], offset pagination logic, include_freshness cost and cache.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists conventionné libéral health professionals by department with optional specialty/type filters. It uses specific verbs and distinguishes from siblings like professionnels_in_radius and mentions other tools for out-of-scope data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Pour énumération administrative — pas de rayon.' Advises when to use specialite_code vs type_ps_code, mentions lister_nomenclature for code lists, explains pagination and deduplication, and details out-of-scope categories with alternative sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond annotations: explains geo_precision types (adresse, etablissement_finess, centroide_commune) and their implications for distance accuracy, gives coverage percentages (~68.5% precise, ~31.5% centroid), details the effect of `include_etudiants` and `include_agents_publics` with percentages, and describes the source and license. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured with clear paragraphs and sections. Every sentence provides value, but it could be slightly more concise. However, given the complexity of the tool, the length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, output schema exists), the description is comprehensive. It covers return fields (geo_precision), edge cases (centroid commune), important warnings about code confusion, and the source and license. It leaves no obvious gaps for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 80%, the description adds significant meaning beyond the schema. It elaborates on `precise_only` with usage recommendations, explains `mode_exercice_codes` values (L, S, M, R, B, A) and the default category, explains `include_etudiants` and `include_agents_publics` with percentages, and clarifies `include_freshness` behavior. This compensates for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds healthcare professionals within a radius via RPPS (Annuaire Santé ANS) covering all statuses (libéraux, salariés, mixtes, remplaçants) and distinguishes it from the sibling `professionnels_in_radius` which only covers libéraux conventionnés Ameli. The verb 'trouve' and specific resource 'PS dans un rayon via RPPS' make the purpose precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: when to use this tool vs the Ameli version, when to set `precise_only` to true (recommended for short radii <3 km, intra-commune ranking), and warns against mixing ANS codes with Ameli codes. It also explains the hybrid mode and the recommendation to use `lister_nomenclature` for discovering ANS codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant context beyond annotations: pagination via truncated, geo_precision interpretation, category defaults, subpopulation opt-ins, freshness flag, and code system warnings. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very thorough but dense; uses line breaks and bullet points for structure. Slightly verbose but every sentence adds value. Could be marginally trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers output schema behaviors (geo_precision, freshness), references external nomenclature, explains all optional filters and their interactions. Complete for a complex 9-parameter tool with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Provides meaning beyond schema: explains default category 'Civil', opt-in behavior for publics/etudiants, pagination logic, and crucial distinction between ANS and Ameli codes. Schema coverage is high (78%), but description adds extra nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists all health professionals in a department via RPPS, distinguishing from sibling tool for liberal only. Verb+resource+scope are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool (all PS via RPPS) and when to prefer sibling (libéraux conventionnés via Ameli). Warns about code nomenclatures and pagination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, destructiveHint, idempotentHint, and openWorldHint are all true/false appropriately. The description adds crucial details: match_score threshold (<0.5 indicates partial homonymy), truncated flag meaning more results exist, geo_precision levels with distance implications, and a 5-minute server cache for 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear paragraphs and front-loaded with essential information. Every sentence adds value, though it is somewhat lengthy. However, given the complexity of the tool (7 parameters, multiple behavioral nuances), the length is justified and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is exhaustive given the tool's complexity. It covers purpose, parameters, scoring, precision, categories, source, and license. The output schema is implied through description of fields (match_score, truncated, geo_precision, data_freshness). The context signals indicate high parameter count and schema coverage, and the description fills all gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71%, but the description significantly enhances understanding. It clarifies that nom is mandatory, explains the departement format with examples (75, 2A, 2B, 971), details the category parameters (including relative percentages), and provides a rationale for include_freshness (optional to avoid payload bloat). This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 and typos. It gives a concrete usage example ('Dr Martin à Paris' -> nom: 'Martin', departement: '75') and distinguishes itself from siblings by focusing on name-based search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions: nom is mandatory, prenom and departement refine results, and warns about homonyms when departement is omitted. It explains the default category (Civil) and how to opt-in for agents publics and étudiants, including a reference URL. It also tells when to use the truncated flag and how to interpret geo_precision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description adds critical behavioral details: email always null, raison_sociale truncation, imagerie family returns 0, cache behavior (5min), and the perimetre field explanation. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then details each aspect. Every sentence provides necessary information without redundancy. Given the complexity (XOR logic, multiple edge cases, behavioral notes), the length is justified and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: parameters, constraints (XOR), edge cases (ambiguous commune, null email, truncated name), known limitations (imagerie), freshness feature, and references to output schema fields (perimetre). No gaps for an AI agent to misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds significant value: explains nom_commune resolution via geo.api.gouv.fr, handling of ambiguous names, XOR rules, include_freshness behavior, and the exact list of famille values. These details go far beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists FINESS establishments by family with optional departmental or commune filters. It explicitly distinguishes from radius tools ('Pas de rayon') and lists the 24 available families, making the purpose specific and differentiating from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use (enumeration of administrative zone) and when not to (e.g., for radius search, use etablissements_finess_in_radius). Explains XOR strict constraints between department, code_insee, and nom_commune, and mentions cross-check via SIREN/SIRET for legal name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the hybrid geocoding precision (77% address-level, 23% commune centroid with ~3km error), the meaning of `geo_precision`, the deduplication behavior, and the distance calculation method. It also notes data freshness and legal reuse constraints, adding significant context beyond the annotations' read/idempotent hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but efficient: it front-loads the purpose, uses clear section breaks for geocoding, codes, mult-site, distance precision, and scope. Bold formatting highlights key parameters. Every sentence adds necessary nuance; there is no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, geocoding nuances, deduplication, scope limitations), the description covers all essential aspects: edge cases (DROM, Monaco, CEDEX), data update frequency, legal reuse, and practical recommendations. It even suggests external services for road distance. The presence of an output schema further reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the description adds further meaning by explaining the semantics of `type_ps_codes` (e.g., '2' groups multiple aux professions), recommending `specialite_codes` for precise targeting, and detailing `precise_only`'s effect. It also clarifies that `dedupe_by_ps` changes the result structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb ('Recherche de') and specifies the resource ('professionnels de santé libéraux conventionnés') and scope ('dans un rayon géographique'). It distinguishes this tool from siblings like `professionnels_rpps_in_radius` by noting that it uses the Annuaire santé Ameli data source and focuses on conventionné libéral professionals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use `specialite_codes` versus `type_ps_codes`, when to enable `precise_only` (short radii, intra-commune ranking), and when to use `dedupe_by_ps`. It also states limitations (distance is haversine, not road distance) and scope exclusions, and recommends using `lister_nomenclature` for available codes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds valuable behavioral context: data sources (INSEE RP 2022, FILOSOFI 2021), geographical limitations (hors métropole/en mer), return structure (LookupResult discriminated by found), and details about the revenue median being a proxy in aggregated mode. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the purpose, then explaining the two modes, parameter constraints, data sources, and output details. Every sentence serves a purpose and adds value. Despite being long, it is concise for the complexity involved, with no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, proxy revenue, coverage limitations), the description is complete. It explains the proxy nature of revenue median, the coverage condition (FILOSOFI only for communes ≥5000 hab), output structure (LookupResult with found, mode, population, etc.), and data sources. Output schema exists, so return values are covered. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although input schema coverage is 100% with parameter descriptions, the description clarifies the relationship between parameters (e.g., exactly one of point or code_iris) and the behavior of rayon_km (optional, range 0<r≤10, triggers basin mode). It also explains the meaning of code_iris format (9 car.) and the consequences of parameter choices, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides demographic profiles at the IRIS level, with two distinct modes (single IRIS and aggregated basin). It distinguishes from the sibling tool 'population' by explicitly noting that for simple commune/department population, one should use 'population' instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: it specifies that exactly one of point (lat+lon) or code_iris must be provided, and optionally rayon_km. It explains the two modes triggered by the presence or absence of rayon_km and tells when not to use this tool ('Pour une simple population de commune/dept, utiliser `population`').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![france-data-mcp MCP server](https://glama.ai/mcp/servers/cturkieh/france-data-mcp/badges/card.svg)](https://glama.ai/mcp/servers/cturkieh/france-data-mcp)

Score Badge

Copy to your README.md:

[![france-data-mcp MCP server](https://glama.ai/mcp/servers/cturkieh/france-data-mcp/badges/score.svg)](https://glama.ai/mcp/servers/cturkieh/france-data-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cturkieh/france-data-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server