SBB Open Data MCP Server

Overview Schema Source Related Servers Discussions Admin

SBB Bahnhöfe vergleichen

sbb_compare_stations

Read-onlyIdempotent

Compare 2-10 SBB stations by passenger frequency and platform metrics for planning, presentations, and location analyses. Returns a compact table for a chosen or latest year.

Instructions

Vergleicht mehrere SBB-Bahnhöfe anhand Passagierfrequenz und Perrondaten.

Kombiniert drei Datensätze (Passagierfrequenz, Bahnhofnutzer, Perrons) zu einem kompakten Vergleich. Nützlich für Planungsentscheide, Präsentationen und Standortanalysen.

Args: params (CompareStationsInput): Parameter: - stations (list[str]): Liste von Bahnhofsnamen (2–10), z.B. ['Zürich HB', 'Bern'] - year (Optional[str]): Vergleichsjahr, z.B. '2024'

Returns: str: Tabellarischer Vergleich der Bahnhöfe mit Passagierfrequenz und Perron-Kennzahlen.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`year`	Yes
`stations`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.4.0Sep 27, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$defs": {
+    "StationComparisonOutput": {
+      "description": "One requested station. Only `name` is guaranteed: the rest is absent\nwhen the source had no passenger-frequency or platform match.",
+      "properties": {
+        "canton": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null,
+          "title": "Canton"
+        },
+        "dtv": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null,
+          "description": "Average daily passengers",
+          "title": "Dtv"
+        },
+        "dwv": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null,
+          "description": "Average workday passengers",
+          "title": "Dwv"
+        },
+        "matched_name": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null,
+          "title": "Matched Name"
+        },
+        "name": {
+          "description": "Station name as requested",
+          "title": "Name",
+          "type": "string"
+        },
+        "platform_count": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null,
+          "title": "Platform Count"
+        },
+        "total_platform_length_m": {
+          "anyOf": [
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null,
+          "title": "Total Platform Length M"
+        },
+        "year": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "default": null,
+          "title": "Year"
+        }
+      },
+      "required": [
+        "name"
+      ],
+      "title": "StationComparisonOutput",
+      "type": "object"
+    }
+  },
+  "properties": {
+    "stations": {
+      "items": {
+        "$ref": "#/$defs/StationComparisonOutput"
+      },
+      "title": "Stations",
+      "type": "array"
+    },
+    "year": {
+      "title": "Year",
+      "type": "string"
+    }
+  },
+  "required": [
+    "year",
+    "stations"
+  ],
+  "title": "CompareStationsOutput",
+  "type": "object"
+}

Changed4 schema fields changedv0.3.4Aug 1, 2026

addedInput schema / $defs / CompareStationsInput / properties / response_format

Added value: +{
+  "$ref": "#/$defs/ResponseFormat",
+  "default": "markdown",
+  "description": "Ausgabeformat: 'markdown' (lesbar) oder 'json' (maschinenlesbar)"
+}

changedInput schema / $defs / CompareStationsInput / properties / year / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^\\d{4}$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / $defs / ResponseFormat

Added value: +{
+  "enum": [
+    "markdown",
+    "json"
+  ],
+  "title": "ResponseFormat",
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "sbb_compare_stationsOutput",
-  "type": "object"
-}New value: +null

First observedv0.1.0Jun 3, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare this as a read-only, idempotent, non-destructive, open-world operation. The description adds useful behavioral context by explaining that it combines three datasets and returns a compact tabular comparison, but it does not cover rate limits, data freshness handling, or authentication requirements.

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

Conciseness4/5

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

The description is front-loaded with the core purpose and then organized into Args and Returns sections. It is appropriately sized, though some material such as the Args section partially duplicates schema information and the Returns section overlaps with the output schema.

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 read-only comparison tool with rich annotations and an output schema, the description is largely complete: it states the comparison basis, the combined datasets, and the output nature. Its main gap is not mentioning the response_format option, but the schema and output schema cover most remaining details.

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

Parameters3/5

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

The description names the main inputs (stations and year) and repeats the 2–10 station constraint, but much of this is already present in the schema. It omits the response_format parameter entirely, even though that parameter controls whether output is markdown or JSON, so it only partially compensates for the low top-level schema description coverage.

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

Purpose4/5

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

States a specific verb and resource ('Vergleicht mehrere SBB-Bahnhöfe') and specifies the comparison dimensions (Passagierfrequenz und Perrondaten). It clearly distinguishes itself from single-dataset siblings like sbb_get_passenger_frequency and sbb_get_platform_data by comparing multiple stations and combining three datasets, though it does not name those alternatives explicitly.

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?

Gives clear usage contexts ('Planungsentscheide, Präsentationen und Standortanalysen'), which tells the agent when this tool is appropriate. It does not state when not to use it or explicitly compare it with alternatives such as sbb_get_passenger_frequency, so it falls short of full routing guidance.

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

Deploy Server