swisstopo-mcp

Overview Schema Source Related Servers Discussions Admin

swisstopo_reverse_geocode

Read-onlyIdempotent

Resolve WGS84 coordinates to the nearest Swiss address. Input latitude and longitude to receive location details for maps or GPS data.

Instructions

Findet die nächstgelegene Adresse zu gegebenen WGS84-Koordinaten (Reverse Geocoding).

Koordinaten aus Karte oder GPS in eine lesbare Adresse auflösen.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`note`	No	Actionable hint when a search returns nothing — what to try next, rather than a bare negative (audit ARCH-003).
`count`	No	Number of structured results.
`source`	No	Data source attribution.	swisstopo / geo.admin.ch
`license`	No	Data licence.	Swiss Open Government Data (opendata.swiss)
`results`	No	Structured result records (machine-readable).
`summary`	Yes	Human-readable Markdown summary of the result.
`is_error`	No	True if this represents a handled error.
`match_type`	No	exact \| fuzzy \| none (for search-style tools).
`provenance`	No	How the data was obtained.	live_api
`retrieved_at`	No	ISO-8601 retrieval timestamp.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.5.0Sep 26, 2026

addedInput schema / $defs / ReverseGeocodeInput / properties / radius_m

Added value: +{
+  "default": 500,
+  "description": "Suchradius in Metern um den Punkt",
+  "maximum": 5000,
+  "minimum": 50,
+  "title": "Radius M",
+  "type": "integer"
+}

removedInput schema / $defs / ReverseGeocodeInput / properties / sr

Removed value: -{
-  "default": 4326,
-  "description": "Koordinatensystem (EPSG-Code)",
-  "title": "Sr",
-  "type": "integer"
-}

Changed1 schema field changedv0.4.1Aug 2, 2026

addedOutput schema / properties / note

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Actionable hint when a search returns nothing — what to try next, rather than a bare negative (audit ARCH-003).",
+  "title": "Note"
+}

First observedv0.1.0Jun 2, 2026

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as read-only, idempotent, and non-destructive, so the bar for extra disclosure is lower. The description adds the behavioral nuance that it returns the nearest address and expects WGS84 input, but it does not describe result limits, pagination, or error behavior. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the main action front-loaded and the use case in a structured tag. No filler or redundancy, and the length is appropriate for the tool's simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has rich annotations, a detailed input schema with bounds and defaults, and an output schema, so the description only needs to state purpose and usage context. It does that clearly; the only minor omission is explicit mention of optional parameters, but those are fully covered by the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description only identifies the input as WGS84 coordinates, which maps to lat/lon but says nothing about limit or radius_m. With the reported 0% schema description coverage, the description fails to compensate for the optional parameters, leaving the agent to rely on the schema's own descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Findet'), a concrete resource ('die nächstgelegene Adresse'), and the input type (WGS84 coordinates). The phrase 'Reverse Geocoding' clearly distinguishes it from the sibling swisstopo_geocode, and the use case reinforces the direction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The use_case tag provides clear context: use this when you have coordinates from a map or GPS and need a readable address. It does not explicitly name alternatives or exclusion conditions, but the reverse-geocoding label makes the appropriate scenario obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.