The TrainRouter Atlas server lets you explore a curated dataset of the world's most legendary train routes through the following tools:
Search train routes: Free-text search across route names, cities, train names, operators, and countries, with optional filters by category (high-speed, classic, night, scenic) or country.
Get full route details: Retrieve the complete record for a specific route by ID, including distance, journey time, top speed, operator, rolling stock, opening year, ridership, highlights, and a link to its TrainRouter page.
Browse the most famous routes: Get a ranked list of the world's most famous train journeys (e.g. Trans-Siberian, Glacier Express, Shinkansen) in order of renown.
Find routes in a country: List all atlas routes that pass through a given country, sorted by renown, along with the country's TrainRouter hub URL.
Find night trains / sleepers: Browse sleeper and overnight train routes, optionally filtered by departure or arrival city.
Look up city-to-city journey facts: Get planning-level journey information between two cities (European coverage), including duration, direct services, fewest changes, operators, and legendary routes on that corridor.
Get atlas statistics: Retrieve a snapshot of total routes, countries, combined distance, categories, and links to key browse pages.
961 train routes · 118 countries · ≈ 432,800 km of route, every route with its key facts and its geometry, from worldtrainmap.com, the interactive world railway map.
High-speed spines (Eurostar, TGV, Shinkansen, AVE), classic long-distance runs (Trans-Siberian, California Zephyr), night trains (Nightjet, the Ghan) and the scenic lines people fly in just to ride (Glacier Express, Bernina Express, the Jacobite).
🗺️ Explore it interactively: worldtrainmap.com
🤖 Use it from an AI assistant: free MCP server at https://worldtrainmap.com/mcp (how to connect), or run it from this repo: npm install && npm start (mcp/)
The site was renamed. It was TrainRouter at
trainrouter.comuntil 11 August 2026 and is now World Train Map atworldtrainmap.com. The old domain redirects path for path, so old links still work, andhttps://trainrouter.com/mcpstill answers directly rather than redirecting, because JSON-RPC clients do not follow redirects. Nothing you already had configured has broken. The repository, the Zenodo DOI and the MCP registry name (com.trainrouter/atlas) keep their old identifiers on purpose: renaming them would break more than it would tidy.
Several different route counts are in circulation for this atlas, so here is the honest map of them.
Where | Routes | Cut | Note |
The live site | 1,338 | today | worldtrainmap.com, always the newest |
The MCP server | 1,247 | 11 August 2026 | deployed separately from the site, so it lags it a little |
| 961 | 23 July 2026 | what you get by cloning or downloading here |
Zenodo (the citable DOI) | 744 | 12 July 2026 | release v1.1.0, the last tagged one |
Why the download is behind the site, and it is deliberate. Since late July the route geometry has been progressively re-traced from OpenStreetMap railway relations, which makes it a derivative of OSM data under ODbL, while this package is licensed CC BY 4.0 throughout. Publishing a refresh before the licence is split per route would ship a licence violation with our name on it, so the exporter is blocked until that work lands. See Sources, accuracy & provenance below. If you want something fresher than the July cut without waiting, the MCP server is the closest available.
Related MCP server: db-fahrplan-mcp
File | Contents |
| One row per route, all facts, no geometry |
| Same records with structured country objects |
|
|
Field | Type | Notes |
| string | Stable slug, e.g. |
| string | Route/service name |
| string | Terminus cities |
| enum | In this cut: |
| string | Rolling stock, e.g. |
| string | Operating company |
| number | Route length |
| number | Service top speed |
| string | Published journey time, e.g. |
| number | Year the line/service entered service |
| number|null | Approx. annual ridership where published, which is rare: 80 of the 961 rows carry one |
| string |
|
| string | One-line description of what makes the route legendary |
| number | 1 = most famous (the atlas's own renown ranking) |
| string | The route's page. These were written before the rename and still read |
import pandas as pd
routes = pd.read_csv("data/routes.csv")
routes.nsmallest(10, "fame_rank")[["name", "from", "to", "distance_km"]]
import geopandas as gpd
gdf = gpd.read_file("data/routes.geojson")
gdf.plot(column="category", figsize=(16, 8))Provenance changed in late July 2026 — this section was updated 2026-07-31 to say so. The atlas started fully hand-built, and the facts still are: compiled from public references, not from any licensed dataset, so the CC BY 4.0 licence on the facts is the author's to grant.
Geometry: hand-traced originally, OSM-traced increasingly. Each route's LineString began as hand-placed [lon, lat] waypoints following the corridor at map scale. From 23 July 2026 onward, alignments have progressively been re-traced from OpenStreetMap railway ways via Overpass so the lines sit on real track. The files currently in data/ are the 23 July refresh: nearly all of their geometry is still the hand-traced kind, but a handful of corridors (Brenner, Oslo–Göteborg, Oslo–Stockholm, Pustertalbahn) are already OSM-traced, and those lines are © OpenStreetMap contributors, ODbL — as any OSM-derived geometry must be. An earlier version of this README said the geometry was "not extracted from OSM or any geodata source"; that was true when written (v1.0, 12 July) and is no longer true, which is why this notice exists. The next release will mark the split per route: facts CC BY 4.0, geometry ODbL. On the live site that re-tracing has since gone much further, which is why the site's routes and this package's routes are no longer the same lines.
Facts are approximate published values: distance, top speed, journey time, operator, opening year and approximate ridership are compiled from public references (operators' own figures, timetables, press material, encyclopaedic articles). Individual facts like these aren't copyrightable; the licence covers the curated compilation. Good for exploration and visualization, not operations.
Curated, not exhaustive: the world's notable routes, not every line on earth. Route names and the one-line highlights are the author's own wording.
Deliberately excluded (they live only on the site, to keep provenance clean): per-route stories and sights, photos (Wikimedia Commons, separately licensed), and the city-to-city journey guides (derived from public schedule feeds).
Basemap ≠ data: the interactive site renders these routes over OpenFreeMap (OpenStreetMap) tiles; those tiles are not part of this dataset. OSM © OpenStreetMap contributors — which, per the provenance note above, now also covers the OSM-traced route lines themselves.
Facts (every non-geometry field in data/): CC BY 4.0, free to use, share and adapt, with attribution to World Train Map. A link to https://worldtrainmap.com (or the specific route page in url) satisfies attribution. (full notice)
Geometry (LineString coordinates): hand-traced lines as above (CC BY 4.0); OSM-traced lines © OpenStreetMap contributors, ODbL 1.0. If you reuse the geometry wholesale, treat it as ODbL and credit OpenStreetMap, which is the safe default, and will be made explicit per route in the next release.
Code (the MCP server in mcp/): MIT.
Hugging Face: huggingface.co/datasets/Flightmussy/trainrouter-atlas, kept byte for byte in step with data/ here
Kaggle: kaggle.com/datasets/flightmussy/world-train-routes, the two fact files only, because Kaggle allows a dataset one licence label and the geometry is part ODbL
Zenodo (archived, DOI): doi.org/10.5281/zenodo.21322030, the concept DOI, which always resolves to the latest published release (today, v1.1.0)
The Kaggle mirror is new, and it is worth saying why it did not exist before: every earlier version of this README, and the site's own dataset page, linked one at kaggle.com/datasets/albanius/.... That account name has never been ours, and the same wrong id was hard-coded into the mirror-sync workflow, so the link was dead from the day it was written and the automation could not have fixed it. Both are corrected.
World Train Map Atlas: the world's legendary train routes (2026). worldtrainmap.com. DOI: 10.5281/zenodo.21322030. https://github.com/Flightmussy/trainrouter-atlas
The data is generated from the atlas source by an exporter that is currently blocked on purpose, pending the split-licence work described above. That block is why data/ has not moved since 23 July and why the last release is still v1.1.0. Once it is unblocked, new versions land here first, and publishing a GitHub release mints a fresh Zenodo DOI and pushes the mirrors via sync-mirrors.yml, whose jobs each skip themselves when their API token is not configured.
mcp/ — source of the World Train Map MCP server (live at https://worldtrainmap.com/mcp, listed in the Official MCP Registry as com.trainrouter/atlas), which serves the atlas as tools for Claude and other MCP clients. It is deployed from the site's own atlas rather than from data/, so it is well ahead of the files here, though it is redeployed on its own schedule and can sit a little behind the site itself. Its atlas_stats tool reports exactly what it is serving.
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 | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds value by detailing exactly what the snapshot contains (e.g., total route count, countries, URLs) and that it takes no parameters. This enriches agent understanding without contradicting 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?
The description is well-structured and efficient. It front-loads the core purpose, then lists contents and usage guidance. Every sentence serves a purpose without 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 has no parameters and no output schema, the description is remarkably complete. It specifies exactly what is returned (routes, countries, URLs, etc.) and situates it among sibling tools. Nothing essential 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?
There are zero parameters, so the description correctly states 'Takes no parameters.' This is explicit and clear, exceeding the baseline expectation for parameterless tools.
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 provides a 'one-call snapshot' of atlas coverage, listing specific data like route count, countries, and URLs. It distinguishes from siblings by explicitly saying 'it returns no individual routes; use 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?
The description explicitly says when to use the tool: 'to learn what this server can answer, to cite dataset totals, or to link a browse page.' It also tells when not to use it and directs to alternatives: '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.
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 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=true and idempotentHint=true. The description adds context by explaining the output format (compact facts with id and URL) and the ordering (by renown). 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, front-loaded with purpose, no wasted words. Structure is efficient and clear.
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 no output schema, the description sufficiently describes return value (compact facts, id, URL) and provides context with examples (Trans-Siberian, Glacier Express). Gives ranking scheme.
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 covers limit (default 25, max 100) at 100%. Description does not add additional parameter details, 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 returns 'the world's most famous train journeys' in a specific rank order, with compact facts including id and URL. It distinguishes from siblings by naming search_routes and get_route as alternatives for different needs.
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 'Best first call for bucket-list and greatest train trips questions' and provides guidance on when to use 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.
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 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?
Beyond annotations, description reveals sorting by renown, inclusion of hub URL, and error behavior for unrecognized countries. 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 focused sentences: output description, error handling, and usage guidance. No fluff, front-loaded with 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?
Given single parameter, high schema coverage, and no output schema, description adequately explains output structure and error behavior, and directs to alternatives.
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 with detailed description. Description adds error handling context for unrecognized country, going 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?
Description explicitly states it returns atlas routes crossing a country, sorted by renown, plus hub URL, and error for unrecognized country. Clearly distinguishes from siblings like 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?
Provides explicit guidance: use for 'trains in X' questions, and recommends search_routes for combined filters and 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.
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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint. Description adds accent-insensitivity, 'every word must match' constraint, sorting by renown with route-name matches first, and the fallback to listing whole atlas without query. 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?
Packs essential information into one coherent paragraph without fluff. Front-loaded with main action. Could be slightly more structured (e.g., bullet points), but current form is efficient and clear.
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?
Covers all necessary aspects: what it does, how to use, parameter behaviors, sorting, fallback, and links to related tools. Despite no output schema, describes return format (compact per-route facts with id and URL). Fully sufficient for competent use.
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 context about query matching fields and omission behavior (browse all). Does not detail limit maximum (schema handles it), but adds value beyond schema. Baseline 3, plus 1 for extra context.
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 'Free-text search over every route in the TrainRouter atlas' and lists matched fields (name, cities, train, operator, countries). Distinct verbs and resource, with explicit differentiation from siblings like get_route, famous_routes, 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?
Explicitly tells when to use this tool vs alternatives: '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.' 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0atlas_statscity_pairfamous_routesget_routenight_trainsroutes_in_countrysearch_routesScored across 7 tools
Each tool serves a clearly distinct purpose: overview (atlas_stats), journey planning (city_pair), famous routes list (famous_routes), route details (get_route), sleeper filters (night_trains), country routes (routes_in_country), and free-text search (search_routes). No overlapping functionality.
All tool names follow a consistent snake_case pattern with clear verb_noun (get_route, search_routes) or noun_noun (city_pair, night_trains) structures. No mixing of conventions.
With 7 tools, the set is well-scoped for a train atlas server. It covers essential operations without unnecessary bloat.
The tool set provides comprehensive coverage: dataset overview, search, detail retrieval, filtering by country, night trains, and fame, plus city-pair journey info. No obvious gaps for the domain.
Read-only MCP server for wafergraph.com's semiconductor & AI supply-chain data: 30 tools, no auth.
Free, read-only MCP subset of x402 Toolbox's cheap data endpoints, free via MCP.
OpenStreetMap Overpass MCP — programmatic queries against the OSM database
Transitland MCP — global GTFS aggregator