TrustyData

Rechercher des communes

search_locality

Read-onlyIdempotent

Recherche ET liste des communes françaises. Deux usages : (1) retrouver une commune précise par nom, code postal ou code INSEE (renseigne query) ; (2) LISTER/FILTRER les communes d'un département ou d'une région, avec une fourchette de population optionnelle — query est alors inutile. Exemple : « communes du Pas-de-Calais de plus de 100 000 habitants » → department_code=["62"], population_min=100000. Préfère department_code (ex. "62") au nom ; les noms de département sont normalisés automatiquement ("Pas-de-Calais", "Val-d'Oise"… sont acceptés). Renvoie code INSEE, code postal, population et — selon le plan/details — altitude, densité, surface, département et région. Plan minimum : Discovery.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Nombre maximal de résultats (défaut 20).
`query`	No	Nom de commune, code postal ou code INSEE, complet ou partiel. Optionnel si un filtre est donné.
`details`	No	Inclure les détails de chaque commune (codes, population, coordonnées). Défaut vrai.
`postal_code`	No	Filtre : codes postaux (liste).
`region_code`	No	Filtre : codes de région (liste).
`region_name`	No	Filtre : noms de région (liste).
`population_max`	No	Filtre : population maximale (habitants).
`population_min`	No	Filtre : population minimale (habitants).
`department_code`	No	Filtre : codes de département (liste, ex. `62`, `2A`). À préférer au nom.
`department_name`	No	Filtre : noms de département (liste ; orthographe normalisée automatiquement).

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedSep 14, 2026

addedInput schema / properties / department_code / description

Added value: +"Filtre : codes de département (liste, ex. `62`, `2A`). À préférer au nom."

addedInput schema / properties / department_name / description

Added value: +"Filtre : noms de département (liste ; orthographe normalisée automatiquement)."

addedInput schema / properties / details / description

Added value: +"Inclure les détails de chaque commune (codes, population, coordonnées). Défaut vrai."

addedInput schema / properties / limit / description

Added value: +"Nombre maximal de résultats (défaut 20)."

addedInput schema / properties / population_max / description
```
Added value: +"Filtre : population maximale (habitants)."
```
addedInput schema / properties / population_min / description
```
Added value: +"Filtre : population minimale (habitants)."
```
addedInput schema / properties / postal_code / description
```
Added value: +"Filtre : codes postaux (liste)."
```

addedInput schema / properties / query / description

Added value: +"Nom de commune, code postal ou code INSEE, complet ou partiel. Optionnel si un filtre est donné."

addedInput schema / properties / region_code / description
```
Added value: +"Filtre : codes de région (liste)."
```
addedInput schema / properties / region_name / description
```
Added value: +"Filtre : noms de région (liste)."
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}

First observedJul 13, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already cover readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds further context: returned fields (code INSEE, code postal, population, and details depending on plan), automatic normalization of names, and the Discovery plan minimum requirement. This goes beyond what annotations alone provide.

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 dense but well organized: two numbered use cases, one illustrative example, a preference note, and a return-field summary. Every sentence earns its place, and the core purpose is front-loaded.

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?

For a 0-required-parameter tool with a rich schema, an output schema, and clear annotations, the description covers all important invocation aspects: input modes, filtering options, output content, and the plan requirement. An agent has enough context to select and call the tool 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 100%, so the baseline is 3. The description adds cross-parameter meaning: query is optional when a filter is present, department_code is preferred over department_name, and the population_min example clarifies combined usage. This is meaningful added value, though it does not enrich every parameter individually.

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 specific verb and resource: 'Recherche ET liste des communes françaises'. It also separates two distinct usages (precise lookup via query vs list/filter by department/region), which is especially useful for an agent distinguishing this from sibling address/company search 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 defines when to use query ('retrouver une commune précise') and when it is useless ('query est alors inutile' for listing/filtering). It gives a concrete worked example, advises preferring department_code over names, and notes automatic normalization of department names. Internal routing between the two modes is fully explicit.

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

All TrustyData 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.