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 World Train Map 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, idempotentHint, so the safety profile is covered. The description adds value by detailing the specific data fields returned (route count, countries, length, category list, etc.) and confirming it is a one-call snapshot with no parameters, which goes beyond the annotations. A minor gap is lack of detail about error scenarios or response format, but for this simple tool the description is sufficient.
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, well-structured sentence that front-loads the core purpose ('One-call snapshot...') and then enumerates specific contents. Every clause adds useful information, with no redundancy or fluff. The sentence earns its length by covering purpose, contents, usage, and alternatives.
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?
For a zero-parameter tool with no output schema, the description fully compensates by listing exactly what the return value contains (totals, categories, URLs) and directing to sibling tools for other needs. It provides complete context for an agent to decide when and how to use this 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?
The tool has zero parameters, and the description explicitly states 'Takes no parameters.' Since there is no parameter complexity to document, the baseline of 4 applies; the description efficiently confirms parameter absence.
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 states a specific verb ('Call it to learn...') and clearly defines the tool's output: a snapshot of atlas coverage statistics and browse page URLs. It also distinguishes itself from siblings by explicitly noting it returns no individual routes and directing users to search_routes or famous_routes for those.
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?
Provides explicit when-to-use guidance: 'Call it to learn what this server can answer, to cite dataset totals, or to link a browse page.' It also gives an exclusion and alternative: 'it returns no individual routes; use search_routes or famous_routes for those.' This is exemplary usage direction.
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 World Train Map'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, so the bar is lower. The description adds meaningful context: the ordering is based on 'World Train Map's renown order,' and the output is 'compact facts with id and URL per route.' It also implies a bounded list (top-ranked) without full search capability, consistent with openWorldHint=false. It doesn't detail the exact structure but is adequate for a simple read-only list.
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-loaded with the main purpose and ranking criteria, then provides clear usage guidance. Every phrase adds value—no filler or 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?
For a simple list tool with one optional parameter, strong annotations, and no output schema, the description is complete. It specifies the ranking, return fields (id and URL), and directs users to siblings for other needs. No critical information is missing.
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% for the single optional 'limit' parameter, which already includes a description ('How many top-ranked routes. Default 25, max 100'). The description does not add further parameter semantics, so the baseline of 3 applies.
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 'the world's most famous train journeys' in a specific ranking order, with 'compact facts with id and URL per route.' It uses a specific verb and resource, and immediately distinguishes itself from siblings like search_routes and get_route by describing its unique scope and ordering.
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?
Explicit usage guidance is provided: 'Best first call for bucket-list and "greatest train trips" questions' and alternatives are named: 'use search_routes to find something specific, get_route for full detail on one route.' This fully addresses when to use the tool versus alternatives.
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 worldtrainmap.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?
The description discloses that an unrecognised country returns an error rather than an empty list, and mentions the inclusion of the hub URL. While annotations already indicate read-only and idempotent behavior, this extra error-handling detail adds valuable context 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 sentences, front-loaded with the core function, then usage guidance. Every sentence earns its place with no redundancy or 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?
The description provides enough context for a simple one-parameter read-only tool: what is returned (routes, hub URL), sorting order, error behavior, and alternatives. No output schema exists, but the description sufficiently covers the return content and edge cases.
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 input schema already fully describes the single 'country' parameter with examples and details (accent-insensitive, partial names). The description adds no new parameter-level semantics, but the schema coverage is 100%, so the baseline 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?
The description clearly states the tool lists all atlas routes crossing one country, sorted by renown, and explicitly distinguishes itself from siblings by mentioning search_routes and night_trains. The verb+resource is specific and unambiguous.
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?
It provides direct usage guidance: use for "trains in X" questions, and explicitly names alternative tools (search_routes for combined filters, night_trains for sleepers), making it easy to decide when to use this tool over others.
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 World Train Map 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 worldtrainmap.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 only declare readOnlyHint and idempotentHint, but the description adds rich behavioral details: accent-insensitive matching, every-word-must-match semantics, sorting by renown with route-name matches first, no-query behavior, and the output format (compact per-route facts with id and URL). No contradiction with 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?
Three dense sentences with no filler. The first sentence establishes scope and filters, the second covers matching and output, and the third gives usage guidance. The structure front-loads the key information.
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?
For a search tool with no output schema, the description covers what fields are matched, how filtering works, result format, sorting, no-query behavior, and provides follow-up tool suggestions. The only remaining detail (limit constraints) is already in the schema. Complete enough for an agent to use 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%, but the description significantly enriches parameter meaning by explaining matching semantics (accent-insensitive, every word must match), sorting behavior, and that omitting the query browses all routes. This goes beyond the schema's property descriptions.
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 this is a free-text search over every atlas route, enumerates the matched fields (name, cities, train name, operator, countries), and lists optional filters. It distinguishes itself from siblings by explicitly pointing to get_route, famous_routes, and city_pair for other use cases.
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 says when to use this tool and names alternatives: use get_route for full detail, famous_routes for a ready-made top list, and city_pair for A-to-B journeys. It also explains no-query behavior. However, it doesn't mention the sibling routes_in_country or night_trains, so it's not fully exhaustive.
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.