Belgium Data Desk

Belgian train punctuality: station, train, IC line, national (Infrabel)

train_punctuality

Read-only

How punctual Belgian trains are, from Infrabel's official open data. For a station (name in Dutch, French or English, or the nearest one to an address): the share of trains arriving less than 6 minutes late in the latest month against the average over all stops, its rank, the last 13 months, and yesterday train by train (delay bands, average delay, the latest trains). For a train number: every point it passed yesterday with its delays, where the delay grew and whether it was on time at the official measuring points. For an IC line (e.g. 'IC 01'): monthly punctuality per direction and by time of day against the national figure. With none of these: the national figure (also counting cancellations), by train type, punctuality lost by cause, cancellations per operator, and today so far. Starts with key_facts. Does not give live departures or platform changes, and has no train-by-train data before yesterday. Examples: How punctual are trains at Leuven station? → {"station":"Leuven"}; Was train 2112 late yesterday, and where did it lose time? → {"train_number":"2112"}; How punctual is the IC 01 Oostende-Eupen? → {"ic_line":"IC 01"}; How punctual were Belgian trains last month, and today? → {}.

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": "train_punctuality"
  }
}

Input Schema

Name	Required	Description
`month`	No	Month for the monthly figures as YYYY-MM, e.g. '2026-03'; default the latest Infrabel published.
`address`	No	An address or place instead of a station: the nearest station is used, e.g. 'Grote Markt 1, 2800 Mechelen'.
`ic_line`	No	An InterCity line, e.g. 'IC 01', 'IC 16-1' or 'IC3'.
`station`	No	A passenger station, e.g. 'Leuven', 'Bruxelles-Midi', 'Gent-Sint-Pieters', 'Luik-Guillemins'.
`latitude`	No	WGS84 latitude, e.g. 51.0453 (use with longitude instead of address).
`longitude`	No	WGS84 longitude, e.g. 3.7275.
`x_lambert72`	No	Belgian Lambert 72 (EPSG:31370) x in metres, as an alternative to latitude/longitude.
`y_lambert72`	No	Belgian Lambert 72 (EPSG:31370) y in metres.
`train_number`	No	A train number as on the departure board, e.g. '2112': its run yesterday stop by stop.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare read-only, open-world and non-destructive; the description adds the data source, temporal coverage (latest month, last 13 months, yesterday only for train-level data), and that results start with key_facts. It does not mention rate limits or authentication, but none are implied for an open-data read 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?

Front-loads the core purpose, then uses a compact semicolon-separated structure to enumerate modes, caveats and examples. No sentence is redundant; the examples are directly useful for parameter selection.

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?

For a nine-optional-parameter, no-output-schema read tool, the description covers input combinations, temporal limits and the output entry point (key_facts). Nothing essential is missing.

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

Parameters5/5

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

Schema coverage is 100%, so baseline is 3, but the description goes beyond field descriptions by explaining how station/address/coordinates select a station view, how train_number returns yesterday's run, and how ic_line returns monthly direction and time-of-day comparisons. This interaction-level meaning is not in the schema.

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 the resource (Belgian train punctuality from Infrabel open data) and the specific scopes available (station, train number, IC line, national). It distinguishes each mode clearly, so an agent can map an intent to the right parameter set 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?

Explicitly tells when each parameter combination applies through four concrete example questions. It also states exclusions (no live departures, no platform changes, no train-by-train data before yesterday), which prevents misuse.

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

All Belgium Data Desk 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.