Note · AI
Giving an agent access to French public land data
The short answer: AI assistants such as Claude or ChatGPT can write and reason, but they do not look up official registers on their own. Asked about a specific plot, they often answer from memory, and get it wrong with confidence. foncier-mcp gives them direct access to French public land and property data.
In practice, you ask your assistant: "Can I build on this plot, what did nearby properties sell for, is it exposed to flooding?" It fetches the answer from the land register, the sales recorded by the tax administration, the local zoning plan, energy performance certificates and the government's risk database. Every figure comes back with its source and the date it was read. When a piece of data is missing, the assistant says so instead of making it up.
What is MCP? The Model Context Protocol is an open standard that works like a universal plug for AI assistants: a service written once to this standard connects to Claude, Codex and other compatible tools, with no adaptation. foncier-mcp is such a service.
Who is it for? Anyone who wants an assistant to help them look into a plot or a home in France without spending an hour on six public websites: a buyer comparing options, a professional preparing a file, a developer building their own agent. The service is free and has been live since 12 October 2026. It informs a decision; it does not replace a notary or an official planning certificate.
The rest of this note is more technical: how the server is built, how its reliability was measured on 40 parcels, what it costs and what remains fragile.
My role, from need to deployment
I defined the need from research for my property projects, designed the architecture, developed with AI assistance, tested and deployed the service. I am responsible for its decisions and fixes; the code, evaluation cases and results are public.
The problem
An agent advising on a plot or a home in France first has to answer five questions: which parcel, what nearby properties sold for, which local zoning applies, what energy rating the building has, which risks it faces. The answers are public and free, but scattered across six government services, and a language model left to itself makes them up with confidence.
What existed before
Each source has its own website: the land registry (cadastre), the property sales records (DVF), the national zoning portal, the ADEME energy rating register (DPE), and Géorisques. A human goes through five sites and copies values by hand. The APIs exist, with no common ground: fields renamed from one service to the next, one API unreachable on the day it was read. No public MCP server brought them together with a clear rule on what the agent is allowed to state.
What was built
A Python server: seven typed, read-only tools, served locally or over HTTP with an access key.
geocode_address --------> Géoplateforme geocoder (IGN)
find_parcel ------------> API Carto cadastre (IGN)
get_parcel_sales -------> geo-dvf files (data.gouv.fr)
get_zoning -------------> API Carto GPU (national zoning portal)
get_energy_diagnostics -> ADEME, existing and new buildings
get_risks --------------> Géorisques
summarize_parcel -------> combines all six, each section independent Three choices. Every value carries its source and read date; a missing
value is a null with its reason, never an estimate. Errors
are typed: invalid input, out of coverage, source unavailable, quota exceeded. The
personal project is shared free of charge, with one key per email address and
200 calls a day, with no commercial activity.
Three refusals. No interpolated price per square metre: the tool returns recorded sales. No link to a zoning regulation while the API returns it empty: the file name is given, the link stays empty and says so. No energy rating without a street number: the tool says it does not know.
How I evaluated the service
I conducted these tests against official data and the references described below. They are reproducible, but are not an independent certification or a guarantee for all addresses.
A set of 40 public parcels across 12 départements, urban, suburban and rural: 24 with at least one sale, 14 with none, including 6 in towns with no local zoning plan, and 2 in a département that DVF does not cover. None belongs to the author or the author's family.
The expected truth comes from a different path than the server: Etalab's cadastral files for the parcel, the Géoplateforme map feed for zoning. For sales, the truth reads the same files as the server: that part measures how the data is read, not an independent register.
Measured on 11 October 2026, live against the public APIs:
| Measure | Cases | Rate |
|---|---|---|
| Geocoding, right town, within 150 m | 34 | 100% |
| Parcel found from a point | 40 | 100% |
| Parcel found from an address | 34 | 82% |
| Sales recall and precision | 31 | 100% |
| No sale returned for a parcel without sales | 14 | 100% |
| Refusal outside DVF coverage | 2 | 100% |
| Exact zone label | 33 | 100% |
| Town without a plan reported as such | 6 | 100% |
| Summary with no invention and no unsourced value | 40 | 100% |
Inventions detected: 0. Median time for a full summary: 2.2 seconds. The 6 address failures are address points that land on the neighbour's plot or on a square with no parcel: the server returns what the point says, with candidates as a warning or a reasoned absence, without guessing. The 22 recorded cases replay offline on every code change, all 40 live every week.
The first weekly run, on 12 October 2026, returned the same rates and no invention. Started from a GitHub machine with an empty cache, the summary took 4 seconds at the median there.
The first live run exposed two defects that the recorded cases, all outside the big cities, had hidden: the cadastre API codes the districts of Paris, Lyon and Marseille differently from parcel identifiers, and Géorisques ignores those of Lyon and Marseille, which left the seismic zone empty with no reason. The published rates come from the run replayed after the fix.
Limits: 40 cases, a single day; zoning truth taken at the parcel's representative point; energy ratings and risks checked only for the absence of invention.
What it cost
Initial build: one day of development with a coding agent, nothing bought. I defined the need, directed the decisions, tested the results and deployed the service. The sources are under the French Open Licence 2.0.
Running it: a serverless container at Scaleway in Paris, 256 MB, at most one instance and zero when idle. Prices read on 11 October 2026, excluding tax: €0 within the monthly free allowance; beyond it, continuous abuse for a whole month would cost about €2.30. For a few keys at 200 calls a day, the free allowance is enough.
What is still wrong or fragile
- With no persistent disk, the daily counter holds per running instance: an upper bound, not an exact count per key.
- Links to zoning regulations are empty because the API returned them empty; nothing checks that they come back.
- Reverse geocoding returns the nearest address, not the parcel's own: an energy rating can be missed.
- The rates hold for 11 October 2026. APIs change without notice, and the weekly run is the only protection.
The code and the service
- Without an MCP client: try the online demo, with a search form and three recorded conversations.
- Public repository, per-case results included: github.com/1000vario/foncier-mcp.
- Live service:
https://foncier.guillaume-couillard.com/mcp, free key on request, as described in the repository README.