Skip to main content
Glama
Sign In
SBB Open Data MCP Server

SBB Open Data MCP Server

by malkreide
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

SBB Haltestellen suchen

sbb_search_stations
Read-onlyIdempotent

Search all Swiss public transport stations and stops by name or canton, returning UIC numbers, coordinates, operators, and canton details.

Instructions

Sucht Bahnhöfe und Haltestellen der Schweiz (DiDok-Liste des BAV).

Deckt alle öV-Haltestellen ab (nicht nur SBB). Enthält UIC-Nummern, Koordinaten, Kantone und Betreiberinformationen.

Args: params (StationSearchInput): Parameter: - query (str): Suchbegriff (mind. 2 Zeichen), z.B. 'Wädenswil', 'Zürich' - canton (Optional[str]): Kantonskürzel, z.B. 'ZH' - limit (int): Max. Resultate - response_format (str): 'markdown' oder 'json'

Returns: str: Haltestellenliste mit UIC, Kanton und Koordinaten. Schema: {name, uic, canton, operator, coordinates}

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "params": "<params>"
    },
    "name": "sbb_search_stations"
  }
}

Input Schema

NameRequiredDescriptionDefault
paramsYes

Output Schema

NameRequiredDescriptionDefault
resultsYesDiDok records as returned by data.sbb.ch
total_countYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "results": {
+      "description": "DiDok records as returned by data.sbb.ch",
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "title": "Results",
+      "type": "array"
+    },
+    "total_count": {
+      "title": "Total Count",
+      "type": "integer"
+    }
+  },
+  "required": [
+    "total_count",
+    "results"
+  ],
+  "title": "StationSearchOutput",
+  "type": "object"
+}
  2. Changed2 schema fields changedv0.3.4
    • changedInput schema / $defs / StationSearchInput / properties / canton / anyOf
      Previous value: -[
-  {
-    "maxLength": 2,
-    "minLength": 2,
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 2,
+    "minLength": 2,
+    "pattern": "^[A-Za-z]{2}$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "sbb_search_stationsOutput",
-  "type": "object"
-}New value: +null
  3. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered structurally and the description doesn't need to repeat it. The description usefully adds the data scope (UIC numbers, coordinates, cantons, operator info) and the return format, but omits any note on auth, rate limits, or result completeness.

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?

Purpose is front-loaded and the Args/Returns structure is easy to scan. There is mild redundancy between the Args list and the Returns schema line, but no wasted filler.

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 single-object, four-parameter read tool with an output schema, the description covers purpose, parameters, and the returned fields (name, uic, canton, operator, coordinates). Nothing essential to invoking it correctly is missing.

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

Parameters4/5

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

Reported schema description coverage is 0%, so the description must carry parameter meaning, and it does: it enumerates query (min 2 chars, examples), canton (canton code examples), limit, and response_format with its allowed values. This compensates well for the thin coverage, though it doesn't explain limit's max of 100 or canton's exact format constraints.

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 (Sucht) and resource (Bahnhöfe und Haltestellen der Schweiz) and clarifies the scope as the BAV DiDok list covering all ÖV stops, not just SBB. This disambiguates from an SBB-only assumption, but it never contrasts itself with the related sibling sbb_compare_stations or the other get_* tools.

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

Usage Guidelines3/5

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

Usage is implied by the scope clarification ('alle ÖV-Haltestellen, nicht nur SBB'), which tells the agent when this tool is appropriate for broad stop lookups. However there are no explicit when-to-use/when-not rules and no mention of alternatives such as sbb_compare_stations for comparing two stops.

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

Deploy Server

Other Tools