swiss-public-data-mcp

A curated portfolio of Model Context Protocol (MCP) servers connecting AI agents to Swiss public and open data. The portfolio is maintained as an auditable inventory, not a loose list of experiments.

🇩🇪 Deutsche Version

⚠️ Disclaimer - independence of this project

This is a personal open-source project by Hayal Oezkan. It is developed in private capacity, on private time, with private infrastructure. It is not an official project of the City of Zurich, the Schulamt, the KI-Fachgruppe der Stadtverwaltung Zurich, or any other public institution. References to municipal or federal strategies are descriptive context only. They do not imply endorsement, mandate, affiliation, or production use by any institution.

Current Snapshot

Last checked: 2026-07-28

All developed MCP server repositories in this inventory have completed at least one audit, and every active server is production ready. Two repositories are archived on GitHub (read-only) and are listed separately under Legacy / Superseded so that nothing in the active tables points at a repository that no longer accepts changes.

The portfolio intentionally distinguishes core Swiss public-data servers from adjacent context servers. Adjacent servers, such as global education or technology-signal monitoring, are useful in combined workflows but are not presented as Swiss government data sources.

Every server row links to the official data portal or API it reads from. No server hosts, mirrors, or re-publishes data: each one is a thin, read-only client for a public endpoint, and the publishing organisation remains the authoritative source.

Why This Exists

The problem. opendata.swiss lists roughly 14'500 public datasets, and the broader Swiss data landscape adds GeoAdmin, Fedlex, the SNB data portal, BAFU, BFS PxWeb, swisstopo, parliamentary OData, cantonal law collections, city open-data portals, and sector-specific APIs. Every one of them speaks a different dialect — CKAN, PxWeb, SPARQL, OData, OGC, OpenDataSoft, bespoke REST. Publishing the data was the first mile. Making it usable without a developer in the loop is the last mile, and it is still missing.

The gap this closes. An AI assistant cannot browse a portal, read a schema, and guess a query. It needs a small, typed, documented interface per source. This portfolio provides exactly that: each server turns one public-data source, or one coherent source family, into MCP tools that clients such as Claude Desktop, VS Code + Continue, Cursor, Windsurf, or custom agents can call directly. Nothing is copied or re-hosted — every server is a thin, read-only client, and the publishing organisation stays the authoritative source.

Who it is for. Public administrations evaluating what open data can do inside an AI assistant; journalists and researchers who need to cross-reference official sources; civic-tech developers who would otherwise write the same API client for the fifth time; and anyone who wants to ask a question in plain language instead of assembling four API calls by hand.

What that looks like in practice. Ask "Which school buildings in the City of Zurich lack fibre, how many pupils does each Schulkreis carry, and what does cantonal law require?" — one question that touches Open Data Zurich, cantonal education statistics, and the Zurich law collection. Without MCP that is three integrations and an afternoon. With it, three servers answer in one conversation, each citing its official source.

Why a portfolio rather than one server. The value compounds when sources combine: transport plus road mobility enables multimodal routing; statistics plus geodata enables spatial analysis; education plus law plus parliamentary data supports policy research. A single monolithic server could not be audited, versioned, or adopted piecemeal — 42 small ones can.

Zurich Focus

The City and Canton of Zurich are the portfolio's deepest coverage, and the reason it started: the original question was what municipal open data can actually do inside an AI assistant. Three servers read directly from the official Zurich portals.

Beyond these, Open Data Zurich datasets also surface through swiss-statistics-mcp, swiss-housing-mcp, and swiss-electricity-mcp (ewz tariffs). See the School-infrastructure audit scenario for a worked example combining all of them.

Public-Sector Strategy Context

The portfolio was built bottom-up from integration needs, not top-down from a strategy document. Still, its design maps cleanly to public-sector digital agendas:

These links are context, not authority. The repository remains a private open-source project.

Quality & Audit Tooling

The audit methodology is now linked to the public mcp-audit-skill repository instead of being described as an internal-only catalogue. It is complemented by mcp-continuous-auditor, which runs continuous CI audits against MCP servers using promptfoo as a deterministic source of truth. The skill currently documents 120 checks across twelve categories, on a dual spec baseline (2025-11-25 and 2026-07-28):

The audit skill is not a vulnerability scanner and not a compliance certificate. It is a reproducible review method. Architecture judgement remains human.

Audit Gate

The portfolio now separates server maturity from audit evidence:

Every active server row links to the corresponding GitHub audit directory in the Audit column. Most repositories use audits/; swiss-culture-mcp uses audit/, and bag-epl-mcp plus swiss-food-safety-mcp use docs/audit/. The two archived repositories are listed separately under Legacy / Superseded; their audit evidence stays public but is frozen with the repository.

Every published audit should include metadata like this:

audit:
  server: swiss-transport-mcp
  repo: https://github.com/malkreide/swiss-transport-mcp
  audited_commit: "<commit-sha>"
  audit_skill: https://github.com/malkreide/mcp-audit-skill
  audit_skill_version: "3.0.0"
  catalogue_checks: 120
  mcp_spec_version: "2026-07-28"        # 2025-11-25 | 2026-07-28
  profile:
    transport: "dual"                   # stdio-only | dual | HTTP/SSE
    sdk_language: "Python"              # Python | TypeScript
    auth_model: "none"                  # none | API-Key | OAuth-Proxy
    data_class: "Public Open Data"      # Public Open Data | Verwaltungsdaten | PII
    write_capable: false
    deployment: ["local-stdio", "Railway"]
  gate: "no critical/high findings open"
  audited_at: "YYYY-MM-DD"

Startup Behaviour

Of the 42 published servers, 27 announce reaching serving state with a stable line on stderr. For those, a tool can tell whether an installed artefact really comes up. For the remaining 15 it cannot — a probe can only report that they did not crash, which is a weaker claim than it looks: zh-education-mcp 0.2.4 did crash, on every transport, and the published package stayed broken for months because nothing ever started it.

Not measured, and listed so the count above cannot be mistaken for the whole portfolio: MCP-Server-for-patent-research- (publishes no package), swiss-geodata-mcp (archived).

Server Portfolio

Status legend: ✅ Production ready and audited at least once · 🔐 Requires API credentials · 🧭 Adjacent/context source · 🗄️ Legacy, archived on GitHub, or superseded

🚆 Transport & Mobility

⚡ Energy & Infrastructure

🌿 Environment & Climate

⚖️ Legal, Courts & Regulatory

🧩 Semantics, Metadata & Interoperability

📊 Statistics & Geodata

🎓 Education & Research

💰 Economics & Finance

🎭 Culture & Media

🏥 Health

🍽️ Food Safety

🗳️ Democracy & Transparency

🛰️ Tech Intelligence

🗄️ Legacy / Superseded

Architecture Principles

No-Auth-First - Phase 1 of every core server should use only open, unauthenticated endpoints. Authenticated APIs can be added later with graceful degradation.

Phase architecture - Server READMEs should distinguish Phase 1 no-auth, Phase 2 authenticated/advanced, and Phase 3 production hardening.

Dual transport - Servers should support stdio for local clients and Streamable HTTP for cloud or gateway deployment when appropriate.

Standard stack - Python servers use FastMCP, Pydantic v2, httpx, hatchling, src/ layout, pytest with @pytest.mark.live isolation, GitHub Actions CI for Python 3.11-3.13, and uvx-ready packaging where possible.

Bilingual documentation - Core servers should keep README.md and README.de.md cross-linked.

Audit-driven quality - Production-ready status requires at least one completed audit. Active server rows link directly to their audit evidence directory.

Quickstart

Each server is independently installable via uvx or pip if published. See the individual server README for exact package names and configuration.

Example: add swiss-transport-mcp to Claude Desktop:

{
  "mcpServers": {
    "swiss-transport": {
      "command": "uvx",
      "args": ["swiss-transport-mcp"]
    }
  }
}

For servers not yet on PyPI:

git clone https://github.com/malkreide/<server-name>
cd <server-name>
uv run mcp dev src/<package>/server.py

Combination Scenarios

Repository Map

All active servers should carry the GitHub topic swiss-public-data-mcp. The machine-readable inventory in portfolio.json is the canonical list.

malkreide/
├── swiss-public-data-mcp                 ← this index
├── mcp-audit-skill                       ← audit tooling, not a server
├── mcp-continuous-auditor                ← audit tooling, not a server
│
├── Transport & Mobility
│   ├── swiss-transport-mcp
│   ├── swiss-road-mobility-mcp
│   └── sbb-opendata-mcp
│
├── Energy & Infrastructure
│   ├── swiss-energy-mcp
│   └── swiss-electricity-mcp
│
├── Environment & Climate
│   ├── swiss-environment-mcp
│   ├── wsl-envidat-mcp
│   └── meteoswiss-mcp
│
├── Legal, Courts & Regulatory
│   ├── fedlex-mcp
│   ├── openlex-mcp
│   ├── swiss-courts-mcp
│   ├── register-mcp
│   ├── amtsblatt-mcp
│   ├── swiss-procurement-mcp
│   └── swiss-ip-mcp
│
├── Semantics, Metadata & Interoperability
│   ├── termdat-mcp
│   ├── i14y-mcp
│   └── lindas-mcp
│
├── Statistics & Geodata
│   ├── swiss-statistics-mcp
│   ├── zurich-opendata-mcp
│   ├── swisstopo-mcp
│   └── swiss-housing-mcp
│
├── Education & Research
│   ├── global-education-mcp
│   ├── zh-education-mcp
│   ├── swiss-academic-libraries-mcp
│   ├── eth-library-mcp
│   └── swiss-holidays-mcp
│
├── Economics & Finance
│   ├── swiss-snb-mcp
│   ├── swiss-efv-mcp
│   └── seco-labor-mcp
│
├── Culture & Media
│   ├── swiss-culture-mcp
│   ├── swiss-cultural-heritage-mcp
│   ├── bakom-mcp
│   ├── srgssr-mcp
│   └── news-monitor-mcp
│
├── Health
│   ├── bag-health-mcp
│   └── bag-epl-mcp
│
├── Food Safety
│   └── swiss-food-safety-mcp
│
├── Democracy & Transparency
│   ├── swiss-democracy-mcp
│   ├── parlament-mcp
│   └── lobbywatch-mcp
│
├── Tech Intelligence
│   └── hn-tech-signal-mcp
│
└── Legacy / Superseded
    ├── swiss-geodata-mcp                     ← 🗄️ archived on GitHub (read-only)
    └── MCP-Server-for-patent-research-       ← 🗄️ archived on GitHub (read-only)

Maintenance Roadmap

The previous roadmap items for Zurich cantonal law, Swiss courts, and deeper swisstopo geodata have moved from roadmap to inventory because openlex-mcp, swiss-courts-mcp, and swisstopo-mcp now exist.

swiss-geodata-mcp and MCP-Server-for-patent-research- were archived on GitHub and moved out of the active inventory; swisstopo-mcp and swiss-ip-mcp are their respective successors.

Current portfolio maintenance priorities:

• Keep all linked audit directories current with report metadata, findings, and remediation notes.
• Migrate the archived repositories' audit evidence into their successors (swisstopo-mcp, swiss-ip-mcp) so the frozen reports do not become the only record.
• Keep every server repository carrying the required discovery topic swiss-public-data-mcp, and keep LICENSE files as unmodified licence templates so GitHub can classify them — appending notices to LICENSE silently turns a repository into NOASSERTION. Data-source notices belong in NOTICE.md.
• Align mcp-audit-skill and all future reports with MCP spec 2025-11-25, while retaining older spec versions in report metadata where applicable.
• Decide whether parlament-mcp remains a specialised server or is folded into swiss-democracy-mcp.
• All data-driven README regions — the Zurich spotlight, the Server Portfolio tables and the Repository Map — are generated from portfolio.json by scripts/generate_readme.py; a CI check (--check) blocks drift, including a server that is still listed as active after its repository has been archived.

Contributing

Bug reports and feature requests are welcome on the individual server repositories. If you build a new MCP server for Swiss open data and would like it listed here, open an issue with a short description, a repository link, data-source notes, and the intended audit profile.

When changing the inventory, edit portfolio.json and run python scripts/generate_readme.py to refresh the generated README sections. CI verifies the READMEs stay in sync via python scripts/generate_readme.py --check.

See CONTRIBUTING.md for the full contribution guide and SECURITY.md for how to report vulnerabilities.

License

MIT License - see LICENSE

Author

Hayal Oezkan · github.com/malkreide

Reminder: this is a private open-source project. Affiliations mentioned in the author's other public profiles are not relevant to this repository.