The French state becomes machine readable through an AI layer

France’s experimental MCP server for data.gouv.fr is more than a technical connector. It signals a broader shift in how a state can expose public information in the age of AI. Rather than limiting access to web pages for humans and APIs for developers, the French open data platform is beginning to add a third interface layer: a standardized machine readable protocol through which AI agents can search datasets, inspect metadata, discover public APIs, and query part of the national open data corpus through conversation. This article explains what the Model Context Protocol is, how the official data.gouv.fr MCP server works, how users can leverage it according to the public documentation, and what its code reveals about the architectural choices behind the implementation. It then situates the server within the broader French ecosystem of datasets, dataservices, and downstream reuses, arguing that the real significance of the initiative lies not in one endpoint alone, but in the emergence of public digital infrastructure designed to remain usable across successive interface paradigms, from websites and APIs to AI mediated access.

Introduction

A great deal of public sector digitalization has followed a familiar pattern. Governments publish web portals for humans, APIs for developers, and documentation for specialists, while ordinary users remain responsible for navigating the complexity of the administrative surface on their own. The French experiment around the data.gouv.fr MCP server is interesting because it adds a new interface layer to that model: not just pages for people and endpoints for software engineers, but a structured protocol through which AI assistants can interact with public data.¹

¹ See the official announcement of the experimental MCP server on data.gouv.fr: Expérimentation autour d’un serveur MCP pour data.gouv.fr

² The official announcement states that data.gouv.fr is experimenting with an MCP server, presents the initiative as exploratory, and specifies that the server is read only at this stage: Expérimentation autour d’un serveur MCP pour data.gouv.fr

This is the real novelty of the initiative. In February 2026, data.gouv.fr announced an experimental MCP server designed to let chatbots and other AI systems interact with French public data through a standardized framework. The stated objective is exploratory and cautious: to understand what the Model Context Protocol can contribute to access to public data, while remaining attentive to its limits. At this stage, the server is read only and is meant to support exploration of open public datasets rather than any modification or publication workflow.²

That may sound like a narrow technical step, but it is more consequential than it first appears. Public data portals already contain huge quantities of information, yet scale alone does not guarantee usability. What changes here is the mode of access. Instead of requiring each AI tool to build a custom integration against the platform, data.gouv.fr is exposing a common machine readable interface that compatible assistants can use to search datasets, inspect metadata, list resources, query some data directly, and retrieve usage indicators through explicit tools. The official announcement describes this precisely as a way to facilitate the use of public data by AI chatbots without multiplying bespoke integrations.³

³ The official announcement explains that the goal is to facilitate the use of public data by AI chatbots through a standardized protocol rather than multiplying bespoke integrations: Expérimentation autour d’un serveur MCP pour data.gouv.fr

⁴ Official datasets catalog on data.gouv.fr, showing the current number of datasets: Jeux de données sur data.gouv.fr

⁵ The official announcement frames the MCP server as an experiment to facilitate access to public data by AI chatbots while remaining attentive to the limits of the approach: Expérimentation autour d’un serveur MCP pour data.gouv.fr

The importance of that design becomes even clearer when one considers the scale of the underlying catalog. The official datasets catalog on data.gouv.fr states that the platform contains 73,872 datasets, which means that the experimental MCP server is not being attached to a marginal repository, but to a very large national open data infrastructure.⁴ This matters because the value of a standardized AI facing interface rises with the size and heterogeneity of the underlying corpus. The more numerous the datasets, the greater the practical need for a machine readable access layer that can help users search, inspect, and navigate them without requiring bespoke integrations for each assistant or extensive manual browsing. The official announcement itself frames the server in exactly that spirit: as an experiment meant to facilitate the use of public data by AI chatbots through a standardized protocol, while remaining attentive to the limits of the approach.⁵

This article is therefore about more than one protocol. Its purpose is to examine a shift in public digital infrastructure. The French state, through data.gouv.fr, is not simply publishing datasets in bulk. It is beginning to expose them through a machine legible conversational interface, making a very large public data corpus directly addressable by AI agents.⁶ The article will first explain what MCP is and what it is for, then analyze the French implementation itself, and finally study the code of the public repository to understand what the server actually exposes, how users can leverage it, and what architectural choices the implementation reveals.

⁶ For the official framing of the MCP server as an experimental interface for public data access, see: Expérimentation autour d’un serveur MCP pour data.gouv.fr. For the scale of the underlying public data corpus, see the official datasets catalog: Jeux de données sur data.gouv.fr

MCP 101

To understand why the French initiative matters, one first needs a minimal understanding of MCP, the Model Context Protocol. MCP was originally introduced by Anthropic in November 2024 as an open standard for connecting AI applications to external systems, and it is now documented as an open protocol for linking language model clients to tools, data sources, and workflows.⁷ In concrete terms, it gives an AI assistant a standardized way to access data sources, call tools, and use structured workflows, instead of relying only on whatever text happened to be inside its training data or current prompt. The protocol has also been adopted well beyond Anthropic’s own ecosystem: OpenAI documents MCP support in its API, Apps SDK, and Codex tooling, while GitHub documents MCP support in GitHub Copilot and the GitHub MCP Server.⁸ Its governance has also broadened. In late 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, so that the protocol could evolve under more neutral, multi company stewardship rather than remaining tied to a single vendor.⁹ This matters because it shows that MCP is not merely a vendor specific experiment, but an increasingly accepted interaction standard across major AI platforms and a protocol now embedded in a broader open governance structure.

⁷ Official MCP introduction: Model Context Protocol Introduction

⁸ For OpenAI support, see the official documentation for MCP in the API, Apps SDK, and Codex: MCP and Connectors, MCP, Model Context Protocol. For GitHub support, see the official GitHub Copilot documentation: About Model Context Protocol (MCP), Using the GitHub MCP Server in your IDE

⁹ Anthropic announced that it was donating MCP to the Agentic AI Foundation under the Linux Foundation: Donating the Model Context Protocol and establishing the Agentic AI Foundation. The MCP project documentation also describes MCP as having grown into a multi company open standard under the Linux Foundation: Roadmap

¹⁰ Official MCP introduction explaining the purpose of a standard way to connect AI systems to tools and data sources: Model Context Protocol Introduction

At first principles level, the problem is simple. A language model can generate text, but by itself it does not inherently know how to inspect a database, search a public data catalog, call a calculator, read a local file, or interact with an external service in a disciplined way. Every such capability normally requires a custom integration. MCP exists to reduce that fragmentation. It defines a common protocol through which an AI application can connect to an external system and discover what that system makes available.¹⁰

The official introduction uses a useful analogy: MCP is like a USB C port for AI applications. Just as USB C gives many different devices a standardized way to connect, MCP gives many different AI clients a standardized way to connect to external tools and data sources. The value of the analogy is architectural. The point is not intelligence by itself. The point is interoperability. A data provider does not need to build a different bespoke connector for every AI client. Instead, it can expose one MCP server, and any compatible client can potentially use it.¹¹

¹¹ The official MCP introduction uses the USB C analogy to explain interoperability across AI applications and external systems: Model Context Protocol Introduction

¹² Official MCP specification describing architecture and use of JSON RPC 2.0: Model Context Protocol Specification

The protocol distinguishes three main roles. There is the host, which is the AI application the user is actually interacting with. There is the client, which is the connector component inside that host. And there is the server, which exposes context and capabilities to the host. The official specification says MCP uses JSON RPC 2.0 messages for this communication. So, at a very practical level, MCP is not magic. It is a structured request and response protocol that lets an AI host discover what an external system offers and then invoke those capabilities in a standardized way.¹²

For non specialists, the most important concepts are only three: tools, resources, and prompts:¹³

¹³ Overview of MCP server features in the official specification and documentation: Model Context Protocol Introduction

A tool is an action the model can invoke on an external system. The official specification describes tools as named capabilities that let models interact with outside systems, such as querying databases, calling APIs, or performing computations. A tool therefore does not merely give the model more text. It gives it the ability to do something structured in the outside world or against an external service. In the case of the French data.gouv.fr MCP server, examples of tools include searching datasets, listing dataset resources, querying tabular data, or retrieving usage metrics.¹⁴
A resource is context exposed by the server. The official specification says resources allow servers to share data that provides context to language models, such as files, database schemas, or application specific information, each identified by a URI. So if a tool is closer to a verb, a resource is closer to a document or object that can be read. Resources matter because many AI tasks are not really about taking an action, but about obtaining grounded context from an authoritative external source.¹⁵
A prompt, in MCP terminology, is a structured prompt template exposed by the server. The specification says prompts allow servers to provide reusable messages and instructions for interacting with language models, and that they are typically intended to be user controlled. In practice, prompts let a server package a recommended interaction pattern for a domain. They do not replace the model. They give it a structured starting point or workflow.¹⁶

¹⁴ Official MCP tools specification: Tools. For examples from the French implementation, see the official repository: datagouv-mcp

¹⁵ Official MCP resources specification: Resources

¹⁶ Official MCP prompts specification: Prompts

¹⁷ The official MCP documentation and specification show that the protocol covers more than tool invocation, including resources and prompts: Model Context Protocol Introduction, Resources, Prompts

This distinction is important because it shows that MCP is broader than tool calling. It can expose actions, context, and reusable interaction patterns. That is why the protocol is relevant for public digital infrastructure. A government platform may want an AI system not only to call an endpoint, but also to retrieve authoritative public information and to do so through a predictable interaction model.¹⁷

Why does this matter in practice? The official MCP documentation gives a straightforward answer. For developers, MCP reduces the effort of integrating external systems into AI applications. For AI applications, it expands what they can do by giving them access to tools and data beyond their base model. For end users, it means assistants can become more useful because they are no longer restricted to generic text generation. They can access relevant systems directly when permitted.¹⁸

¹⁸ Official MCP introduction on the value of the protocol for developers and AI applications: Model Context Protocol Introduction

¹⁹ For the official French framing of the MCP server as a standardized AI facing interface for public data, see: Expérimentation autour d’un serveur MCP pour data.gouv.fr

This is exactly the background needed to understand the French experiment. The novelty is not that France has public data. Many governments already publish large quantities of public data. The novelty is that France is starting to expose that data through an MCP server, meaning through a standardized interface designed for AI mediated access rather than only for human browsing or traditional software integration. Instead of asking each assistant vendor to invent its own connector to the French open data platform, the platform can expose a common interface once and let multiple compatible clients use it. That is the infrastructural logic behind the initiative.¹⁹

There is also an important limit. MCP does not make an AI system automatically correct, authoritative, or safe. It merely gives it a standardized way to obtain external context and invoke external capabilities. The quality of the result still depends on the design of the server, the quality of the underlying data, the behavior of the client, and the reasoning of the model itself. MCP improves connectivity and structure. It does not eliminate the need for verification. That point is especially important when the connected system is a public data platform, where the difference between access and correct interpretation remains substantial. This caution is consistent with the official architecture and specification, which define communication mechanisms and capability exposure, not epistemic guarantees about model outputs.²⁰

²⁰ The official MCP specification defines protocol structure and server capabilities, not truth guarantees about model outputs: Model Context Protocol Specification

How to use the data.gouv.fr MCP server

From the user perspective, the official data.gouv.fr MCP server is meant to be used through an MCP compatible client, not by manually sending protocol messages. The repository states this very clearly: the recommended option is to use the hosted public endpoint at https://mcp.data.gouv.fr/mcp, which is available without access restrictions, and then connect a compatible chatbot or coding assistant to it. The repository explicitly mentions clients such as Claude, ChatGPT, and Gemini, and provides configuration instructions for a larger list that also includes Cursor, Claude Desktop, Claude Code, Le Chat, VS Code, Windsurf, AnythingLLM, HuggingChat, IBM Bob, Kiro, OpenCode, and others.²¹

²¹ Official repository README for the data.gouv.fr MCP server, including hosted endpoint and supported clients: datagouv-mcp

²² Official repository README section recommending the hosted endpoint for normal use: datagouv-mcp

The first practical point is that the repository recommends the hosted endpoint rather than self hosting for ordinary usage. Its wording is direct: use the hosted endpoint https://mcp.data.gouv.fr/mcp, and only substitute your own URL if you choose to self host the server. That means the basic usage model is very simple. The user selects an MCP capable application, adds the data.gouv.fr endpoint using the configuration format expected by that application, and then starts interacting with public data through natural language.²²

The repository’s ChatGPT instructions are unusually concrete. It says the connector is available only on paid plans, specifically Plus, Pro, Team, and Enterprise. The documented path is to open Settings, then Apps and connectors, then Advanced settings to enable Developer mode, and finally return to Settings and Connectors to add a new connector whose URL is https://mcp.data.gouv.fr/mcp. Once saved, the tools become available inside ChatGPT.²³

²³ Official ChatGPT setup instructions in the repository README: datagouv-mcp

²⁴ Official client configuration examples for Cursor, VS Code, Claude Code, and Claude Desktop in the repository README: datagouv-mcp

For Cursor, the repository explains that MCP servers can be added through Cursor settings by searching for MCP or Model Context Protocol and inserting a JSON block that points to https://mcp.data.gouv.fr/mcp with HTTP transport. For VS Code, the repository gives the platform specific locations of the mcp.json file and shows a similar configuration using a servers object whose datagouv entry uses the same hosted URL. For Claude Code, the documented setup is command line based: claude mcp add --transport http datagouv https://mcp.data.gouv.fr/mcp. For Claude Desktop, the repository provides a configuration file example using npx and mcp-remote against the same endpoint, and it even documents a Windows specific troubleshooting case involving the built in Node runtime.²⁴

The repository also documents setup for clients oriented toward broader public use rather than only developer environments. For Le Chat by Mistral, it says the feature is available on all plans including free, and the steps are to go to Intelligence, then Connectors, then add a Custom MCP Connector, give it a name, set the URL to https://mcp.data.gouv.fr/mcp, leave authentication disabled, and create it. For HuggingChat, the instructions are to open the MCP server manager from the plus icon, add a server, provide the URL, and then run a health check so that the server shows as connected and the toggle can be activated for use in chat.²⁵

²⁵ Official client configuration examples for Le Chat and HuggingChat in the repository README: datagouv-mcp

²⁶ Official repository README usage examples and overview of the conversational interaction model: datagouv-mcp

Once the connector is configured, the user does not normally need to think about MCP again. The interaction becomes conversational. The repository explains the expected usage through examples such as asking what datasets are available on housing prices or asking to show the latest population data for Paris. This is an important detail: the server is not designed as a generic chat endpoint but as a structured bridge between natural language requests and the public data operations exposed by the tools.²⁶

The repository then describes the available tools. On the dataset side, the server exposes search_datasets, get_dataset_info, list_dataset_resources, get_resource_info, and query_resource_data. The repository explains each of them in operational terms. search_datasets searches datasets by keywords and returns metadata such as title, description, organization, tags, and resource count. get_dataset_info retrieves detailed information on a specific dataset. list_dataset_resources enumerates the files attached to a dataset, including metadata such as format, size, type, and URL. get_resource_info retrieves detailed information about a resource, including its MIME type, URL, dataset association, and whether the Tabular API is available. query_resource_data then queries a specific resource through the Tabular API in order to fetch rows and answer questions over the data.²⁷

²⁷ Official repository README tool descriptions for search_datasets, get_dataset_info, list_dataset_resources, get_resource_info, and query_resource_data: datagouv-mcp

²⁸ The layered workflow is inferred directly from the official tool descriptions and examples in the repository README: datagouv-mcp

This implies a practical usage sequence. A user typically begins with discovery, using search_datasets to identify datasets related to a topic. Once a promising dataset is found, the next step is inspection, using list_dataset_resources to see what files are attached and get_dataset_info or get_resource_info to understand the structure and relevance of the material. Only after that does the user move to actual data retrieval, using query_resource_data to inspect rows or answer questions grounded in a specific tabular resource. The repository’s tool descriptions strongly support this layered workflow even when it does not spell it out as a formal sequence in the same paragraph.²⁸

The server also exposes a second family of functions for dataservices, which the repository defines as external third party APIs registered in the data.gouv.fr catalog, such as Adresse API or Sirene API. This is an important distinction. Datasets are static data files, while dataservices are APIs listed in the catalog. For this second class, the server provides search_dataservices, get_dataservice_info, and get_dataservice_openapi_spec. In practical terms, that means a user can exploit the server not only to discover downloadable datasets, but also to discover relevant public APIs and inspect their documented interfaces.²⁹

²⁹ Official repository README section describing dataservices and the tools search_dataservices, get_dataservice_info, and get_dataservice_openapi_spec: datagouv-mcp

³⁰ Official repository README section documenting get_metrics and its production only availability: datagouv-mcp

A further documented capability is get_metrics. The repository says this tool returns monthly statistics including visits and downloads, sorted by month in descending order, and that at least one of dataset_id or resource_id must be provided. It also states an operational limit that matters for users and deployers alike: this tool works only against the production environment because the Metrics API does not exist in demo or preproduction.³⁰

For users who want to run the server themselves, the repository also documents local execution. It recommends Docker, with docker compose up -d as the default startup command. The documented environment variables include MCP_HOST, MCP_PORT, MCP_ENV, DATAGOUV_API_ENV, and LOG_LEVEL. The repository notes that DATAGOUV_API_ENV can target either production or demo data.gouv.fr, and that binding to 127.0.0.1 instead of 0.0.0.0 is preferable for local development from an MCP security standpoint. Once running locally, the server exposes POST /mcp for JSON RPC traffic and GET /health for a JSON health probe.³¹

³¹ Official repository README local development and Docker instructions, including environment variables and endpoints: datagouv-mcp

³² Official repository README instructions for testing with MCP Inspector: datagouv-mcp

The repository even documents how to test the server interactively with the official MCP Inspector. The stated procedure is to start the local server and then launch the inspector with npx @modelcontextprotocol/inspector --http-url "http://127.0.0.1:${MCP_PORT}/mcp". This is less relevant for ordinary end users, but it is useful for developers, public sector technologists, and researchers who want to inspect the exposed tools more explicitly rather than only through a chatbot interface.³²

So, stripped to its essentials, the official usage model is this. Connect an MCP capable client to https://mcp.data.gouv.fr/mcp. Use natural language to search for datasets or dataservices. Inspect the returned metadata and resources. Then query specific resources or inspect API specifications depending on what the catalog contains. The repository documentation makes clear that the design is intentionally practical: the goal is to let users move from a question in ordinary language to structured operations over the French national open data platform without having to manually browse the site or hand code against its APIs.³³

³³ Official repository README summarizing the practical usage model of the server: datagouv-mcp

Inside the implementation: what the French MCP server actually is

Once the user side workflow is understood, the next question is architectural. What exactly has the French team built? Is this a large autonomous agent system, a specialized reasoning engine, or merely a thin compatibility layer over existing public APIs? The code makes the answer quite clear. The official data.gouv.fr MCP server is fundamentally a protocol adapter: a relatively small service that exposes selected capabilities of the French open data platform through the Model Context Protocol, so that MCP compatible AI clients can invoke them through a standardized interface rather than through bespoke integrations.³⁴

³⁴ Official repository README describing the project as an MCP server for searching, exploring, and analyzing datasets from data.gouv.fr through conversation: datagouv-mcp

³⁵ Repository structure and project description in the official repository: datagouv-mcp

The repository structure already points in that direction. At the top level, the project has a small main.py, a tools package, helper modules, tests, Docker support, and packaging metadata. That is not the shape of a monolithic AI application. It is the shape of a bounded service whose purpose is to expose an existing platform through a clean integration layer. The repository README itself describes it in those terms: an MCP server that allows AI chatbots such as Claude, ChatGPT, and Gemini to search, explore, and analyze datasets from data.gouv.fr directly through conversation.³⁵

A small FastMCP application rather than a complex agent system

The main.py file is revealing precisely because it is so compact. It instantiates a FastMCP server named data.gouv.fr MCP server, registers the tools, wraps the MCP application in a small monitoring layer, and runs the resulting ASGI app through Uvicorn. In other words, the core server does not contain business logic about datasets itself. It contains the protocol scaffold, transport security configuration, health reporting, and observability wiring. The real application logic lives in the tool handlers.³⁶

³⁶ Official implementation entry point showing FastMCP initialization, tool registration, monitoring wrapper, and Uvicorn app startup: main.py

³⁷ The bounded protocol surface is evident from the server entry point and registered tools in the official codebase: main.py, tools/init.py

This is a strong architectural signal. The French implementation does not try to bury everything inside one opaque conversational backend. It keeps the protocol layer narrow and legible. That makes the service easier to inspect, easier to maintain, and easier to reason about. The model does not get a vague unrestricted bridge to the entire platform. It gets a bounded set of named capabilities.³⁷

Explicit tool registration rather than one monolithic endpoint

The tools/__init__.py file confirms this design. The MCP server registers a fixed set of tools: search_datasets, search_dataservices, get_dataservice_info, get_dataservice_openapi_spec, query_resource_data, get_dataset_info, list_dataset_resources, get_resource_info, and get_metrics. This is a deliberately explicit interface surface.³⁸

³⁸ Official tool registration in the repository: tools/init.py

This choice matters more than it might seem. A public facing AI integration could have been implemented as one generic operation such as ask data.gouv.fr anything. Instead, the French server decomposes the interaction into bounded operations that map to real classes of backend capability: search, metadata inspection, resource listing, row retrieval, dataservice discovery, API specification inspection, and usage metrics. That decomposition is important for three reasons.

First, it makes the interface inspectable by both developers and users. One can see what the server can and cannot do. Second, it lets the client reason over specific tool affordances rather than a vague omnipotent backend. Third, it preserves the ontology of the underlying platform. Datasets, resources, dataservices, and metrics remain distinct things rather than being collapsed into one fuzzy abstraction.³⁹

³⁹ The explicit separation of tools is documented in the repository and implemented in the official code: tools/init.py

Streamable HTTP only

The repository states that the server uses the official Python MCP SDK and supports streamable HTTP transport only. It explicitly does not support STDIO or SSE. The endpoint surface is also narrow: POST /mcp for JSON RPC traffic and GET /health for health checks.⁴⁰

⁴⁰ Official repository README documenting Streamable HTTP only transport and the /mcp and /health endpoints: datagouv-mcp

⁴¹ Transport model and endpoints documented in the official repository README: datagouv-mcp

This is a subtle but important design choice. Many early MCP examples were oriented toward local developer tooling, where STDIO based transport is natural. The French implementation instead privileges a remotely accessible HTTP service. That makes sense for a national open data portal intended to be used by many classes of client, not just local code tools. The design is therefore production oriented rather than merely demonstrative.⁴¹

Stateless HTTP as an interoperability decision

One of the most revealing technical decisions appears directly in main.py. The FastMCP instance is created with stateless_http=True. The in code comment explains the reason: to avoid Session not found errors with MCP clients that do not correctly preserve the mcp-session-id header across requests, with examples explicitly including Claude Code, Cline, and OpenAI Codex. The same comment adds that stateful sessions are unnecessary here because the server does not use server initiated notifications.⁴²

⁴² Official server code showing stateless_http=True and the compatibility comment about preserving mcp-session-id: main.py

⁴³ The design choice is visible in the official implementation and its code comments: main.py

This is not just an implementation detail. It reveals the design philosophy of the service. The server is optimized for broad client compatibility rather than for protocol features it does not currently need. In other words, the team is solving the real integration problem that exists today, not a more ambitious but fragile one. For public infrastructure, this is a sound judgment. A protocol is only useful if the clients actually interoperate with it.⁴³

Transport security is treated as part of the design, not an afterthought

The main.py file also configures TransportSecuritySettings with DNS rebinding protection enabled. It restricts allowed_hosts to the production and preproduction domains plus localhost variants, and similarly restricts allowed_origins to the corresponding HTTPS and local development origins. The code comments tie this explicitly to MCP transport security requirements, including origin validation and localhost binding guidance for local development.⁴⁴

⁴⁴ Official server code configuring TransportSecuritySettings, allowed_hosts, and allowed_origins: main.py

⁴⁵ The transport security configuration is implemented in the official server entry point: main.py

This matters because it shows that the French team is not treating MCP as a generic convenience wrapper with no protocol specific threat model. Exposing tool invocation over HTTP creates a new integration surface, and the implementation acknowledges that. The security posture here is not exhaustive, of course, but it is evidence of disciplined engineering. The server constrains where it may be called from and by whom at the transport layer, which is exactly what one would want from a public machine interface.⁴⁵

Operational observability is built in

The same file includes a custom monitoring wrapper around the MCP app. The wrapper intercepts HTTP requests, exposes a dedicated /health endpoint, and sends tracking events for MCP requests through a Matomo helper. The health response includes status, uptime_since, version, env, and data_env. Sentry initialization is also performed at startup.⁴⁶

⁴⁶ Official implementation of the monitoring wrapper, health endpoint, Matomo tracking, and Sentry initialization: main.py

⁴⁷ Operational monitoring and observability features are visible in the official server code: main.py

This is operationally significant. An experimental public MCP endpoint is still a public service. The French implementation is clearly instrumented as such. It supports health reporting, version visibility, environment introspection, analytics, and error monitoring. This is not what one usually finds in a throwaway demo. It suggests the service is being treated as a real operational component of the platform’s evolving interface layer.⁴⁷

The search layer is thin, but not naive

The search_datasets.py tool is one of the clearest examples of the server adding value beyond mere pass through exposure of the underlying API. The code explains that the data.gouv.fr search API uses strict AND logic, which means that generic words often added by users can cause searches to fail by requiring metadata terms that are unlikely to appear. To mitigate that, the server defines a query cleaning function that removes common generic terms such as données, fichier, tableau, and format names such as csv, excel, xlsx, json, and xml.⁴⁸

⁴⁸ Official dataset search tool implementation describing strict AND logic and query cleaning: search_datasets.py

⁴⁹ Official dataset search tool implementation showing cleaned query fallback behavior: search_datasets.py

This is an important design move. The MCP server is not simply replicating the raw API. It is adapting the interaction model for natural language use. Users often ask for datasets in CSV or fichier de données, but those generic words are not semantically useful for metadata retrieval if the underlying search engine treats them as hard constraints. The server therefore removes them, tries the cleaned query first, and if the cleaned version yields no result while differing from the original, it falls back to the unmodified query. That fallback behavior is also explicit in the code.⁴⁹

This is a small heuristic, but conceptually it is important. It shows what a good MCP wrapper should do. It should not merely expose an API mechanically. It should encode the friction points of the underlying platform and reduce them in a way that remains transparent and bounded.⁵⁰

⁵⁰ The search adaptation logic is documented directly in the official implementation: search_datasets.py

The tabular query tool is a controlled analytical interface

The query_resource_data.py tool is even more revealing. It does not just fetch an entire file blindly. It exposes a more structured and analysis oriented retrieval model over the Tabular API. The tool accepts a natural language question, a resource_id, pagination controls, optional filters by column and value, a restricted set of filter operators, and optional sorting controls. The supported operators listed in the code are exact, contains, less, greater, strictly_less, and strictly_greater, while sorting is restricted to asc or desc.⁵¹

⁵¹ Official tabular query tool implementation documenting accepted parameters, filter operators, and sort directions: query_resource_data.py

Several design judgments are embedded here.

The tool explicitly recommends starting with a small page_size of 20 to preview the resource structure. It clamps page_size to a range between 1 and 200. It retrieves resource metadata first, and if possible dataset metadata as well, so that the textual response can contextualize the query with the resource title and dataset title. It then builds filter and sort parameters for the Tabular API in a controlled way, rather than allowing arbitrary parameter injection.⁵²

⁵² Official tabular query tool implementation showing page_size handling, metadata retrieval, and controlled parameter construction: query_resource_data.py

⁵³ Official tabular query tool implementation showing result formatting, paging guidance, and handling of large datasets: query_resource_data.py

The result formatting is also telling. The tool reports the total row count when available, calculates total pages, lists the column names, shows the retrieved rows, truncates long field values, and, when more data exists, tells the user what to do next. For larger datasets above 1000 rows, the tool explicitly warns that the dataset is large and recommends either pagination or using get_resource_info to retrieve the raw file URL and fetch it directly.⁵³

This is not a general purpose data analysis engine. It is a controlled inspection interface. That is the right design for an MCP server over a public data portal. The goal is not to reimplement pandas inside the protocol layer. The goal is to make tabular public resources inspectable and partially queryable in a way that supports conversational exploration while remaining bounded and legible.⁵⁴

⁵⁴ The bounded analytical behavior is visible in the official tabular query tool implementation: query_resource_data.py

The implementation preserves the platform’s ontology

Another important architectural feature is that the server keeps a sharp distinction between datasets, resources, and dataservices. The repository documentation is explicit that dataservices are external APIs registered in the data.gouv.fr catalog, unlike datasets which are static files. That distinction is reflected in the separate tool families for search, inspection, and OpenAPI specification retrieval.⁵⁵

⁵⁵ Official repository documentation and code distinguish datasets from dataservices: datagouv-mcp, tools/init.py

⁵⁶ The distinct treatment of files and APIs is reflected in the official repository and code: datagouv-mcp, tools/init.py

This is conceptually correct and important. A public data file and an API are not the same kind of object. One is primarily explored through rows, structure, and downloads. The other is explored through endpoint documentation, parameters, and interaction semantics. The French implementation does not flatten these into a single undifferentiated object model. It preserves the ontology of the catalog, which makes the resulting AI interface more truthful to the underlying platform.⁵⁶

What the code says about the overall philosophy

Taken together, the code reveals a consistent design philosophy.

The first principle is thinness. The server is intentionally narrow. It exposes a selected set of operations and delegates most actual data storage and retrieval to existing platform services.⁵⁷

⁵⁷ The server’s intentionally narrow scope is visible across the official repository and codebase: datagouv-mcp

⁵⁸ Explicit named tool decomposition in the official code: tools/init.py

The second principle is explicitness. Capabilities are decomposed into named tools rather than hidden behind a single broad conversational endpoint.⁵⁸

The third principle is interoperability pragmatism. The use of stateless HTTP and the focus on a hosted endpoint show that the service is designed for real client compatibility rather than abstract protocol completeness.⁵⁹

⁵⁹ Stateless HTTP and hosted endpoint emphasis are documented in the official repository and implementation: datagouv-mcp, main.py

⁶⁰ Examples of bounded augmentation are visible in the official search and tabular query tool implementations: search_datasets.py, query_resource_data.py

The fourth principle is bounded augmentation. The server adds modest but meaningful logic, such as search query cleaning, metadata contextualization, pagination hints, filter validation, and explicit guidance for large datasets, without trying to replace the underlying data platform.⁶⁰

This is why the French MCP server is interesting. It is not technically impressive because it performs deep reasoning on its own. It is interesting because it embodies a sound architectural judgment about how a national open data platform can become AI addressable without becoming opaque, monolithic, or overly magical. It remains recognizably a public data platform. The MCP layer simply makes that platform legible to a new class of clients.⁶¹

⁶¹ The overall architectural character of the service emerges from the official repository and codebase taken together: datagouv-mcp

What the community is building on top of the platform

An open data platform is not important only because of what it publishes. It is important because of what others can build with it. This is one of the reasons the data.gouv.fr MCP experiment matters beyond protocol design. The underlying platform is not a static archive. It already sits inside a broader ecosystem of reuse, where public datasets are turned into applications, visualizations, search tools, domain specific services, and practical decision aids.⁶²

⁶² Official reuse catalog on data.gouv.fr: Réutilisations

⁶³ Official reuse catalog showing the current number of reuses and the sector taxonomy: Réutilisations

The official reuse catalog on data.gouv.fr makes this visible at a glance. At the time of consultation, the platform listed 5,115 reuses. The catalog spans a wide range of sectors, including health, transport and mobility, territorial planning and housing, food and agriculture, culture and leisure, economy and business, environment and energy, employment and training, politics and public life, security, education and research, society and demography, law and justice, and open data tools. This alone is an important signal. The value of the French open data infrastructure is not confined to one theme or one administrative department. It is generative across a wide spectrum of public and economic activity.⁶³

The official page also highlights some of the most popular reuses, and the selection is revealing because it is highly heterogeneous. Among the featured examples are the Explorateur des données de valeur foncière (DVF), an application around property transaction data, Eco Score, which concerns the environmental impact of food products, Datan, a tool for analyzing the behavior of members of the National Assembly, matchID, a search engine for deceased persons, and SupTracker. These examples show that reuse is not limited to one pattern such as dashboards or maps. The same public data infrastructure supports civic analysis, consumer information, memorial search, public accountability, and sector specific exploration tools.⁶⁴

⁶⁴ Official reuse catalog page highlighting featured reuses such as DVF, Eco Score, Datan, matchID, and SupTracker: Réutilisations

⁶⁵ Official reuse catalog page showing the current selection of the moment: Réutilisations

The page’s selection of the moment reinforces the same point. It features, among others, a map of the 2026 municipal election results, CloudSmog, and a map of political representation. The common element is not the form of the application but the conversion of raw public data into more directly interpretable public artifacts. In other words, the platform’s reuse layer is already a space where data becomes operationalized for citizens, researchers, activists, and developers.⁶⁵

The official catalog also provides a more curated clue about the kinds of practical problems these reuses address. In its use cases area, the data.gouv.fr team highlights examples such as understanding the tree heritage of municipalities, knowing the sale price of real estate assets, identifying firms in difficulty, precisely locating interventions, proposing an educational orientation path, assessing the risks attached to a property, and simplifying farm management. These are not abstract demonstrations of transparency. They are concrete transformations of public data into decision support, market intelligence, local knowledge, and administrative assistance.⁶⁶

⁶⁶ Official reuse catalog page highlighting practical use cases built on public data: Réutilisations

⁶⁷ The broader significance of the MCP layer should be read together with the existing reuse ecosystem documented on the official platform: Réutilisations, Expérimentation autour d’un serveur MCP pour data.gouv.fr

This ecosystem matters for the interpretation of the MCP server. The server itself does not create those applications. It does something more infrastructural. It changes the access layer through which AI capable systems can discover and work with the same underlying public data universe. That means MCP should not be understood as an isolated gadget placed on top of a dead catalog. It should be understood as a new machine readable interface over an already productive ecosystem of reuse. The community has already shown that the datasets can generate maps, trackers, search engines, and analytic services. The MCP layer potentially lowers the cost of discovering and interrogating that data through conversational systems. That is the broader significance of the French move.⁶⁷

There is also a governance implication here. When a platform exposes thousands of datasets and thousands of downstream reuses, the problem is no longer only publication. It becomes mediation. How does a citizen, journalist, researcher, entrepreneur, or local public actor find the right dataset, understand what it contains, distinguish between files and APIs, and move from catalog browsing to actual use? The reuse catalog shows that the French ecosystem already has strong downstream creativity. The MCP server can therefore be read as an attempt to improve the interface between that abundance of public information and the next generation of user interaction models.⁶⁸

⁶⁸ For the scale and diversity of downstream reuse on the official platform, see: Réutilisations

The French state becomes machine readable through an AI layer

Introduction

MCP 101

How to use the data.gouv.fr MCP server

Inside the implementation: what the French MCP server actually is

A small FastMCP application rather than a complex agent system

Explicit tool registration rather than one monolithic endpoint

Streamable HTTP only

Stateless HTTP as an interoperability decision

Transport security is treated as part of the design, not an afterthought

Operational observability is built in

The search layer is thin, but not naive

The tabular query tool is a controlled analytical interface

The implementation preserves the platform’s ontology

What the code says about the overall philosophy

What the community is building on top of the platform

See also longforms

Reclaiming the Namespace: EU Digital Sovereignty in the CVE Ecosystem?

A Glimpse of Agent Evolution

Beyond the Hype: What Microsoft’s Copilot Data Really Says About AI at Work

Darwin Gödel Machine: A Commentary on Novelty and Implications

Beyond Human Data: A Critical Examination of Silver & Sutton’s _Welcome to the Era of Experience_

Beyond the Urgency: A Commentary on Dario Amodei’s Vision for AI Interpretability

See also posts

France’s Linux Desktop Turn and the European Logic of Digital Sovereignty

Beyond De-Skilling: Intelligence Explosion and the End of Skill as a Stable Category

What Is a World Model?

GPT-4 Anniversary

Intervento al DABS Day 2024 - Università Ca' Foscari