The Italian MCP ecosystem in 2026: who builds what
Direct answer: Italy's MCP ecosystem in 2026 is small, alive and nearly invisible. It is not dominated by companies: the most mature projects come from communities of independent developers and, unexpectedly, from public institutions. This ecosystem's problem is not technical quality — it is discoverability: excellent servers exist, work, and nobody finds them. This is the survey, project by project, of what is there.
TL;DR
- The most mature projects in the Italian catalogue come not from companies but from communities of independent builders.
- The most solid one exposes the Chamber of Deputies budget line by line, under a dual licence (open plus commercial) that is itself a case study in civic-tech sustainability.
- There are two opposite approaches to Italian open-source legal AI: local desktop application versus web service. It is worth understanding why.
- There are public institutions in the catalogue — the most underrated fact here, which I cover separately.
- Two people independently mapped the same parliamentary data, with different choices. Neither knew about the other.
- The ecosystem's bottleneck is discoverability, not engineering: a project nobody can find costs exactly what a project that does not exist costs.
How I ran this survey
Not to write an article: for work. I was assessing which existing projects could serve OpenLegis instead of rewriting things others had already done. I started from the public, collaborative catalogue of Italian MCP servers and actually tried them, rather than just reading about them.
What follows is the state as of September 2026. On public repositories that kind of information ages fast: before adopting anything, check the last commit.
The projects that hold up
The Chamber's budget, line by line
The most mature project in the catalogue exposes the Chamber of Deputies' budget in queryable form, line by line. I tried it with real data: it works.
But the interesting part is not technical, it is the licensing model: dual licence, strong copyleft open source plus a commercial licence. Meaning: anyone can use and study it, and anyone wanting to integrate it into a closed product pays.
This deserves attention because it addresses, at least on paper, the problem that kills most Italian civic projects: they are free, so nobody funds them, so after two years they stop. Dual licensing is one of the few models that lets a civic project earn revenue without betraying openness. Whether it works in practice is another question — but it is the right question to ask.
A community, not a single developer
Behind that project is not one person: it is a community of Italian builders producing several serious projects. That detail changes how you read the ecosystem. The usual Italian civic-tech narrative is the lone hero who gives up after three years; here there is a structure that spreads the load, and that is why the projects survive.
Two opposite ways of doing open-source legal AI
The catalogue includes a legal assistant working over Italian legislative sources — Normattiva, the Akoma Ntoso and ELI standards — still early, but with a radically different architectural choice from mine.
| Dimension | Local application | Web service (OpenLegis) |
|---|---|---|
| Where data runs | On the user's computer | On central infrastructure |
| Privacy | Maximum: nothing leaves the machine | Requires trusting the operator |
| Corpus updates | User's responsibility | Centralised and continuous |
| Cost to the user | Zero after installation | Service model |
| Compute capacity | Limited by local hardware | Scalable |
| Graph of relations between norms | Hard to build and maintain | Precisely the strong point |
There is no right choice: there are two different products. Local wins on privacy and marginal cost; centralised wins when the value lies in cross-referencing different sources, which is the heart of the knowledge-graph argument. Worth saying with respect: whoever chose the local route solved a problem I sidestepped, and vice versa.
Two independent mappings of the same data
The detail that struck me most: two people independently mapped the same SPARQL endpoints of the Chamber and the Senate, with different approaches, without knowing about each other.
On one hand that is waste: the same thankless work done twice. On the other, something more interesting happened — reading the problems documented by the other project (a long list of anomalous behaviours in the engine behind that data), I found two real bugs in my own code:
- A date comparison made on unnormalised strings: I was filtering with a
YYYY-MM-DDformat against values stored without dashes. The comparison happened, but lexicographically — wrong, and silent. - A query syntax error: a double nesting of ordering operators that the engine rejected with a cryptic error code.
Both verified live against the real endpoint, before and after the fix. This is open-source collaboration with no collaboration having taken place: nobody opened an issue, nobody wrote to anybody. It was enough that the other person had documented their stumbles well.
The least relevant project, with the best README
The catalogue holds a technically marginal MCP server whose README is, by some distance, the best of the group: it explains what it does, for whom, with what limits, with examples you can copy. It deserves a mention precisely for that. In an ecosystem whose main problem is being found and being understood, writing well is a competitive advantage, not a courtesy.
The real problem: nobody knows they exist
Here I have to implicate myself, because I am the worst example.
I have a second MCP server published on PyPI for months. Working. With 24 tools implemented. Its README documented two, because the linked repository had stayed private and nobody had ever updated the public description.
It was installable by anyone in the world with one command, and invisible to everyone. I did not discover this through market analysis: I discovered it by accident, running this very survey, finding my own package in a list.
The lesson is not «do marketing». It is blunter: a product that exists and cannot be found does not, as far as the world is concerned, exist — and the cost you paid to build it is identical. In the Italian MCP ecosystem this is the dominant bottleneck: the skills are there, the surface to meet on is not.
If you want to contribute, three things needed more than a new server
- Document your stumbles. The list of a public source's strange behaviours is worth as much to whoever comes next as the code is. It found me two bugs.
- Add your project to the public catalogue. It seems obvious; it is not: most of the serious projects that exist are not in it.
- Before writing a new server, check whether someone has already mapped that source. If so, contribute there. Two independent mappings of the same endpoint are a luxury a small ecosystem cannot often afford.
FAQ
What is the Italian MCP ecosystem?
It is the set of MCP servers — services exposing data or tools to a language model in a standard format — built over Italian data: parliamentary, budgetary, legislative, scientific, geographic. It is tracked in a public, collaborative catalogue, and includes independent projects, communities and some institutions.
Is there a sustainable way to fund an open-source civic project?
The model seen in the more mature cases is dual licensing: code under a strong copyleft open licence, plus a paid commercial licence for anyone wanting to integrate it into closed products. It allows revenue without closing the project, and is one of the few alternatives to depending on grants.
Is a locally running legal assistant better than a web service?
It depends where the value sits. Local wins on privacy and marginal cost, and is preferable when documents must not leave the machine. The web service wins when value comes from cross-referencing different sources and keeping a continuously updated corpus, which is hard to do on a personal computer.
Why would two projects map the same source?
Usually because they did not know about each other: a symptom of low discoverability, not competition. The positive side effect is that the problem documentation produced by one project can fix bugs in the other, even with no direct contact.
If you are considering building on Italian public data and want to know what already exists before rewriting it, let's talk. See also what putting MCP into production means and why Italian public data is hard to use.
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.