swiss-public-data-mcp

<p align="center"> <img src="docs/showcase-card.png" width="820" alt="swiss-public-data-mcp — 42 servers that let AI assistants query official Swiss open data. 42 servers, 41 data sources, 13 domains, 100% audited."> </p>

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

| Metric | Current value | |---|---:| | Active portfolio servers | 42 | | Production-ready active servers | 42 | | MCP server repos with at least one audit | 44 | | Legacy / archived MCP server repos | 2 | | Audit tooling repos | 2 | | opendata.swiss datasets | 14'551 via package_search?rows=0 | | Machine-readable source of truth | portfolio.json | | MCP Registry entries (generated) | registry/ | | Publishing runbook | RUNBOOK.md | | Promotion & distribution | PROMOTION.md | | Client install snippets | docs/INSTALL.md | | opendata.swiss showcase submission | docs/SHOWCASE.md | | Fixture provenance inventory (snapshot, 2026-08-07) | docs/FIXTURE-PROVENANCE-2026-08-07.md | | Required discovery topic | swiss-public-data-mcp | | Current MCP spec baseline for new audits | 2025-11-25 |

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.

<!-- BEGIN GENERATED: zurich-spotlight -->

| Server | Official data portal | What it covers | |---|---|---| | zurich-opendata-mcp | Open Data Zurich | City of Zurich weather, air quality, parking, geodata, Gemeinderat, tourism | | zh-education-mcp | Canton Zurich education statistics | Canton and City of Zurich education data: schools, statistics, infrastructure | | openlex-mcp | Zurich cantonal law (ZH-Lex) | Canton Zurich legislation via ZH-Lex with full-text search and article extraction |

<!-- END GENERATED: zurich-spotlight -->

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:

| Strategy | Portfolio contribution | |---|---| | Strategien Zurich 2040 | Turns "published open data" into "agent-usable open data" through reusable MCP interfaces. | | Digitalisierungsstrategie Stadt Zurich 2024 | Supports user-focused digital services, information sharing, and responsible data use without rebuilding existing APIs. | | SB021 - Strategy for AI systems in the Federal Administration | Provides a public, readable competence-building artefact with explicit audit and risk methodology. | | Digital Switzerland Strategy 2026 | Extends the practical value of public digital infrastructure by making data sources LLM-consumable through a common protocol. |

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):

| Category | Coverage | |---|---| | ARCH | Tool design, annotations, idempotency, repo structure, spec-version alignment | | SDK | FastMCP / TypeScript / Zod / lifecycle | | SEC | OAuth proxy risks, confused-deputy risks, SSRF, session hijacking, prompt-injection surface, secret handling | | SCALE | Transport, statelessness, containerisation, load balancing, gateway compatibility | | OBS | Logging, errors, SIEM, tracing, trace correlation | | HITL | Sampling and human-in-the-loop behaviour | | CH | Swiss DSG / EDOB / public-sector compliance considerations | | OPS | Test strategy, documentation, phase architecture, release hygiene | | FID | Data fidelity: scope defaults, recall against ground truth, empty results, query syntax | | IDENT | Identity: user agent, __version__, manifest and documented version, release gap, artefact health | | DRIFT | Upstream contract and repo prose: endpoint drift, fallback semantics, test quality, CHANGELOG vs code | | DEP | Resolution space of the published artefact: upper bounds, major upgrades |

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:

| Field | Meaning | |---|---| | Status | Runtime/documentation maturity of the server. | | Audit | Published evidence for the audit gate. |

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