datagouv-mcp: An MCP Server for Querying French Open Data in Chat
Official data.gouv.fr Model Context Protocol (MCP) server that allows AI chatbots to search, explore, and analyze datasets from the French national Open Data platform, directly through conversation.
At a glance
- What is it?
- The official Model Context Protocol server for data.gouv.fr turns a national open data portal into a tool that chatbots can call mid-conversation. The design is deliberately thin: it exposes the catalogue, not the analysis, and the hosted endpoint at mcp.data.gouv.fr/mcp is the intended way in.
- Who is it for?
- Adopt datagouv-mcp if your users ask questions about French public datasets and you want the catalogue reachable from inside a chatbot without building your own connector. Do not adopt it if you need statistical analysis over the data itself, or if you cannot send user queries to a third-party hosted endpoint.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What datagouv-mcp removes from the workflow
The problem is not that data.gouv.fr lacks data. The problem is the step before the data: knowing which dataset exists, what it is called, and where it lives. Today that step means opening a browser, typing a French-language query into a portal search box, reading result pages, and copying a URL back into whatever tool you were actually using. datagouv-mcp collapses that loop into a tool call. The README frames the goal as letting users ask questions like "Quels jeux de données sont disponibles sur les prix de l'immobilier ?" or "Montre-moi les dernières données de population pour Paris" and get answers without manually browsing the website. The audience is anyone whose chatbot needs to ground an answer in French public data: analysts, journalists, civil servants, and developers building assistants for French-speaking users. It is not a data warehouse and it is not an analytics engine. It is a discovery and exploration layer that sits in front of the portal.
The mechanism: an MCP server over streamable HTTP
The architecture is a single remote MCP server. The README describes it as a Model Context Protocol server, and the connection instructions consistently point clients at one URL, https://mcp.data.gouv.fr/mcp, using the streamable HTTP transport. Clients that speak MCP natively register that URL directly; clients that do not, such as Claude Desktop, are told to bridge through npx mcp-remote. In MCP terms the server publishes tools that the chatbot can invoke during a conversation. The README names three verbs in its description: search, explore, and analyze datasets. It does not reproduce the tool schemas, so the exact parameter names and return shapes cannot be confirmed from the supplied material. What can be confirmed is the data flow: the chatbot decides a tool call is needed, the MCP client sends it to the endpoint, the server queries data.gouv.fr, and the result returns to the model as context for the answer. There is no local index and no cached copy of the portal described in the README, which means every question reaches the live platform.
Getting a client connected, per the README
The README gives a configuration snippet for each supported client, and they are not interchangeable. For Claude Code and Autohand Code the documented command is claude mcp add --transport http datagouv https://mcp.data.gouv.fr/mcp and autohand mcp add --transport http datagouv https://mcp.data.gouv.fr/mcp respectively. For Cursor the JSON uses a url key plus "transport": "http". For Gemini CLI the key is httpUrl rather than url. For IBM Bob it is "type": "streamable-http". AnythingLLM expects "type": "streamable" inside an mcpServers object in anythingllm_mcp_servers.json. Claude Desktop is the odd one out: it needs a command and args pair invoking npx mcp-remote against the hosted URL. The README also documents a Windows-specific failure, where Claude Desktop uses a built-in Node.js runtime that cannot see packages installed with the system npm, and the fix is setting isUsingBuiltInNodeForMcp to false at the root of claude_desktop_config.json before restarting. That is a real configuration trap, and it is documented rather than hidden. ChatGPT support is noted as paid plans only, Plus, Pro, Team and Enterprise, reached through Settings, Apps and connectors, with Developer mode enabled first.
The hosted endpoint is the product, and that is the main constraint
The README states that a public instance is available at https://mcp.data.gouv.fr/mcp with no access restrictions, and recommends it over self-hosting. That choice carries consequences the README does not resolve. Every query a user types passes through an endpoint operated by the project rather than by you, which matters if the questions themselves are sensitive even when the underlying data is public. The README does not document rate limits, authentication, uptime expectations, or a data retention policy for the hosted instance, so those cannot be confirmed from the supplied material. Self-hosting is mentioned as an option ("If you self-host, swap in your own URL") but the README excerpt does not include the deployment steps, so the cost of running your own instance is unknown from what is provided. There is also a versioning signal worth reading plainly: the project reached v1.0.0 on 2026-09-04 after a long 0.2.x series, and the last push to the repository is dated 2026-09-08.
Where this is the wrong tool
The description says the server lets chatbots search, explore, and analyze datasets. The first two are discovery operations and fit the MCP pattern well. Analysis is a weaker fit. An MCP tool call returns text into a model's context window, and a national open data platform hosts datasets far larger than any context window. If a user asks for a regression across five years of commune-level records, the server can point at the dataset, but the computation has to happen somewhere else. Treat datagouv-mcp as a catalogue assistant, not a compute layer. The second limitation is linguistic and jurisdictional. The portal is French, the example queries in the README are French, and the datasets are French public data. A team whose users need UK, US, or EU-wide statistics will find the tool returns nothing useful, because the server is bound to one platform. The third is dependency on a hosted service you do not control, which is the wrong shape for air-gapped or offline environments unless self-hosting is viable for you, and the README excerpt does not establish that it is.
How it differs from calling the data.gouv.fr API directly
The obvious alternative is the data.gouv.fr public API itself, called from your own code. The difference is who decides what to fetch. With a direct API integration you write the query logic up front: you choose the endpoint, the search parameters, the pagination, and the fields you keep. The model never sees the catalogue. datagouv-mcp inverts that. The model chooses the query at runtime based on what the user asked, which is what makes open-ended questions like the README's real estate example workable without you anticipating them. The trade is control. A direct integration gives you deterministic output, testable behaviour, and no third-party endpoint in the path. datagouv-mcp gives you flexibility and a much smaller integration surface, at the cost of non-deterministic tool selection and a dependency on someone else's server. If your application has a fixed set of known datasets it needs, the direct API is the better engineering choice. If the requirement is genuinely exploratory, the MCP server earns its place.
Licence and maintenance expectations
The repository is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are retained. That is permissive and imposes no copyleft obligation on your own code. It does not, however, say anything about the hosted endpoint: an MIT licence on the source code is not a service agreement, and the README's statement of "no access restrictions" is a description of current behaviour, not a contractual commitment. If you depend on https://mcp.data.gouv.fr/mcp in production, that distinction matters. On maintenance, the release history shows a steady cadence through the 0.2.x line and a 1.0.0 cut in September 2026, with repository activity shortly after. The README also links a feedback form and references issue #69 for the Windows Node.js problem, which suggests the project is responsive to configuration bugs. For a self-hosted deployment, the maintenance surface is the Python codebase plus whatever infrastructure the (undocumented here) deployment requires; for the hosted path, maintenance is effectively zero until the endpoint changes or disappears.
Editorial conclusion
Adopt datagouv-mcp if your users ask questions about French public datasets and you want the catalogue reachable from inside a chatbot without building your own connector. Do not adopt it if you need statistical analysis over the data itself, or if you cannot send user queries to a third-party hosted endpoint. Before rolling it out, verify the current tool list from the server, confirm whether the hosted instance applies rate limits, and check that your client's MCP transport matches the streamable HTTP endpoint the README documents.
Community notes