osm-mcp

Ein MCP-Server für OpenStreetMap: Geokodierung, Geh-/Fahr-/Radfahrstrecken und -dauern, Optimierung von Routen mit mehreren Zwischenstopps, Isochronen und POI-Suche – entwickelt für die Reiseplanung mit KI-Assistenten.

11 Werkzeuge, alle schreibgeschützt. Alle Backends sind kostenlose öffentliche OpenStreetMap-Dienste; es ist kein API-Schlüssel erforderlich. Ein OpenRouteService-Schlüssel kann optional angegeben werden, um die Routing-Engine zu wechseln.

📖 Vollständige Dokumentation: https://osm-mcp.ni-c.de

Warum ein weiterer OSM-MCP-Server?

• Korrekte Geh- und Radfahrrouten. Die öffentlichen OSRM-Demo-Server ignorieren das Profilsegment im OSRM-URL-Pfad und geben immer Auto-Routen zurück, es sei denn, die FOSSGIS-Pfadpräfixe routed-foot / routed-bike / routed-car werden verwendet. Die meisten vorhandenen OSM-MCP-Server machen das falsch und geben stillschweigend Fahrzeiten für Fußwege-Anfragen zurück. Dieser Server verwendet die Präfixe und sein Live-Smoke-Test stellt sicher, dass Fußwege viel langsamer sind als Autostrecken.

• Richtlinienkonform von Grund auf. Dienstspezifische Ratenbegrenzung (Nominatim und OSRM: 1 Anfrage/Sekunde), ein identifizierender User-Agent bei jeder Anfrage (erforderlich durch die Nominatim-Nutzungsrichtlinie), Antwort-Caching, begrenzte Overpass-Gleichzeitigkeit (2 Slots) und automatisches Failover auf einen Overpass-Spiegel bei 429/5xx.

• Photon-Unterstützung. Optionale tippfehlertolerante Geokodierung über komoots Photon, das für die interaktive Nutzung konzipiert ist – eine bessere Wahl für LLM-gesteuerte Abfragen als Nominatim zu überlasten.

Related MCP server: Geo MCP Worker

Voraussetzungen

• Node.js ≥ 22

• Internetzugang zu den öffentlichen OpenStreetMap-Diensten (siehe Tabelle unten)

Konfiguration

Jede Variable ist optional – der Server funktioniert sofort einsatzbereit.

Installieren

claude mcp add osm -- npx -y osm-mcp

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "osm": {
      "command": "npx",
      "args": ["-y", "osm-mcp"]
    }
  }
}

Codex (~/.codex/config.toml):

[mcp_servers.osm]
command = "npx"
args = ["-y", "osm-mcp"]

Container (Multi-Arch, mit SBOM und Build-Provenienz):

docker run -i --rm ghcr.io/ni-c/osm-mcp

-i ist erforderlich – das Protokoll läuft über stdin und stdout. Es gibt keinen Port zum Veröffentlichen. Weitere Client-Rezepte finden Sie im Client-Leitfaden.

Werkzeuge

Jede Ortsangabe akzeptiert entweder einen Namen/eine Adresse (automatisch geokodiert) oder buchstäbliche Koordinaten als "lat,lon".

Nutzungsrichtlinien & Quellenangabe

Dieser Server kommuniziert mit gemeinsamer Community-Infrastruktur. Er erzwingt die veröffentlichten Limits clientseitig, aber der Betreiber bittet die Nutzer, die Gesamtnutzung gering und nicht kommerziell zu halten:

• Daten: © OpenStreetMap Mitwirkende, lizenziert unter ODbL 1.0.

• Nominatim: max. 1 Anfrage/Sekunde, identifizierender User-Agent obligatorisch, Ergebnisse gecached (Richtlinie).

• OSRM / Valhalla (FOSSGIS): angemessene, nicht kommerzielle Nutzung; max. 1 Anfrage/Sekunde (Info).

• Overpass: ~2 gleichzeitige Slots pro IP, <10.000 Abfragen/Tag (Wiki).

• Photon: faire Nutzung (photon.komoot.io).

Für intensive oder kommerzielle Nutzung hosten Sie die Dienste selbst und richten Sie die *_BASE_URL-Variablen auf Ihre Instanzen.

Sicherheit

• Alle Werkzeuge sind schreibgeschützt; der Server schreibt nie in OpenStreetMap.

• Es sind keine Anmeldeinformationen erforderlich; der optionale ORS_API_KEY wird nach dem Laden aus der Prozessumgebung entfernt und in Fehlermeldungen geschwärzt.

• OSM-basierte Inhalte (Namen, Adressen, Tags) werden in den Werkzeugergebnissen als nicht vertrauenswürdige Daten markiert, sodass das Modell sie als Daten und nicht als Anweisungen behandelt.

• Upstream-Fehlermeldungen werden gekürzt und HTML-Fehlerseiten verworfen, bevor sie den Modellkontext erreichen.

• Weiterleitungen werden nie verfolgt; alle Anfragen haben ein Timeout.

Entwicklung

npm install
npm run lint          # eslint + prettier
npm test              # unit tests (all upstream APIs mocked)
npm run test:coverage
npm run build
npm run smoke         # opt-in LIVE test against the real public services

Veröffentlichung

Tag-gesteuert, kein manueller Veröffentlichungsschritt:

1. Verschieben Sie die Einträge aus [Unreleased] in einen neuen Abschnitt ## [x.y.z] - YYYY-MM-DD in CHANGELOG.md und erhöhen Sie die Version in package.json.

2. npm run lint && npm run build && npm run test:coverage.

3. Committen, dann einen signierten annotierten Tag: git tag -s vx.y.z -m "vx.y.z".

4. git push origin main vx.y.z.

release.yml führt dann die Tests aus, veröffentlicht auf npm mit Provenienz über Trusted Publishing (kein Token-Geheimnis beteiligt), erstellt das GitHub-Release aus dem CHANGELOG-Abschnitt und veröffentlicht im MCP-Registry als io.github.ni-c/osm-mcp. ci.yml pusht das Multi-Arch-Image auf GHCR beim gleichen Tag.

Wenn der Registry-Schritt fehlschlägt, beheben Sie ihn auf main und lösen Sie den Workflow Publish to MCP Registry aus – führen Sie den Tag-Job nicht erneut aus, da dieser den alten Baum auschecken würde.

Lizenz

MIT