The world railway atlas as MCP tools: 744+ legendary train routes, night trains, journey times.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.7/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: overview stats, city pair journey info, famous routes list, full route details, sleeper routes, routes by country, and free-text search. No overlap in functionality.
Names follow a consistent snake_case style and are descriptive. Minor inconsistency: 'get_route' uses a verb-noun pattern while others like 'city_pair' are noun-noun, but overall predictable.
Seven tools is well-scoped for a train atlas server, covering overview, search, specific queries, country, city pair, night trains, and famous routes without being excessive.
Covers key operations: overview, search, detail, country, city pair, night trains, famous routes. Missing direct route-by-category or regional groupings, but search with filters compensates. No dead ends.
atlas_statsAtlas coverage statsAOne-call snapshot of what the TrainRouter atlas covers: total route count, countries, combined length in km, the category list, number of city-pair guides, data snapshot date, and direct URLs to the main browse pages (world map, all routes, Europe/USA maps, night trains, scenic, by-country, city-to-city). Takes no parameters. Call it to learn what this server can answer, to cite dataset totals, or to link a browse page — it returns no individual routes; use search_routes or famous_routes for those.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value by clarifying the scope (what is returned and what is not) and that it takes no parameters. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is well-structured and front-loaded with the key purpose. Every part adds value, though it is slightly lengthy but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains what is returned (various stats and URLs) and what is not (individual routes). It covers the tool's purpose comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description doesn't need to elaborate on parameters. Baseline 4 is appropriate as there is no need for parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 'snapshot of what the TrainRouter atlas covers' and lists specific data points (route count, countries, etc.). It distinguishes from siblings by stating it returns no individual routes and names alternatives like search_routes and famous_routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to call: 'to learn what this server can answer, to cite dataset totals, or to link a browse page'. It also says what not to use it for: 'it returns no individual routes; use search_routes or famous_routes for those.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
city_pairCity-to-city by trainAJourney facts between two cities (European coverage): fastest and typical duration, whether direct trains run, fewest changes, operators and the guide URL — plus legendary atlas routes on that corridor. Direction-insensitive. Figures are sampled from public schedule data, not live times — treat as planning estimates. An uncovered pair returns an error with a search_routes tip.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Destination city, e.g. "Paris". | |
| from | Yes | Origin city, e.g. "London". City name only, no station needed; accent-insensitive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant value beyond annotations: it states data is 'sampled from public schedule data, not live times – treat as planning estimates,' specifies direction-insensitivity, and describes error handling. This provides behavioral context that readOnlyHint and idempotentHint cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. Core information is front-loaded, making it easy to scan. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully lists what the tool returns (fastest/typical duration, direct trains, fewest changes, operators, guide URL, atlas routes) and explains error behavior. For a small tool with 2 parameters, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description enhances by noting 'City name only, no station needed; accent-insensitive,' which adds meaning beyond the schema's example values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides journey facts between two European cities, including duration, directness, operators, guide URL, and legendary atlas routes. The verb 'journey facts' is specific and the resource is well-defined. It distinguishes from siblings like search_routes (mentioned as fallback) and famous_routes (likely lists notable routes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use: to get journey facts between two cities. It also explains error behavior (uncovered pair returns an error with a tip to use search_routes) and mentions direction-insensitivity. It does not explicitly list alternatives or when-not-to-use, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
famous_routesMost famous train routesAThe world's most famous train journeys in TrainRouter's renown order (rank 1 = most famous: Trans-Siberian, Glacier Express, Orient Express lineage, Shinkansen…), as compact facts with id and URL per route. Best first call for bucket-list and "greatest train trips" questions; use search_routes to find something specific, get_route for full detail on one route.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many top-ranked routes. Default 25, max 100. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint true, so no safety issues. Description adds context that it returns compact facts in renown order with rank 1 being most famous, which is helpful behavioral insight beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences: first describes what the tool does and the ordering, second provides usage guidance. Every word adds value, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no output schema), the description fully covers what is returned (id and URL per route), the ordering, and how it fits with sibling tools. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters (limit) with description. Description does not add extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns a ranked list of famous train journeys with id and URL per route. It distinguishes itself from siblings by indicating use for bucket-list questions, while search_routes and get_route handle specific searches and details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Best first call for bucket-list and greatest train trips questions.' Also specifies when not to use and gives alternatives: 'use search_routes to find something specific, get_route for full detail on one route.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_routeGet one route in fullAFull record for one atlas route by exact id: distance, fastest time, top speed, operator, rolling stock, opening year, ridership, story, on-route sights, photo and page URL, plus country-hub links. An unknown id returns up to 5 close-match suggestions instead of failing. Use search_routes first when you only have a name or city.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Exact route id in kebab-case, e.g. "glacier-express" — take it from search_routes, famous_routes or routes_in_country results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds useful behavior: unknown id returns up to 5 close-match suggestions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Lists returned fields first, then edge-case behavior and usage guidance. Concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter, annotations cover safety. Description fully explains return fields, error handling, and when to use alternatives. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description enriches the parameter by specifying format (kebab-case) and source (search_routes, famous_routes, routes_in_country).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get' and resource 'route in full', specifies exact id lookup. Distinguishes from sibling search_routes by stating it requires exact id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use search_routes first when only a name or city is known, and explains that unknown id returns suggestions instead of failing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
night_trainsNight trains / sleepersASleeper routes from the atlas, sorted by renown — all of them by default, or only those starting or ending in a given city — with the per-city night-train guide URL when one exists. Use for overnight and sleeper questions; city_pair for concrete A-to-B times; search_routes for other route categories.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional city filter matched against route endpoints (accent-insensitive), e.g. "Vienna". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description does not need to cover safety. It adds behavioral context: results are sorted by renown, city filter affects endpoints, and output includes a URL when available. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core functionality in the first sentence and usage guidance in the second. Every word contributes to understanding, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single optional parameter, no output schema, clear annotations), the description covers purpose, filtering, output hints, and usage guidance. It is fully sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'city' is already described in the schema. The description reinforces that the filter matches route endpoints and adds details like accent-insensitivity and that it filters for routes starting or ending in the city, adding semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns sleeper routes sorted by renown, with optional city filtering and inclusion of a per-city guide URL. It distinguishes itself from siblings by specifying its use case for overnight/sleeper questions and pointing to alternatives like city_pair and search_routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool ('Use for overnight and sleeper questions') and when to use alternatives ('city_pair for concrete A-to-B times; search_routes for other route categories'). This provides explicit guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
routes_in_countryTrain routes in a countryAEvery atlas route crossing one country, sorted by renown, plus that country's trainrouter.com hub URL when it exists. An unrecognised country returns an error, not an empty list. Use for "trains in X" questions; use search_routes to combine a country with text or category filters, night_trains for sleepers only.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country name or 2-letter ISO code, e.g. "Japan" or "JP". Accent-insensitive; unambiguous partial names resolve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. Description adds details: sorted by renown, returns error for unrecognized country, and hub URL inclusion. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with action and key details, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Coverage includes use case, error behavior, sorting, and hub URL. No output schema needed; annotations cover safety. Complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and includes detailed parameter description. Description does not add new parameter info beyond what schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists atlas routes crossing one country, sorted by renown, and includes optional hub URL. Distinguishes from siblings by naming search_routes and night_trains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for 'trains in X' questions and provides alternatives: search_routes for text/filter combinations, night_trains for sleepers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_routesSearch train routesAFree-text search over every route in the TrainRouter atlas — matches route name, cities, train name, operator and countries, with optional category/country filters. Accent-insensitive; every word of the query must match. Returns compact per-route facts with id and trainrouter.com URL, sorted by renown with route-name matches first; with no query it lists the whole atlas by renown. Use get_route with a returned id for full detail, famous_routes for a ready-made top list, city_pair for A-to-B journey times.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max routes returned. Default 10, max 50. | |
| query | No | Free text matched against name, cities, train, operator and countries — e.g. "glacier", "Tokyo", "Amtrak". Omit to browse all routes by renown. | |
| country | No | Only routes crossing this country — full name or 2-letter ISO code ("Switzerland" or "CH"). | |
| category | No | Only routes in this category. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only and idempotent nature. The description adds valuable behavioral details: accent-insensitive matching, all-words-must-match rule, sorting by renown with route-name matches first, and output format (id and URL).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at ~120 words, well-structured with core function first, then details, then usage guidance. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately explains return format (compact facts with id and URL), sorting, and filter behavior. Combined with sibling references, it provides complete context for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds operational semantics not in schema: accent-insensitive, all-words-must-match, and behavior with no query. This supplements the schema effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does free-text search over routes in the TrainRouter atlas, matching multiple fields. It distinguishes from siblings like get_route and city_pair by specifying its role as a search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (free-text search, browsing all routes) and when to use alternatives (get_route for detail, famous_routes for top list, city_pair for journey times). Also explains behavior with no query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.