Skip to main content
Glama
dukarev

rail-interop-mcp

by dukarev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
resolve_operational_pointA

Find operational points (stations, junctions, border points) by name in Poland or Czechia.

Call this first to turn a place name from the user into an op_id for find_route. Diacritics
are ignored. An empty candidate list is a valid answer (the place was not found), not an error.
find_routeA

Compute a route between two operational points over the ERA RINF infrastructure graph.

Call resolve_operational_point first to get valid op_id values. Call this before
check_train_compatibility or assess_weather_risk: both need the route this returns.
check_train_compatibilityA

Check whether a train fits the infrastructure of a route (gauge, axle load, clearance, length).

Call find_route first and pass its route as `route`, or pass `section_ids` to check a specific
segment (e.g. after adjusting a route). Exactly one of the two is required.
assess_weather_riskA

Turn a weather forecast at points along a route into a structured risk assessment.

Call find_route first (for `route` or its section_ids) and the existing OpenWeather MCP
server's `weather` tool for forecasts at find_route's waypoints, before calling this.
Exactly one of `route` or `section_ids` is required, same as check_train_compatibility.
plan_tractionA

Assign locomotives from a fleet to a route's runs, greedily minimising changes.

Call find_route first and pass its route as `route`, or pass `section_ids`, same as
check_train_compatibility. Give at least one locomotive via `fleet_ids` (ids from
data/locomotives.yaml) or `custom_locomotives`. A run with no locomotive able to cover
it (unknown/non-electrified energy system, or unmatched signalling) is uncovered, not
an error.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a distinctly different aspect of the rail planning workflow: place resolution, route computation, infrastructure compatibility, weather risk, and traction planning. Their inputs and outputs are clearly separated, with no overlapping responsibilities or ambiguous boundaries.

Naming Consistency5/5

All tool names follow a strict verb_noun pattern in snake_case: resolve_operational_point, find_route, check_train_compatibility, assess_weather_risk, plan_traction. The verbs are specific and the nouns clarify the object, making the naming entirely predictable.

Tool Count5/5

With 5 tools, the server covers the core end-to-end rail interoperability workflow without redundancy. Each tool is necessary and contributes to a different step, so the count is well-calibrated for the stated purpose.

Completeness5/5

The tools form a complete lifecycle: resolve places to op_ids, find a route, validate train compatibility, assess weather risk, and plan traction. No obvious missing operations are apparent for the server's domain, and each tool's output feeds naturally into the next step.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources