Skip to main content
Glama
mirodn

mcp-server-public-transport

ch_search_connections

Find train connections in Switzerland between stations using real-time data. Get departure times, duration, platforms, and transfer information for planning journeys.

Instructions

Search for train connections in Switzerland between two stations. Uses transport.opendata.ch API to provide real-time connection data including departure times, duration, platforms, and transfers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
originYes
destinationYes
limitNo
dateNo
timeNo
is_arrival_timeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The main handler function implementing ch_search_connections. It validates station names, builds API parameters for date/time/arrival, and fetches JSON data from the Swiss transport API (transport.opendata.ch/connections). Handles TransportAPIError.
    async def ch_search_connections(
        origin: str,
        destination: str,
        limit: Optional[int] = 4,
        date: Optional[str] = None,
        time: Optional[str] = None,
        is_arrival_time: Optional[bool] = False
    ) -> Dict[str, Any]:
        """
        Search for train connections between Swiss stations.
    
        Args:
            origin: Departure station name (e.g., 'Zürich HB')
            destination: Arrival station name (e.g., 'Basel SBB')
            limit: Max number of connections (default: 4)
            date: Date in format YYYY-MM-DD
            time: Time in HH:MM format
            is_arrival_time: Whether time refers to arrival (True) or departure (False)
        """
        origin_clean = validate_station_name(origin)
        destination_clean = validate_station_name(destination)
    
        params = {
            "from": origin_clean,
            "to": destination_clean,
            "limit": limit or 4
        }
    
        if date:
            params["date"] = date
        if time:
            params["time"] = format_time_for_api(time)
        if is_arrival_time:
            params["isArrivalTime"] = "1"
    
        try:
            logger.info(f"Searching connections: {origin} → {destination}")
            return await fetch_json(f"{CH_BASE_URL}/connections", params)
        except TransportAPIError as e:
            logger.error(f"CH connection search failed: {e}")
            raise
  • tools/ch.py:16-19 (registration)
    The @mcp.tool decorator registers the ch_search_connections function with the MCP server instance, specifying the tool name and description.
    @mcp.tool(
        name="ch_search_connections",
        description="Search for train connections in Switzerland between two stations. Uses transport.opendata.ch API to provide real-time connection data including departure times, duration, platforms, and transfers."
    )
  • tools/ch.py:139-144 (registration)
    The register_ch_tools function returns a list including the ch_search_connections tool object for further use (e.g., logging total tools).
    return [
        ch_search_connections,
        ch_search_stations,
        ch_get_departures,
        ch_nearby_stations
    ]
  • server.py:49-52 (registration)
    In the main server.py, register_ch_tools(mcp) is called to register the CH tools, including ch_search_connections, with the FastMCP server instance.
    # Register tools (UK only if keys exist and not disabled)
    ch_tools = register_ch_tools(mcp)
    be_tools = register_be_tools(mcp)
    no_tools = register_no_tools(mcp)
  • Docstring providing detailed input schema descriptions for parameters, used for tool schema validation in MCP.
    """
    Search for train connections between Swiss stations.
    
    Args:
        origin: Departure station name (e.g., 'Zürich HB')
        destination: Arrival station name (e.g., 'Basel SBB')
        limit: Max number of connections (default: 4)
        date: Date in format YYYY-MM-DD
        time: Time in HH:MM format
        is_arrival_time: Whether time refers to arrival (True) or departure (False)
    """
Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses the API source (transport.opendata.ch) and data types (real-time, including specific fields), which is useful context. However, it doesn't mention rate limits, authentication needs, error handling, or pagination behavior, leaving gaps for a search tool.

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 efficiently structured in two sentences: the first states purpose and scope, the second adds API details and data specifics. Every sentence adds value with no wasted words, making it easy to parse and front-loaded with key information.

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?

Given 6 parameters with 0% schema coverage and an output schema (which reduces need to explain returns), the description provides good context on what the tool does and data included. However, it lacks details on parameter usage, behavioral constraints, and sibling differentiation, leaving minor gaps for full agent understanding.

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 description coverage is 0%, so the description must compensate. It doesn't explicitly explain parameters, but it implies 'origin' and 'destination' as stations and mentions data types like 'departure times' and 'duration', which relate to 'date', 'time', and 'limit'. This adds some meaning beyond the bare schema, though not comprehensive for all 6 parameters.

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 clearly states the specific action ('Search for train connections'), resource ('between two stations in Switzerland'), and scope ('real-time connection data including departure times, duration, platforms, and transfers'). It distinguishes from siblings by specifying Switzerland and the transport.opendata.ch API, unlike generic connection 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?

The description implies usage context (Switzerland, train connections) but doesn't explicitly state when to use this tool versus alternatives like 'ch_search_stations' or 'ch_get_departures'. No exclusions or prerequisites are mentioned, leaving some ambiguity about tool selection.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mirodn/mcp-server-public-transport'

If you have feedback or need assistance with the MCP directory API, please join our Discord server