swisstopo-mcp

by malkreide

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

swisstopo_get_egrid

Read-onlyIdempotent

Resolve a Swiss property ID (EGRID) from coordinates by providing WGS84 or LV95 values and a canton code.

Instructions

Ermittelt die EGRID (Grundstück-ID) aus Koordinaten für einen bestimmten Kanton.

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. Erfordert einen unterstützten Kanton (z.B. ZH, BE).

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.

Changed16 schema fields changedv0.4.1Aug 2, 2026

addedInput schema / $defs / GetEgridInput / properties / easting

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "LV95-Ostwert in Metern (EPSG:2056, z.B. 2683531). Zusammen mit northing.",
+  "title": "Easting"
+}

addedInput schema / $defs / GetEgridInput / properties / lat / anyOf

Added value: +[
+  {
+    "maximum": 47.9,
+    "minimum": 45.8,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / $defs / GetEgridInput / properties / lat / default
```
Added value: +null
```

changedInput schema / $defs / GetEgridInput / properties / lat / description

Previous value: -"Breitengrad (WGS84)"New value: +"Breitengrad (WGS84). Zusammen mit lon angeben."

removedInput schema / $defs / GetEgridInput / properties / lat / maximum
```
Removed value: -47.9
```
removedInput schema / $defs / GetEgridInput / properties / lat / minimum
```
Removed value: -45.8
```
removedInput schema / $defs / GetEgridInput / properties / lat / type
```
Removed value: -"number"
```

addedInput schema / $defs / GetEgridInput / properties / lon / anyOf

Added value: +[
+  {
+    "maximum": 10.5,
+    "minimum": 5.9,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / $defs / GetEgridInput / properties / lon / default
```
Added value: +null
```

changedInput schema / $defs / GetEgridInput / properties / lon / description

Previous value: -"Längengrad (WGS84)"New value: +"Längengrad (WGS84). Zusammen mit lat angeben."

removedInput schema / $defs / GetEgridInput / properties / lon / maximum
```
Removed value: -10.5
```
removedInput schema / $defs / GetEgridInput / properties / lon / minimum
```
Removed value: -5.9
```
removedInput schema / $defs / GetEgridInput / properties / lon / type
```
Removed value: -"number"
```

addedInput schema / $defs / GetEgridInput / properties / northing

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "LV95-Nordwert in Metern (EPSG:2056, z.B. 1247914). Zusammen mit easting.",
+  "title": "Northing"
+}

changedInput schema / $defs / GetEgridInput / required

Previous value: -[
-  "lat",
-  "lon",
-  "canton"
-]New value: +[
+  "canton"
+]

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.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful context about the need for a supported canton, which could cause errors otherwise. It doesn't contradict annotations and provides the key behavioral constraint beyond what annotations state.

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?

The description is extremely concise: one main sentence, a use_case block, and a short important note. It's well-structured with tagged sections, front-loads the core purpose, and every sentence earns its place without redundancy.

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

Completeness4/5

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

For a simple lookup tool with strong annotations and an output schema, the description covers the primary use case, an alternative, and an important prerequisite. It misses explicitly stating the coordinate pair requirement, but the schema handles that detail. Overall, it's adequately complete for an agent to invoke correctly.

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 tool description does not explain parameter semantics; it only says 'aus Koordinaten' (from coordinates). The schema does describe each parameter, but with schema_description_coverage at 0%, the description provides almost no value beyond the schema. It gives no hints about the need to supply either lat/lon or easting/northing, nor the coordinate systems.

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 uses the specific verb 'ermittelt' (determines) and clearly identifies the resource (EGRID property ID) and the input (coordinates for a specific canton). It also distinguishes itself from siblings by explicitly directing users to swisstopo_oereb_at for restrictions, resolving the EGRID internally.

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

Usage Guidelines5/5

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

The use_case section states when to use the tool ('wenn die ID selbst gebraucht wird') and explicitly points to an alternative for restriction lookups (swisstopo_oereb_at). The important_notes adds a prerequisite (supported canton), giving clear usage guidance.

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