Trafikverket MCP Server

get_replacement_traffic

Read-onlyIdempotent

Retrieve buses, coaches, or taxis replacing cancelled Swedish trains, with train numbers, status, accessibility, stops, times, delays, and traveller notes; filter by station, train, or date.

Instructions

Get replacement traffic (ersättningstrafik) for Swedish trains: the buses, coaches or taxis that run instead of cancelled trains, with the replaced train numbers, vehicle type, status (planned, ordered, confirmed, running, finished, canceled), wheelchair access, toilet, and every stop with stop description (where to board), planned/expected/actual times, delay in minutes and traveller notes. Filter by station (name or signature; the stop there is returned as atStation), by replaced train number, and/or by the replaced train's departure date; otherwise trips from minutesBack before now to hoursAhead after now. Operators report this voluntarily, so not every replacement is listed: use get_train_announcements to see which trains are cancelled and get_train_messages for the disruption behind them. Returns an error result (isError: true) if TRAFIKVERKET_API_KEY is missing/invalid or the Trafikverket API is unreachable. Coverage: Sweden only (Trafikverket data).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

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

Input Schema

Name	Required	Description
`date`	No	Departure date (YYYY-MM-DD) of the replaced train. When set, the whole day is searched and minutesBack/hoursAhead are ignored
`limit`	No	Maximum number of trips to return (1-50)
`station`	No	Only trips stopping at this station: name (e.g. "Lund C", "Malmö") or location signature (e.g. "Lu")
`hoursAhead`	No	Include trips departing up to this many hours after now (0.5-48, default 12)
`minutesBack`	No	Include trips still running or departing up to this many minutes before now (0-240, default 30)
`trainNumber`	No	Only trips replacing this advertised train number, e.g. "1043"

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.1Nov 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover the safe-read profile (readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false), and the description adds what annotations cannot: an error result with isError: true when TRAFIKVERKET_API_KEY is missing or the API is unreachable, Sweden-only coverage, and the voluntary-reporting data gap. These are exactly the failure and completeness traits an agent needs before calling.

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 purpose, then return contents, then filters, then alternatives and caveats - a sensible order. It is a dense single paragraph that runs long, and the enumerated return fields partly duplicate what the filter sentence already implies, but with no output schema present that enumeration earns its place.

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?

Packs the fields that would otherwise live in an output schema (train numbers, vehicle type, status values, wheelchair access, toilet, per-stop descriptions, planned/expected/actual times, delay, notes), plus failure modes and geographic coverage. For a six-parameter read tool with no output schema, nothing an agent needs 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?

Schema description coverage is 100%, so the baseline is 3, and the description still adds meaning: it explains that the station filter matches by name or signature and that the matched stop appears as atStation in the results, and it clarifies the date-versus-window precedence. It stops short of adding format or syntax detail beyond the schema, so it does not fully earn a 5.

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 and resource ('Get replacement traffic (ersättningstrafik) for Swedish trains'), enumerates what is returned, and explicitly distinguishes itself from the sibling tools get_train_announcements and get_train_messages. An agent can identify the tool's domain without opening the schema.

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?

Spells out the exact selection conditions (station, replaced train number, departure date) versus the default time window, then routes the agent to alternatives: get_train_announcements for cancelled trains and get_train_messages for the underlying disruption. It also warns that operators report voluntarily so absence of a result is not proof of no replacement.

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

Deploy Server