Spick Me — Swiss public transport

Everywhere reachable by public transport within a time budget

reachable_area

Read-onlyIdempotent

List every station and stop in Switzerland reachable from one place within a number of minutes by public transport, nearest first, with the earliest arrival at each. One call answers what would otherwise be hundreds of journey searches.

Use it for "where can I get to from Bern in 45 minutes", "which towns are within an hour's commute of Zug", catchment areas and isochrones. For the travel time between specific places, use travel_time_matrix; for how to make a particular journey, plan_journey.

Inputs: from is A station or stop name ("Zürich HB", "Bern", "Lausanne, Flon"), an address ("Bahnhofstrasse 1, Winterthur"), a named place ("ETH Zürich", "Kunsthaus"), a coordinate as "geo:47.3769,8.5417", or a place_id returned by find_place ("stop:8503000"). Names are read the way a rider types them; an ambiguous name returns candidates instead of a guess. (an address or coordinate is snapped to its nearest stop, which the answer names). departure is when to leave: Swiss local time in ISO 8601, e.g. "2026-09-26T08:00"; an explicit offset or Z is converted. A bare "08:00" means today (tomorrow if it has long passed). Omit for now. max_minutes is the time budget (default 60), waiting for the first vehicle included. limit is how many places to list (default 50). max_transfers caps changes.

Minutes are timetable minutes from the departure time given, on that day's planned timetable; live delays are not included.

Example: {"from": "Bern", "departure": "2026-09-28T07:30", "max_minutes": 45}

Input Schema

TableJSON Schema

Name	Required	Description
`from`	Yes	Where to start.
`limit`	No	How many places to list, nearest first.
`departure`	No	When to leave. Omit for now.
`max_minutes`	No	The time budget in minutes, waiting included.
`max_transfers`	No	The most changes of vehicle allowed.
`transfer_time_factor`	No	How much time to allow for changing trains, as a multiple of the timetable's minimum change times: 1 (default) is the timetable's own; 1.5 for luggage, children or reduced mobility; 0.7 for a fast walker. Between 0.5 and 3.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`from`	Yes
`places`	Yes
`departure`	No
`truncated`	Yes
`max_minutes`	No
`total_reachable`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 3, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds material behavior: results are timetable minutes on the planned timetable with live delays excluded, an address or coordinate is snapped and the answer names the stop, and an ambiguous name returns candidates rather than guessing. These are exactly the traits an agent cannot infer from the structured fields.

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?

Front-loaded with the core behavior and the routing alternatives before the input detail, and a worked example closes it usefully. It is on the long side and the parenthetical asides could be tightened, but each sentence carries information.

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?

An output schema exists, so return-value explanation is unnecessary, and the description nonetheless covers the behavior an agent needs: defaults (60 minutes, 50 results), waiting included in the budget, and the timetable-only caveat. Complete for a six-parameter read tool.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real value beyond the schema: accepted 'from' formats (station name, address, named place, 'geo:lat,lon', 'stop:8503000' place_id), ISO 8601 departure semantics including offset conversion and the bare '08:00' meaning today. It omits transfer_time_factor, which the description never mentions, so it is not fully additive.

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?

States a specific verb (list) and resource (every station/stop reachable) with scope and ordering ('nearest first, with the earliest arrival at each'). It explicitly distinguishes itself from travel_time_matrix and plan_journey, so an agent can route correctly without opening schemas.

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?

Gives concrete user-intent examples ('where can I get to from Bern in 45 minutes', catchment areas, isochrones) and names the alternatives with the condition that selects them ('for travel time between specific places use travel_time_matrix; for how to make a particular journey, plan_journey'). Nothing is left to inference.

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

All Spick Me — Swiss public transport tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?