The Italian State and MCP: further along than it looks
Direct answer: some Italian public institutions have already published MCP servers — the standard interface through which a language model queries external data and tools — over their own datasets. This is not conference-stage experimentation: these are public repositories, with code, letting an AI assistant query state data without scraping. The news is not that they exist: it is that almost nobody knows, not even among people building AI products in Italy.
TL;DR
- MCP (Model Context Protocol) is the standard by which a model calls external tools and data in a structured way, instead of improvising.
- The public catalogue of Italian MCP servers includes institutions, not just independent developers: AgID appears to have adopted and derived a server for CKAN open-data catalogues; INGV has an official one over its own data; there is a server over the public-data dashboard.
- The pattern matters: not «the agency buys a chatbot», but «the agency exposes its data in a format agents can read». That is the right order.
- What is missing is not technology: it is declared maintenance — who updates it, how often, with what continuity commitment.
- For builders: an institutional MCP server is the first serious alternative to scraping Italian public data, which is almost always the only route today.
What MCP is, in two lines, for non-technical readers
A language model on its own can write, not look. To answer about real data it has to query a source. MCP is the standard format in which a source describes itself to the model: these are the tools I have, these are the parameters they accept, this is what I return.
The practical difference from a traditional API is that an API is designed for a programmer reading documentation, while MCP is designed for a consumer that reasons and can get things wrong. That changes what you expose and how you describe it. It is a distinction I went into while writing about what I learned putting MCP into production.
What exists today, on the institutional side
Looking into the catalogue of Italian MCP servers — a public, collaborative list — the part I did not expect was not the independent projects. It was the public bodies.
| Area | What appears published | Why it matters |
|---|---|---|
| Open-data catalogues (CKAN) | An MCP server adopted/derived in the AgID sphere | CKAN is the de facto standard for open-data portals: one connector potentially opens hundreds of catalogues |
| Seismic and geophysical data (INGV) | An official MCP server from the institute | High-quality scientific data, already structured, with a community that actually uses it |
| Public-data dashboard | A public MCP server | Aggregate indicators, the kind of data an assistant needs to be able to cite |
A necessary caveat: this survey comes from a public catalogue consulted in September 2026, and a repository's maintenance status changes quickly. Before building anything serious on top, check the last commit and the issue tracker yourself — the advice I would give for any dependency, all the more for an institutional one.
Why the order is the right one
The version you hear most often at public-sector conferences is: the agency adopts an AI assistant for citizens. That is the wrong order, and it produces the results we know — chatbots that answer with the brochure.
What is happening here is the opposite order: the agency exposes its data in a format any agent can read, and lets others build on top. Whether that is an institutional assistant, a civic application, a newspaper's chatbot or a researcher's tool makes no difference to the agency: publish once, serve everyone.
It is exactly the open-data principle, applied to a new kind of consumer. And as with open data, the value is not in the act of publishing, but in the care over time.
What is missing for it to become infrastructure
Three things, none of them technological.
1. A declared maintenance commitment. An institutional MCP server without a line saying who maintains it and with what continuity is an implicit promise nobody made. The graveyard of Italian civic projects is full of excellent initiatives frozen five years ago; the difference between an experiment and infrastructure is entirely there.
2. Tool descriptions written for someone who does not know the domain. An MCP server is only as useful as its tool descriptions are clear, because that is what the model uses to decide what to call. Descriptions written by people who already know the data — «returns records filtered by type code» — are useless to an agent that has to work out when to use them.
3. A way for people to know they exist. This is the real bottleneck, and it is not just an institutional problem. Worth saying with an example of my own: I had an MCP server on PyPI for months, working, with 24 tools — and its README documented two, because the linked repository had stayed private. Downloadable by anyone and invisible to everyone. A product that exists and cannot be found does not, as far as the world is concerned, exist.
If you work in a public body and wonder where to start
Not with the chatbot. In order:
- Take the dataset you get the most access requests for. The one people email you about.
- Expose it with a few well-described tools, not one generic «run a query» tool. Three clear tools beat twenty parametric ones.
- Declare maintenance: who, how often, until when. Even «best effort, no guarantees» is valuable information.
- Publish where people look: the public catalogue of MCP servers, not only your institutional website.
The cost of those four steps is a fraction of an AI-assistant project, and the return is structural: every developer, journalist and researcher building on your data is, in effect, working for your mission.
FAQ
What is an MCP server?
It is a service exposing data or tools in a standard format designed to be consumed by a language model: it declares which operations it offers, with which parameters, and what it returns, so an AI assistant can use them without improvising or scraping.
How does it differ from a normal REST API?
In the consumer's nature. A REST API is designed for deterministic software following documentation; MCP is designed for a consumer that interprets, decides which tool is needed, and can be wrong. Consequently it exposes fewer operations and describes them far better.
Are there really Italian public bodies with MCP servers?
The public catalogue of Italian MCP servers lists entries attributable to AgID (CKAN open-data catalogues), INGV (institute data) and the public-data dashboard. Since these are repositories, maintenance status should be verified case by case before relying on them.
Why would a public body prefer an MCP server over a chatbot?
Because publishing data in an agent-readable format serves every use at once — assistants, civic applications, research, journalism — while a chatbot serves one channel and has to be maintained like a product. It is the difference between building a road and buying a bus.
If you work in an organisation sitting on data that deserves to be queryable by an agent, and want to understand where to actually start, let's talk. See also what it means to treat a knowledge graph as the asset rather than the visualisation.
Related articles
- PNRR contracts: five public systems that do not talkFinding out who won an Italian PNRR contract takes at least five different public databases, none of which is designed to be queried alongside the others. The technical record, source by source, from someone who actually tried.
- The worst bug does not break the feature. It breaks the view26 tools connected and working in production, the dashboard showed zero. The bug had been there for months for another product too, and nobody had seen it because whoever could notice had admin permissions.
- It knew 22,000 rulings, but not one bill numberA system holding constitutional case law since 1956 could not find a bill searched by its number. Nobody had ever tested it: it seemed too obvious to be broken.