Alice — Santé territoriale France Care

Analyser l'accès aux soins d'un territoire

analyze_territory

Read-onlyIdempotent

Analyse l'acces aux soins d'un territoire francais. Accepte un code postal (ex: 77300), un nom de commune (ex: Fontainebleau), ou un code INSEE prefixe (ex: insee:77186) ; sans prefixe, 5 chiffres se lisent d'abord comme un code postal. Si plusieurs communes correspondent, la reponse les liste avec la requete exacte a relancer (relancer_avec). Retourne: APL medecins generalistes et niveau d'acces rapporte a la moyenne nationale pour la commune, son intercommunalite et son departement (lecture_du_niveau, present quand la commune est dans la moyenne nationale ou au-dessus alors que son intercommunalite ou son departement est sous la moyenne, que le zonage a jour de l'ARS la classe en zone d'intervention prioritaire ou d'action complementaire, ou que son intercommunalite est une zone prioritaire du Pacte), infrastructure sante (FINESS), organisation des soins (CPTS, TDS), population active, et comparaison regionale/nationale. Retourne aussi les classements officiels de la commune (seuil DREES de commune sous-dense, zonage de l'ARS pour six professions avec date d'arrete, zone prioritaire du Pacte de lutte contre les deserts medicaux). Sources: DREES (APL, millesime 2024), FINESS (synchronise chaque jour), INSEE, ARS, ministere de la Sante.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "analyze_territory"
  }
}

Input Schema

Name	Required	Description	Default
`query`	Yes	Code postal, nom de commune, ou code INSEE prefixe (insee:77186)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 26, 2026

changedInput schema / properties / query / description

Previous value: -"Code postal, nom de commune, ou code INSEE"New value: +"Code postal, nom de commune, ou code INSEE prefixe (insee:77186)"

First observedSep 18, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations cover read-only/idempotent/non-destructive, and the description adds real behavioral depth beyond that: data sources with vintages (DREES millésime 2024, FINESS synced daily), the conditional logic behind lecture_du_niveau, and ambiguity-handling behavior. This is substantive disclosure an agent cannot get from the annotations.

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

Conciseness4/5

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

Purpose is front-loaded and input formats come before the long return inventory. The return enumeration is dense but each element is information-bearing; it could still be tightened by grouping the classification fields rather than listing them serially.

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?

There is no output schema, so the description carries the return contract — and it does so thoroughly, enumerating metrics, classifications, and sources. An agent has enough to know what it will get back and whether the tool fits.

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, but the description adds a genuine precedence rule the schema lacks: bare 5 digits are interpreted as a postal code first, and 'insee:' selects the INSEE path. That resolves real ambiguity in the single parameter.

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

Purpose4/5

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

Specific verb+resource: 'Analyse l'acces aux soins d'un territoire francais', and the return inventory (APL, FINESS, CPTS, TDS, zonage ARS) makes the scope concrete. It does not explicitly differentiate itself from siblings like compare_territories or search_health_infrastructure, so it stops short of a 5.

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

Usage Guidelines4/5

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

Explains accepted input formats with worked examples and the disambiguation path (multiple communes → relancer_avec). It gives clear context for use but names no alternatives or when-not-to-use conditions versus the sibling tools.

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

All Alice — Santé territoriale France Care tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?