The world railway atlas as MCP tools: notable train routes, night trains, journey times.
Scored across 7 tools
Each tool addresses a distinct query type: overview stats, city-to-city journey facts, famous routes, single route detail, night trains, country-specific routes, and free-text search. No two tools overlap in purpose; even the route-listing tools (famous, night, country, search) are clearly differentiated by filter and intent.
The naming is a mix of verb_prefix (get_route, search_routes) and noun-phrase conventions (city_pair, famous_routes, night_trains, routes_in_country, atlas_stats). While readable and descriptive, the lack of a consistent verb_noun pattern is a minor inconsistency.
Seven tools is well within the ideal range for a domain-specific data server. Each tool covers a distinct browsing or search need without redundancy, so the count feels appropriate.
The tool surface covers the core operations for a train atlas: overview, search, specific route detail, thematic lists (famous, night), country filtering, and city-pair journey planning. There are no obvious gaps for the read-only nature of the server; even categories are accessible via search_routes filters.
One-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.
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. |
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.
The 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.
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. |
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.
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". |
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.
Every 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.
Free-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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_routes1 field changedInput schema / properties / category / enumPrevious value: -[
- "high-speed",
- "classic",
- "night",
- "scenic",
- "heritage",
- "funicular",
- "luxury"
-]New value: +[
+ "high-speed",
+ "classic",
+ "night",
+ "scenic",
+ "heritage",
+ "mountain",
+ "luxury"
+]search_routes1 field changedInput schema / properties / category / enumPrevious value: -[
- "high-speed",
- "classic",
- "night",
- "scenic",
- "luxury"
-]New value: +[
+ "high-speed",
+ "classic",
+ "night",
+ "scenic",
+ "heritage",
+ "funicular",
+ "luxury"
+]search_routes1 field changedInput schema / properties / category / enumPrevious value: -[
- "high-speed",
- "classic",
- "night",
- "scenic"
-]New value: +[
+ "high-speed",
+ "classic",
+ "night",
+ "scenic",
+ "luxury"
+]city_pair2 fields changedInput schema / properties / from / descriptionPrevious value: -"Origin city, e.g. \"London\""New value: +"Origin city, e.g. \"London\". City name only, no station needed; accent-insensitive."Input schema / properties / to / descriptionPrevious value: -"Destination city, e.g. \"Paris\""New value: +"Destination city, e.g. \"Paris\"."famous_routes1 field changedInput schema / properties / limit / descriptionPrevious value: -"How many (default 25, max 100)"New value: +"How many top-ranked routes. Default 25, max 100."get_route1 field changedInput schema / properties / id / descriptionPrevious value: -"Route id, e.g. \"glacier-express\""New value: +"Exact route id in kebab-case, e.g. \"glacier-express\" — take it from search_routes, famous_routes or routes_in_country results."night_trains1 field changedInput schema / properties / city / descriptionPrevious value: -"Optional city, e.g. \"Vienna\""New value: +"Optional city filter matched against route endpoints (accent-insensitive), e.g. \"Vienna\"."routes_in_country1 field changedInput schema / properties / country / descriptionPrevious value: -"Country name or ISO code, e.g. \"Japan\" or \"JP\""New value: +"Country name or 2-letter ISO code, e.g. \"Japan\" or \"JP\". Accent-insensitive; unambiguous partial names resolve."search_routes4 fields changedInput schema / properties / category / descriptionPrevious value: -"Filter by route category"New value: +"Only routes in this category."Input schema / properties / country / descriptionPrevious value: -"Country name or ISO code (e.g. \"Switzerland\" or \"CH\")"New value: +"Only routes crossing this country — full name or 2-letter ISO code (\"Switzerland\" or \"CH\")."Input schema / properties / limit / descriptionPrevious value: -"Max results (default 10, max 50)"New value: +"Max routes returned. Default 10, max 50."Input schema / properties / query / descriptionPrevious value: -"Free text: route name, city, train or operator (e.g. \"glacier\", \"Tokyo\", \"Amtrak\")"New value: +"Free text matched against name, cities, train, operator and countries — e.g. \"glacier\", \"Tokyo\", \"Amtrak\". Omit to browse all routes by renown."atlas_statscity_pairfamous_routesget_routenight_trainsroutes_in_countrysearch_routesTravelMind: 8 MCP tools for travel (12306 trains, flights, hotels, geocode, planning, policy).
Monitor European train stations
Plan journeys by train, bus, tram, metro and ferry across 42 European countries.
Global scheduled passenger flight routes: which exist, direct or connecting, and days flown.