Lombardia Trains MCP server

Lombardia Trains MCP

<!-- mcp-name: io.github.DenisRaimondi/lombardia-trains -->

An MCP server that answers questions about Lombardy trains: departure and arrival boards, live delays, platforms, stop-by-stop progress, cancellations and crowding — and plans journeys with a change, from the regional timetable Regione Lombardia publishes as open data. It reads the public ViaggiaTreno (RFI/Trenitalia) and Trenord APIs. No API key, no account, no scraping.

> is the next train to Malpensa on time?

Departures — MILANO CADORNA (S01066), 21:29
  21:23  REG787    SEVESO                       +2'  platform 9
  21:26  REG387    MALPENSA AEROPORTO TERMINA   -2'  platform 1
  21:32  REG887    SARONNO                       0'  platform 6

Install

dotnet tool install -g LombardiaTrains.Mcp

Then register it with your MCP client. For Claude Desktop, in claudedesktopconfig.json:

{
  "mcpServers": {
    "lombardia-trains": {
      "command": "lombardia-trains-mcp"
    }
  }
}

For Claude Code:

claude mcp add lombardia-trains -- lombardia-trains-mcp

Tools

Station arguments take either a code (S01700) or a name (milano centrale), and times take either HH:mm for today or ISO 2026-08-29T09:00 for another day.

Three behaviours exist because the caller is a language model rather than a person, and each of them prevents a confident wrong answer:

Rome, and every relative question — "tonight", "Saturday" — needs one before any other tool can be called.

• now exists at all because a model has no reliable idea of the date in

stations, and many towns have both a national station and a separate "Nord" one served by entirely different trains. The tools return the list and ask, rather than picking the first and sounding certain.

• Ambiguous names are never resolved silently. "Milano" matches twenty-six

explanation of what the service covers, so the model can decline instead of inventing a train to Switzerland.

• Unknown places say where coverage ends. Asking for Lugano returns an

findconnection finds direct** trains only, and says so. It reads live departure boards and each candidate train's stop list rather than a timetable, so it carries delays and platforms but cannot compose a change.

find_journey composes one. It plans from the regional timetable, falls back to Swiss open data for anywhere that timetable does not reach, and returns scheduled times with no delays in them — the two tools answer different halves of the same question and are meant to be used together.

Journeys are ranked by arrival, not departure. Someone asking how to get somewhere wants to be there soonest, and ranking by departure puts a train that leaves four minutes earlier and arrives forty minutes later at the top of the list.

Only one change is searched for. Two multiply both the search space and the ways to be quietly wrong, and on this network almost everything worth reaching is reachable with one — so the limit is stated rather than hidden behind an incomplete search.

The part worth reading

Both upstream APIs are public, undocumented and a little hostile. Most of the work in this repository is not calling them, it is surviving them. Each of the following is enforced in code and covered by a test.

Trenord wants two headers, not one

Shortened. The full README is on GitHub.