France Geodata

Fr Commune

fr_commune

Read-onlyIdempotent

French commune lookup (Etalab/INSEE commune register): INSEE code, postcodes, population, department, region, centre point and area. Look up by name or INSEE code, or pass lat+lon to find the commune containing a point. Example: "population of Lyon" -> 69123, 519,127.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "Lyon",
      "limit": 3
    },
    "name": "fr_commune"
  }
}

Input Schema

Name	Required	Description
`lat`	No	Latitude (WGS84); pair with lon to find the commune at a point.
`lon`	No	Longitude (WGS84); pair with lat.
`name`	No	Commune name, e.g. "Lyon". Returns the best matches.
`limit`	No	Max communes for a name search, 1-20 (default 5).
`insee_code`	No	5-character INSEE code, e.g. "69123" (Corsica: "2A004").

Output Schema

Name	Required	Description	Default
`count`	No
`found`	No
`source`	No
`communes`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered; the description adds the data provenance (official INSEE register) and the semantic of the lat+lon mode — point-in-polygon containment rather than nearest match. It doesn't discuss ambiguity/ranking behavior for fuzzy name matches, which is the main remaining unknown.

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?

One sentence of scope, one of invocation modes, one example — front-loaded with the resource, no filler, and every clause carries either identity, usage, or disambiguation 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?

With an output schema present, return values need no explanation, and all five parameters are described at 100% coverage. The one unaddressed case is calling with zero arguments (all parameters are optional), where the behavior — error, empty result, or listing — is unspecified.

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, but the description adds mode-combination semantics the schema only implies piecewise: name-or-code lookup versus lat+lon containment. It also frames the output fields those parameters select, which helps the agent pick the right parameter rather than just read its type.

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?

States a specific verb and resource (French commune lookup) plus the upstream register (Etalab/INSEE), and enumerates the returned fields: INSEE code, postcodes, population, department, region, centre point, area. That level of specificity lets an agent distinguish it from geo siblings like fr_buildings_near or fr_flood_zones without opening a schema.

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?

It explicitly names the three invocation modes — by name, by INSEE code, or by lat+lon point containment — and anchors them with a worked example ('population of Lyon' -> 69123, 519,127). It does not say when to prefer this over the other French-geo siblings (e.g., address-level or building-level lookups), so it stops short of full alternative routing.

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

All France Geodata 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.