japan-rail-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_provider_statusA | Use before live train queries to see which read-only capabilities are configured and why unavailable capabilities are disabled. |
| search_stationsA | Use this before search_trains whenever no canonical station ID is known. Returns candidates for Japanese, English, and common romanized names without silently resolving ambiguous inputs such as Osaka or Fukuoka. |
| search_trainsA | Use after resolving both station IDs. Searches direct Shinkansen services only, never transfer journeys. Requires an explicit date; optional time, service, and operator filters are applied before pagination. |
| get_train_detailsA | Use with the opaque trainId returned by search_trains to retrieve that service and its ordered stops. Do not construct train IDs manually. |
| get_availabilityA | Use only to check whether the configured provider exposes seat inventory for an exact train and station pair. The default provider returns an explicit unsupported status and never fabricates inventory. |
| compare_trainsB | Use to sort structured direct-train candidates by departure, arrival, duration, or total fare. This tool does not make a subjective recommendation. |
| search_journeysA | Use for routes that may include transfers, not for an individual train. The Shinkansen-first v0.1 provider reports this capability as unsupported rather than returning direct trains under the wrong concept. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool has a clearly distinct purpose: provider status, station search, direct train search, journey search with transfers, train details, availability check, and comparison. No two tools overlap in function; even search_trains and search_journeys are explicitly separated by transfer handling.
All tool names follow a consistent verb_noun pattern (get_, search_, compare_) with snake_case throughout. The naming is predictable and aligns with the domain verbs expected (get, search, compare).
With 7 tools, the server is well-scoped for a read-only Japan rail information service. Each tool covers a distinct aspect of the domain without unnecessary duplication, fitting the typical 3-15 tool range perfectly.
The tool surface covers the core journey: station lookup, train search (direct and transfers), train details, availability, and comparison. Minor gaps exist like a dedicated fare breakdown or station details, but the essential read-only workflow is fully supported.