io.github.malkreide由 GitHub 账号 malkreide 发布v0.5.1更新于 Nov 1, 2026
Swiss federal geodata: geocoding, height, STAC, WMTS, OEREB and more
面向瑞士联邦地理数据的本地 MCP 服务器：地理编码、高程、地图图层、地籍 ÖREB 摘录、STAC 数据下载与行政区查询。
Desktop only，通过 STDIO。 STDIO 服务会启动本地进程，因此需要 SourceWeft 桌面宿主。
参照 仓库 中的启动说明。
🇨🇭 Part of the Swiss Public Data MCP Portfolio
[Version] [License: MIT] [Python 3.11+] [MCP] [No Auth Required] [CI]
MCP server for Swiss federal geodata -- maps, elevation, geocoding, cadastral extracts, and downloadable datasets via Swisstopo APIs
swisstopo-mcp gives AI assistants access to Switzerland's official geodata infrastructure through 20 tools, all without authentication:
Anchor demo query: "Which communes are in the Uster district, and what are their BFS numbers for joining with BFS statistics data?"
(The BFS commune number is the official join key to swiss-statistics-mcp and zurich-opendata-mcp — this is what turns a geodata wrapper into a semantic connector at the commune level.)
→ More use cases by audience →
[Demo: Claude using swisstopo_find_commune and swisstopo_lookup_postal_code]
Or with uvx (no permanent installation):
Try it immediately in Claude Desktop:
"Where is Bahnhofstrasse 1, Zurich? Give me the coordinates." "What is the elevation at the Uetliberg summit?" "What buildings are at coordinates 2683500, 1247500 (LV95)?"
Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
Or with uvx:
Config file locations:
~/Library/Application Support/Claude/claude_desktop_config.json%APPDATA%\Claude\claude_desktop_config.jsonFor use via claude.ai in the browser (e.g. on managed workstations without local software):
Render.com (recommended):
python -m swisstopo_mcp.server --http --port 8000https://your-app.onrender.com/sseswisstopo_map_query operationsArguments belonging to a different operation are rejected, not ignored — the
error names the ones the chosen operation accepts. Silently dropping a
misplaced search_field would return a plausible answer to a question nobody
asked, which is the failure mode the whole envelope design is against.
One façade over several map/layer sources, kept under the 25-tool budget (see
docs/geodaten-erweiterung-phase1.md):
The amtliche address hierarchy PLZ → commune → district → canton, served by
the OpenPLZ API (data: BFS municipal directory +
swisstopo street directory, Swiss OGD — a separate source and licence from
the swisstopo geodata above). Every commune-bearing response exposes
bfs_commune_number as a named top-level field: the official join key to
BFS statistics (swiss-statistics-mcp) and zurich-opendata-mcp.
The full security policy and posture is documented in SECURITY.md.
This server is in Phase 2.5 — Consolidation of swiss-geodata-mcp
(see docs/roadmap.md, the single authority for phase state).
A phase advance requires: the phase's roadmap items checked off, a re-run audit
with no open critical findings, and a CHANGELOG entry naming the new phase.
Phase 3 (write tools) additionally requires re-running the Lethal-Trifecta
assessment and a security review before any implementation starts.
20 tools against a self-imposed budget of 25. The check's ideal is ≤12, so the count still needs an argument, not just a number. Per cluster:
The five api3 tools are merged (0.4.1, breaking). search_layers,
layer_info, identify_features, find_features and get_feature are now
operation values on swisstopo_map_query. They were the textbook
one-tool-per-REST-endpoint mapping the check names, and they are gone as such.
Earlier releases argued the opposite here, and the argument is worth keeping visible because it was not wrong so much as outweighed: merging relocates the decision from tool selection into schema navigation, where a model has less help, because tool descriptions are what it actually reads. Three things address that directly rather than hoping it does not matter:
identify and
find are ESRI vocabulary — they say which MapServer route is called, not
what is being asked, and nobody without ArcGIS experience can tell them apart.
features_at_point and features_by_attribute can be picked correctly from
the operation list alone.note hints from ARCH-003 still name the next step, now as
operations rather than tool names — an empty attribute search points at
operation='layer_info' for the valid field names, and so on.Observability was the other cost, and it is not paid: each operation keeps its
own log and trace label (swisstopo_map_query:features_at_point), so per-operation
timing and error rates survive the merge.
The two pairs that stay separate, both named by the audit:
geocode + reverse_geocode do hit the same SearchServer endpoint, so on the
API axis this is a 1:1 mapping twice over. They stay separate on the axis that
matters for tool selection: "address → coordinates" and "coordinates →
address" are different questions with different input types, and collapsing
them into one tool with a mode would make the model choose a variant instead
of a tool. Sharing an endpoint is an implementation detail of the upstream.search_geodata → get_collection is a genuine search → detail pair over
STAC; see below.The naming ambiguity is resolved, which the audit did not raise but the
previous version of this section recorded for "the next breaking release" — this
is it. swisstopo_search_layers and swisstopo_list_available_layers both said
"layers" while fronting different catalogues. The first is now
swisstopo_map_query with operation='search_layers', which puts the national
catalogue in the tool name and leaves list_available_layers unambiguously the
consolidated façade.
Search → detail pairs. search_geodata → get_collection is a genuine
pair: STAC collection metadata is large and callers usually want one of many
search hits. get_egrid → get_oereb_extract was the same shape and has been
collapsed: swisstopo_oereb_at answers the actual question in one call and
resolves the EGRID internally, because the EGRID is an upstream identifier
rather than something a caller asked for. get_egrid remains for callers who
want the parcel ID itself.
Genuine aggregation already in place. query_geodata fronts three sources
behind one tool; zoning_at and municipality_at each collapse a discovery
chain that previously took two calls.
When the next source is added, the choice is a raise or a consolidation.
With the api3 five merged there is no obvious consolidation left holding
headroom, so the next surface growth is a real conversation about the ceiling
rather than a deferred cleanup. tests/test_tool_namespace.py::TestToolBudget
is where that conversation is forced: raising the budget means editing the
number there and in both READMEs.
Every response carries source and license. ARE is a different federal
office from swisstopo, so its licence is asserted rather than inherited.
ch.are.bauzonen is a federal synthesis for cross-cantonal comparability and
is not legally binding — only the cantonal or communal Nutzungsplanung is.
That caveat is carried on every swisstopo_zoning_at result record.
The tool modules sit flat under src/swisstopo_mcp/ rather than in a tools/
sub-package. Each module maps to exactly one upstream API family —
rest_api.py → api3 MapServer, stac.py → STAC, oereb.py → cantonal ÖREB,
openplz.py → OpenPLZ, overpass.py → OSM, coords.py → REFRAME — which is
the axis along which this server's code actually varies. A tools/ level would
add a directory without adding a distinction.
server.py contains tool registrations only; every tool body lives in its
domain module. Splitting it further is a readability question, not a structural
one.
Trifecta score: at most 1 of 3 — safe by design.
Outbound requests are restricted to an explicit code-layer allow-list and redirects are disabled — see docs/network-egress.md.
For containerised HTTP deployments, a hardened Dockerfile and Kubernetes
manifests (non-root, read-only root filesystem, dropped capabilities, egress
NetworkPolicy) are provided — see docs/deployment.md.
The server speaks 2026-07-28 natively and keeps every older revision reachable. Which one you get is decided by how you connect, not by configuration — one process serves both eras at once.
A 2026-07-28 request is a self-contained POST to /mcp:
The MCP-Protocol-Version header is what routes the request to the modern
path; without it the same body lands on the handshake transport. Mcp-Method
and Mcp-Name must agree with the body, or the request is rejected with
-32020. All three are in the CORS allow-list so a browser client's preflight
passes.
What this means in practice:
2025-06-18 still
gets 2025-06-18; one asking over initialize for 2026-07-28 gets the
handshake ceiling 2025-11-25 back. Measured, not assumed —
tests/test_protocol_version.py.tests/test_modern_protocol.py).Neither revision is author-settable: the SDK negotiates the handshake era and
routes the modern one, and pyproject.toml pins mcp to the 2.x major so an
update cannot move either silently. tests/test_protocol_version.py pins both
ceilings and fails if a Dependabot bump changes one.
Update policy
### Changed, naming the old and the new
version.The server is unauthenticated by design — it serves only public open data.
Sessions exist in the handshake era only. There, session IDs are managed
entirely by the MCP SDK; there is no per-user state, so there is nothing
user-specific to bind a session to. Idle sessions are reaped after
SWISSTOPO_SESSION_IDLE_TIMEOUT seconds (default 1800) so a client that
disconnects without sending DELETE /mcp does not leak one for the lifetime of
the process. A 2026-07-28 request opens no session at all, so neither the
timeout nor the reaper applies to it.
If an authenticated deployment is ever introduced, session IDs must be bound to the validated user identity (audit finding SEC-009).
ToolResponse with is_error: true and a user-friendly summary; unexpected
exception text is masked and logged to stderr instead. No upstream body or
internal configuration is forwarded: Overpass error pages are classified
against a fixed signature table, and an egress refusal returns a fixed message
rather than the allow-list (OBS-002).isError flag set — not as
JSON-RPC error objects. Verified against mcp 1.28.1 by runtime probe; an
earlier version of this section claimed -32602 and was wrong. Input
validation happens at the Pydantic boundary (SEC-018).isError flag and the payload field is_error, so a client can branch on
either. The envelope — including source and license — survives on the
error path (OBS-001).Tools are the surface, and almost all of it: every result is a live, parameterised API query rather than a static addressable document.
One Resource — swisstopo://catalogue/layers — serves the façade layer
catalogue. It is the one thing here that behaves like a document: deterministic,
idempotent, and already served with provenance: "cached". swisstopo_list_available_layers
remains for filtered queries; the resource is for a client that wants the
catalogue itself, addressably.
Two Prompts encode the workflows below, including the precedence rule for point questions. That rule lives in the tool descriptions and in the server instructions too, but a prompt is the one place a model reads it as guidance rather than as one of 24 descriptions (audit ARCH-007/ARCH-008):
Most tools return a thought-complete result in a single call. Two domains use a short, documented discovery chain (each tool's description states the next step):
swisstopo_map_query with a different
operation: search_layers (find layer IDs) → layer_info (see the queryable
fields) → features_at_point / features_by_attribute → feature_by_id
(full detail).swisstopo_geocode → swisstopo_oereb_at (one call: coordinates
→ EGRID → extract). Use swisstopo_get_egrid → swisstopo_get_oereb_extract
only when the parcel ID itself is wanted.swisstopo_search_geodata → swisstopo_get_collection.Every tool returns a structured ToolResponse (FastMCP emits it as structured
content with an output schema, plus a JSON text block):
The OpenPLZ endpoints were probed live before implementation. Findings baked into the tools:
The abbreviation-vs-key trap in one line: an empty OpenPLZ list is almost never proof that something does not exist — it usually means a wrong path parameter (an abbreviation where a numeric key was expected). The tools resolve abbreviations server-side and annotate every empty result.
See CHANGELOG.md
See CONTRIBUTING.md
Read-only, no authentication, public geodata only. See SECURITY.md (Deutsch) for the security posture and how to report a vulnerability.
MIT License -- see LICENSE
Data provided by swisstopo under Open Government Data terms.
Hayal Oezkan · malkreide
Run via uv's uvx — no clone or manual install needed. Add to your MCP client config (mcpServers for Claude Desktop, Cursor and Windsurf; use a top-level servers key for VS Code in .vscode/mcp.json):
来源：README.md，提交 c1efaa0
Adresse geocodieren
Wandelt eine Adresse, einen Ortsnamen oder eine PLZ in Koordinaten um (Geocoding). <use_case>Startpunkt für ortsbezogene Abfragen: Adresse → Koordinaten, die danach an swisstopo_get_height, swisstopo_map_query (operation='features_at_point') oder swisstopo_get_egrid übergeben werden.</use_case>
params必填Koordinaten zu Adresse
Findet die nächstgelegene Adresse zu gegebenen WGS84-Koordinaten (Reverse Geocoding). <use_case>Koordinaten aus Karte oder GPS in eine lesbare Adresse auflösen.</use_case>
params必填Nationaler Kartenkatalog: Layer und Features
Fragt den nationalen Swisstopo-Kartenkatalog ab (500+ Layer): Layer finden, Felder ansehen, Features abfragen. <use_case>Der übliche Ablauf ist eine Kette: operation='search_layers' liefert Layer-IDs, operation='layer_info' zeigt deren abfragbare Felder, danach operation='features_at_point' (räumlich) oder 'features_by_attribute' (nach Attributwert), und operation='feature_by_id' holt ein einzelnes Feature vollständig.</use_case> <important_notes>Genau eine operation pro Aufruf. Felder, die zu einer anderen operation gehören, werden abgelehnt statt ignoriert — die Fehlermeldung nennt die zulässigen.</important_notes> <important_notes>Für Bauzone bzw. Gemeinde gibt es direkte Tools (swisstopo_zoning_at, swisstopo_municipality_at). 'features_at_point' nur nutzen, wenn zusätzliche Rohattribute gebraucht werden oder ein anderer Layer gefragt ist.</important_notes> <important_notes>Das ist der nationale Katalog von api3.geo.admin.ch. Für interkantonale und kantonale Quellen ist swisstopo_list_available_layers → swisstopo_query_geodata zuständig, für herunterladbare Datensätze swisstopo_search_geodata.</important_notes>
params必填Geodaten suchen
Durchsucht den STAC-Katalog nach herunterladbaren Geodaten. <use_case>Findet Orthophotos, Höhenmodelle (swissALTI3D), 3D-Gebäude und historische Karten zum Download.</use_case> <important_notes>Liefert Collections/Metadaten; Download-Links via swisstopo_get_collection.</important_notes>
params必填Geodaten-Details abrufen
Ruft Detailinformationen und Download-Links einer STAC-Collection ab. <use_case>Zweiter Schritt nach swisstopo_search_geodata, um Assets/Download-URLs einer Collection zu erhalten.</use_case>
params必填Karten-URL generieren
Generiert eine teilbare map.geo.admin.ch-URL zum Öffnen im Browser. <use_case>Einen Kartenausschnitt mit optionalen Layern als Link bereitstellen (kein Datenabruf).</use_case>
params必填Höhe abfragen
Gibt die Höhe über Meer (m ü. M.) an einer Koordinate zurück. <use_case>Punkthöhe für eine Adresse/Koordinate; für Linien siehe swisstopo_elevation_profile.</use_case> <important_notes>Koordinaten entweder als lat/lon (WGS84) ODER als easting/northing (LV95) angeben — nicht beides.</important_notes>
params必填Höhenprofil berechnen
Berechnet ein Höhenprofil entlang einer Linie aus mehreren Koordinatenpaaren. <use_case>Höhenverlauf z.B. für Wander-/Schulweg-Analysen.</use_case> <important_notes>Benötigt ≥2 Koordinatenpaare. Standard ist WGS84 ('lat1,lon1;lat2,lon2;…'); für LV95 coordinate_system='lv95' setzen und die Paare als 'easting,northing' übergeben.</important_notes>
params必填Bauzone an Koordinate
Gibt die harmonisierte Bauzone an einer Koordinate zurück (ch.are.bauzonen, ARE). <use_case>«Welche Bauzone gilt hier?» in einem Aufruf — ohne vorher die Layer-ID via swisstopo_map_query erst suchen zu müssen.</use_case> <important_notes>Der harmonisierte ARE-Layer ist eine Synthese für die schweizweite Vergleichbarkeit und NICHT rechtsverbindlich — verbindlich ist allein die kantonale/kommunale Nutzungsplanung. Der Hinweis steht in jedem Resultat. Koordinaten als lat/lon (WGS84) oder easting/northing (LV95).</important_notes>
params必填Gemeinde an Koordinate
Gibt Gemeinde, BFS-Nummer und Kanton an einer Koordinate zurück (swissBOUNDARIES3D). <use_case>Koordinate → amtliche BFS-Gemeindenummer, der Join-Key zu swiss-statistics-mcp und zurich-opendata-mcp.</use_case> <important_notes>Der Layer führt eine Fläche pro historischem Jahrgang; es wird der aktuelle Stand zurückgegeben. Auf einer Gemeindegrenze oder ausserhalb der Schweiz bleibt das Resultat leer.</important_notes>
params必填Koordinaten umrechnen (REFRAME)
Rechnet Koordinaten amtlich zwischen WGS84 und LV95 um (swisstopo REFRAME). <use_case>Wenn Koordinaten in LV95 (EPSG:2056) vorliegen und für die übrigen Tools nach WGS84 gebracht werden müssen — oder umgekehrt für den Katasterbezug, wo Zentimeter zählen.</use_case> <important_notes>Achsenreihenfolge beachten: REFRAME benennt beide Eingaben easting/northing. Bei wgs84_to_lv95 ist easting der LÄNGENgrad und northing der BREITENgrad — umgekehrt zur lat/lon-Reihenfolge der übrigen Tools. Vertauschte Achsen werden abgewiesen, nicht stillschweigend umgerechnet.</important_notes>
params必填Grundstück-ID (EGRID) ermitteln
Ermittelt die EGRID (Grundstück-ID) aus Koordinaten für einen bestimmten Kanton. <use_case>Grundstück-ID (EGRID) zu einer Koordinate, wenn die ID selbst gebraucht wird. Für die Beschränkungen direkt swisstopo_oereb_at nutzen — das löst den EGRID intern auf.</use_case> <important_notes>Erfordert einen unterstützten Kanton (z.B. ZH, BE).</important_notes>
params必填ÖREB-Auszug abrufen
Ruft öffentlich-rechtliche Eigentumsbeschränkungen (ÖREB) für ein Grundstück (EGRID) ab. <use_case>ÖREB-Auszug zu einem bereits bekannten EGRID. Wer von einer Koordinate ausgeht, nimmt swisstopo_oereb_at — das erledigt beide Schritte in einem Aufruf.</use_case> <important_notes>Erfordert einen unterstützten Kanton.</important_notes>
params必填ÖREB-Auszug an Koordinate
Gibt die ÖREB-Eigentumsbeschränkungen an einer Koordinate zurück (ein Aufruf). <use_case>«Welche Beschränkungen gelten auf diesem Grundstück?» — löst den EGRID intern auf. Das ist der normale Weg; swisstopo_get_egrid braucht es nur, wer die Parzellen-ID selbst benötigt.</use_case> <important_notes>Nur für Kantone mit angebundenem ÖREB-Dienst (siehe SWISSTOPO_OEREB_CANTONS). Koordinaten als lat/lon (WGS84) oder easting/northing (LV95).</important_notes>
params必填Verfügbare Geodaten-Layer auflisten
Discovery-Tool: listet die Layer-Kennungen, die swisstopo_query_geodata akzeptiert. <use_case>Erster Schritt vor swisstopo_query_geodata: herausfinden, welche Datensätze (Strassenverzeichnis, ÖREB-Verfügbarkeit, interkantonale geodienste.ch-Topics) verfügbar und ohne Vertrag frei nutzbar sind. Für konkrete geodienste-Kennungen einen Kanton angeben (z.B. canton='ZH').</use_case>
params必填Geodaten abfragen (Fassade)
Einheitliche Fassade über mehrere Geodaten-Quellen anhand einer Layer-Kennung. <use_case>Ein Tool für drei Quellen: 'strassenverzeichnis' (Strassen um einen Punkt), 'oereb-verfuegbarkeit' (ÖREB-Status/Zuständigkeit an einem Punkt) und 'geodienste:<topic>:<KANTON>' (interkantonale Basisgeodaten via OGC API Features). Genau eine Ortsangabe (point | bbox | commune) übergeben.</use_case> <important_notes>Gültige Layer-Kennungen via swisstopo_list_available_layers. geodienste-Layer erfordern bbox oder point (mit radius_m).</important_notes>
params必填OpenStreetMap-POIs abfragen (Overpass)
Findet OpenStreetMap-POIs (Schulen, Spielplätze, Apotheken …) im Umkreis. <use_case>Beantwortet «Welche Schulhäuser/Spielplätze liegen im Umkreis von R Metern um diesen Punkt/diese Adresse?». Ergänzt die amtlichen swisstopo-Daten um Points-of-Interest aus OpenStreetMap.</use_case> <important_notes>Quelle OpenStreetMap (ODbL, © OpenStreetMap contributors), nicht swisstopo. Overpass hat Rate-Limits/Timeouts — kleiner Radius bevorzugt; bei Überlastung kommt eine sprechende Fehlermeldung statt Daten.</important_notes>
params必填PLZ zu Gemeinde/BFS-Nummer auflösen
Löst eine Schweizer PLZ in Ort, Gemeinde, Bezirk und Kanton auf (OpenPLZ, amtlich). <use_case>Beantwortet «Zu welcher Gemeinde/welchem Kanton gehört PLZ 8001?» und liefert die BFS-Gemeindenummer (`bfs_commune_number`).</use_case> <important_notes>`bfs_commune_number` ist der amtliche Join-Schlüssel zu BFS-Statistikdaten (swiss-statistics-mcp) und zu zurich-opendata-mcp. Quelle OpenPLZ (BFS/swisstopo OGD), nicht die swisstopo-Geodaten. Eine unbekannte PLZ liefert eine leere Trefferliste mit erklärendem Hinweis.</important_notes>
params必填Gemeinde auflösen (Name ↔ BFS-Nummer, Kanton/Bezirk)
Löst Gemeinden auf: Name→BFS-Nummer, BFS-Nummer→Name, oder alle Gemeinden eines Kantons/Bezirks. <use_case>Vier Modi (genau einen Parameter angeben): `name` (Name → BFS-Nummer), `bfs_number` (BFS-Nummer → Gemeinde), `canton` (alle Gemeinden eines Kantons) oder `district` (alle Gemeinden eines Bezirks). Beantwortet z.B. «Welche Gemeinden liegen im Bezirk Uster und wie lauten ihre BFS-Nummern?».</use_case> <important_notes>`bfs_commune_number` ist der amtliche Join-Schlüssel zu BFS-Statistikdaten (swiss-statistics-mcp). `canton` akzeptiert Kürzel ('ZH') oder BFS-Nummer ('1') — die Kürzel→Schlüssel-Auflösung erfolgt serverseitig, weil der Pfad sonst still eine leere Liste liefert. Gemeindelisten sind vollständig (interne Pagination), nicht auf 10 Einträge gekürzt.</important_notes>
params必填Adressen/Orte per Volltext suchen
Volltextsuche über Schweizer Strassen und Ortschaften (OpenPLZ FullTextSearch). <use_case>Findet Strassen und Orte zu einem freien Suchbegriff und liefert je Treffer Gemeinde und BFS-Nummer, wenn vorhanden.</use_case> <important_notes>Quelle OpenPLZ (BFS/swisstopo OGD). Ergebnisse sind paginiert (max. 50/Abfrage); die Gesamttrefferzahl wird ausgewiesen. Für die exakte PLZ→Gemeinde-Auflösung ist swisstopo_lookup_postal_code präziser.</important_notes>
params必填已满足适用检查项的 90%
该评分衡量此收录条目的完整程度，依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价，也不表示服务器安全或当前可用：可连通性是带日期的检查结果，评分也不包含安装量或用户评价。
请在注册中心条目中声明凭据请求头，或保持端点能够响应探测，以便判定其认证方式。
# Clone the repositorygit clone https://github.com/malkreide/swisstopo-mcp.gitcd swisstopo-mcp
# Installpip install -e .# or with uv:uv pip install -e .uvx swisstopo-mcp# stdio (for Claude Desktop)python -m swisstopo_mcp.server
# Streamable HTTP (port 8000)python -m swisstopo_mcp.server --http --port 8000{ "mcpServers": { "swisstopo": { "command": "python", "args": ["-m", "swisstopo_mcp.server"] } }}{ "mcpServers": { "swisstopo": { "command": "uvx", "args": ["swisstopo-mcp"] } }}┌─────────────────┐ ┌──────────────────────────────┐ ┌──────────────────────────┐│ Claude / AI │────▶│ swisstopo-mcp │────▶│ Swisstopo REST API ││ (MCP Host) │◀────│ (MCP Server) │◀────│ api3.geo.admin.ch │└─────────────────┘ │ │ ├──────────────────────────┤ │ 20 Tools │────▶│ Geocoding │ │ Stdio | Streamable HTTP │◀────│ api3.geo.admin.ch │ │ │ ├──────────────────────────┤ │ No authentication required │────▶│ STAC Catalog │ │ (all tools; OEREB canton opt) │◀────│ data.geo.admin.ch │ │ │ ├──────────────────────────┤ │ │────▶│ OEREB Cadastre │ │ │◀────│ (cantonal endpoints) │ │ │ ├──────────────────────────┤ │ │────▶│ geodienste.ch (OGC API) │ │ │◀────│ overpass.osm.ch (ODbL) │ │ │ ├──────────────────────────┤ │ BFS-Nr = join key to │────▶│ OpenPLZ API │ │ swiss-statistics-mcp │◀────│ openplzapi.org (BFS/OGD)│ └──────────────────────────────┘ └──────────────────────────┘swisstopo-mcp/├── src/swisstopo_mcp/│ ├── __init__.py # Package version│ ├── server.py # MCP server wiring (tool registrations)│ ├── api_client.py # Shared HTTP client (httpx + error handling)│ ├── geocoding.py # swisstopo_geocode, swisstopo_reverse_geocode│ ├── rest_api.py # swisstopo_map_query (5 operations), zoning_at, municipality_at│ ├── height.py # swisstopo_get_height, swisstopo_elevation_profile│ ├── stac.py # swisstopo_search_geodata, swisstopo_get_collection│ ├── wmts.py # swisstopo_map_url│ ├── oereb.py # swisstopo_get_egrid, swisstopo_get_oereb_extract│ ├── geodata.py # swisstopo_query_geodata + swisstopo_list_available_layers (façade)│ ├── overpass.py # swisstopo_query_osm_features (OpenStreetMap / Overpass)│ └── openplz.py # swisstopo_lookup_postal_code, swisstopo_find_commune, swisstopo_search_address (OpenPLZ)├── tests/│ ├── test_api_client.py│ ├── test_geocoding.py│ ├── test_height.py│ ├── test_oereb.py│ ├── test_rest_api.py│ ├── test_stac.py│ ├── test_wmts.py│ ├── test_geodata.py│ ├── test_overpass.py│ ├── test_openplz.py│ └── test_retry.py├── .github/workflows/ci.yml # GitHub Actions (Python 3.11/3.12/3.13)├── pyproject.toml├── CHANGELOG.md├── CONTRIBUTING.md # Contribution guide (English)├── CONTRIBUTING.de.md # Contribution guide (German)├── SECURITY.md # Security policy (English)├── SECURITY.de.md # Security policy (German)├── LICENSE├── README.md # This file (English)└── README.de.md # German versionPOST /mcpMCP-Protocol-Version: 2026-07-28Mcp-Method: tools/callMcp-Name: swisstopo_map_urlContent-Type: application/jsonAccept: application/json, text/event-stream
{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{ "name":"swisstopo_map_url", "arguments":{"params":{"lat":46.9481,"lon":7.4474}}, "_meta":{ "io.modelcontextprotocol/protocolVersion":"2026-07-28", "io.modelcontextprotocol/clientCapabilities":{} }}}# Unit tests (no network required)pytest tests/ -m "not live"
# Integration tests (live API calls)pytest tests/ -m "live"{ "mcpServers": { "swisstopo-mcp": { "command": "uvx", "args": [ "swisstopo-mcp" ] } }}