atlas
Server Details
The world railway atlas as MCP tools: 744+ legendary train routes, night trains, journey times.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.6/5 across 7 of 7 tools scored.
Most tools have distinct purposes, but multiple tools return routes sorted by renown (famous_routes, search_routes with no query, routes_in_country), which could cause confusion. However, each has a unique filter or scope, so some ambiguity but mostly clear.
Names are consistently snake_case and descriptive, with a mix of verb_noun (get_route, search_routes) and noun_phrase (city_pair, night_trains). The pattern is mostly consistent, though atlas_stats deviates slightly but is acceptable.
7 tools is well within the ideal range and covers the main operations needed for a train atlas: stats overview, search, specific queries by ID, country, night trains, and city pairs. No extra clutter.
The tool set provides comprehensive coverage for a read-only atlas: metadata, search, filtering by various criteria, detailed route info, and city-pair queries. No obvious missing functionality for its stated purpose.
Available Tools
7 toolsatlas_statsAtlas coverage statsARead-onlyIdempotentInspect
One-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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds specific return fields (route count, countries, URLs, etc.) and confirms no parameters. This is valuable context beyond the annotations, though not critical.
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 three sentences with no wasted words. It front-loads the main purpose, then explains use cases and what the tool does not do, achieving high efficiency.
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 thoroughly lists what the tool returns. Coupled with strong annotations (readOnly, idempotent), the description is complete for a stat snapshot 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 schema has no parameters with 100% coverage. The description states 'Takes no parameters,' which matches the schema exactly. No additional meaning is added, 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?
The description clearly states the tool returns a 'snapshot of what the TrainRouter atlas covers' with specific fields. It explicitly distinguishes from siblings like search_routes and famous_routes by stating it returns no individual 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 gives explicit use cases: 'Call it to learn what this server can answer, to cite dataset totals, or to link a browse page.' It also specifies when not to use it by directing to sibling tools for individual routes.
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 trainARead-onlyIdempotentInspect
Journey 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent hints. The description adds critical behavioral context: figures are sampled, not live times, and the tool is direction-insensitive. 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 concise, front-loading key information, with no unnecessary words. Each sentence adds value.
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 adequately explains return values and error behavior. Combined with annotations, it provides complete context for a simple two-parameter 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 description coverage is 100% with clear descriptions for 'from' and 'to'. Description adds context about direction-insensitivity and city-only input, enhancing parameter understanding slightly beyond 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 clearly states it provides 'journey facts between two cities' with specific outputs (duration, direct trains, changes, operators, guide URL, legendary atlas routes). It specifies European coverage and direction-insensitivity, distinguishing it from sibling tools.
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?
Description advises that data is sampled and not live, treat as planning estimates. It mentions errors for uncovered pairs and suggests using search_routes. This gives clear context, though it doesn't explicitly exclude non-European or real-time use.
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 routesARead-onlyIdempotentInspect
The 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. Description adds context about output being compact facts with id and URL, and ordering by renown. While not covering every behavioral aspect, it provides useful additional 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 concise sentences that front-load the core purpose and immediately provide usage context. No unnecessary words.
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 list tool with one optional parameter and no output schema, the description is fully complete: it explains what is listed, the ordering, the output fields, and how to use it relative to siblings.
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 only parameter 'limit' is fully described in the schema. The description adds no extra meaning beyond the schema's description. Schema coverage is 100%, 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?
The description clearly states it lists the world's most famous train journeys ranked by renown, with compact facts (id and URL). It distinguishes from siblings by explicitly naming search_routes and get_route for other purposes.
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 it is the best first call for bucket-list and 'greatest train trips' questions, and directs to search_routes for specific queries and get_route for full details on a single 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 fullARead-onlyIdempotentInspect
Full 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that an unknown id returns close-match suggestions instead of failing, which goes beyond the readOnlyHint and idempotentHint annotations. Also lists the fields returned, adding valuable behavioral context.
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 wasted words. The first sentence front-loads the purpose and contents, while the second adds behavioral detail and usage guidance.
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 retrieval tool with one parameter and no output schema, the description covers return fields, error behavior, and when to use sibling tools, making it fully complete and actionable.
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 a descriptive parameter description including example and source. The description reiterates 'by exact id' but does not add new semantic meaning 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 clearly states the tool returns the full record for one atlas route by exact id, listing specific fields. It distinguishes from siblings like search_routes by indicating when to use each.
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 search_routes first when only a name or city is available, and explains behavior for unknown ids, providing clear context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
night_trainsNight trains / sleepersARead-onlyIdempotentInspect
Sleeper 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". |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral context: results are sorted by renown, include per-city night-train guide URL if it exists, and filtering is accent-insensitive. No contradictions. Could mention empty result behavior, but overall 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?
Two efficiently written sentences that front-load the main purpose and include usage guidance. Every sentence adds value 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?
For a simple tool with one optional parameter and no output schema, the description covers purpose, usage, filter behavior, and output characteristics. It is complete enough for an AI agent to correctly select and invoke the 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% with a clear parameter description. The description adds that the city filter applies to 'starting or ending' routes, which clarifies the filter's scope beyond the schema's 'matched against route endpoints'.
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 that the tool returns sleeper routes from the atlas, sorted by renown, with optional city filter and per-city guide URL. It distinguishes itself from siblings like city_pair and search_routes, making its purpose explicit.
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 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'), providing clear usage guidance.
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 countryARead-onlyIdempotentInspect
Every 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds that an unrecognised country returns an error (not empty list) and mentions sorting and hub URL. 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: first explains output, second gives usage guidance. No extraneous content, front-loaded with essential 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 simple tool with one parameter, the description covers purpose, behavior, error handling, sorting, and hub URL. Complete given the complexity and rich annotations.
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 a thorough parameter description. The tool description does not add further parameter information, which is acceptable; 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?
The description clearly states the tool returns every atlas route crossing a country, sorted by renown, plus a hub URL if available. It distinguishes from siblings like search_routes and night_trains. The verb and resource are specific.
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 instructs to use for 'trains in X' questions and directs to alternatives: search_routes for combined filters, night_trains for sleepers only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_routesSearch train routesARead-onlyIdempotentInspect
Free-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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds significant behavioral context beyond annotations: accent-insensitive, every word must match, sorted by renown with route-name matches first, default limit 10, max 50, returns compact facts with id and URL, and lists all when no query. 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?
Extremely concise: two sentences covering main functionality and one sentence directing to sibling tools. Front-loaded with core behavior, 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 clearly states what is returned (compact per-route facts with id and URL). Combined with high-quality schema and annotations, the tool is fully specified for correct usage.
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 description adds helpful examples (e.g., 'glacier', 'Tokyo', 'Amtrak') for the query parameter and clarifies country as full name or ISO code. Adds value beyond schema definitions.
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 specifies the tool's purpose as a free-text search over routes, listing the fields searched (name, cities, train name, operator, countries) and explicitly distinguishes itself from siblings like get_route, famous_routes, and city_pair.
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 (free-text search, optional filters, browse all by omitting query) and when-not-to-use directions (use get_route for details, famous_routes for top list, city_pair for A-to-B times). Also notes accent-insensitivity and matching rule.
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.
Discussions
No comments yet. Be the first to start the discussion!