TrainRouter Atlas

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
With 7 tools, the set is well-scoped for a train atlas server. It covers essential operations without unnecessary bloat.
Completeness5/5
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.
Average 4.8/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 5 of 6 community issues answered or closed in the last 6 months
- 16 commits in the last 12 weeks
- Last stable release on July 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds valuable context: unknown id returns close-match suggestions instead of failing. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence describes the tool's function and output; second sentence provides usage guidance. Every sentence is essential, no fluff, and information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description lists the return fields, which is sufficient. It also covers behavior on unknown id. Given the tool's simplicity (single parameter, read-only, idempotent) and comprehensive annotations, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (1 parameter), so baseline is 3. The description provides additional context for the 'id' parameter beyond the schema, including format (kebab-case), example, and source (search_routes, famous_routes, routes_in_country). This adds meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full record for one atlas route by exact id' and enumerates the specific fields (distance, fastest time, etc.), distinguishing it from sibling tools like search_routes which would be used for name-based lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides when to use this tool vs. alternatives: 'Use search_routes first when you only have a name or city.' Also explains behavior for unknown id (returns up to 5 close-match suggestions), which helps the agent decide how to handle edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures beyond annotations: figures are sampled from public schedule data (not live), treat as planning estimates, direction-insensitive. Annotations already indicate read-only and idempotent, and description adds important context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose. Every sentence adds value: core function, output summary, data source caveat, and error handling. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers all needed aspects: purpose, data type, limitations, and error behavior. Completely sufficient 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already has 100% coverage with descriptions. Description adds that both parameters are city names only (no station needed), accent-insensitive, and that the tool is direction-insensitive, significantly aiding correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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, listing specific details (fastest/typical duration, direct trains, operators, atlas routes) and European coverage. It distinguishes from siblings like search_routes and famous_routes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (for journey facts between two cities) and what happens for uncovered pairs (error with search_routes tip). No explicit when-not-to-use, but alternative is clearly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint and idempotentHint, indicating safe read operation. Description adds context: sorted by renown, returns per-city night-train guide URL when exists. No contradictions, and adds value 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficiently conveys all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool, description covers what it returns (routes sorted by renown, URL if exists), how to filter, and use cases. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description of 'city' parameter. Description adds semantic nuance: filter matches routes starting or ending in given city, not just containing. This enhances understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists sleeper routes sorted by renown, with optional city filtering. It distinguishes from siblings by explicitly naming city_pair for concrete A-to-B times and search_routes for other route categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use for overnight and sleeper questions' and provides alternatives: 'city_pair for concrete A-to-B times; search_routes for other route categories.' This offers clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![trainrouter-atlas MCP server](https://glama.ai/mcp/servers/Flightmussy/trainrouter-atlas/badges/card.svg)](https://glama.ai/mcp/servers/Flightmussy/trainrouter-atlas)

Score Badge

Copy to your README.md:

[![trainrouter-atlas MCP server](https://glama.ai/mcp/servers/Flightmussy/trainrouter-atlas/badges/score.svg)](https://glama.ai/mcp/servers/Flightmussy/trainrouter-atlas)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Flightmussy/trainrouter-atlas'

If you have feedback or need assistance with the MCP directory API, please join our Discord server