Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NS Travel Information Server what's the next train from Amsterdam Centraal to Utrecht?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Transform your AI assistant into a Dutch railways expert! This MCP server connects Claude to real-time NS (Nederlandse Spoorwegen) travel information, making it your perfect companion for navigating the Netherlands by train.
You can install this server in three ways:
Update your Claude configuration file (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"ns-server": {
"command": "npx",
"args": [
"-y",
"ns-mcp-server"
],
"env": {
"NS_API_KEY": "your_api_key_here"
}
}
}
}You can get an API key from NS API Portal
To install NS Travel Information Server automatically via Smithery:
npx -y @smithery/cli install ns-server --client claudeClone this repository
Install dependencies:
npm installCopy the example environment file:
cp .env.example .envAdd your NS API key to the .env file:
NS_API_KEY=your_api_key_hereThen update your Claude configuration file:
{
"mcpServers": {
"ns-server": {
"command": "node",
"args": [
"/path/to/ns-server/build/index.js"
],
"env": {
"NS_API_KEY": "your_api_key_here"
}
}
}
}Make sure to:
Replace /path/to/ns-server with the actual path to your installation
Add your NS API key in the env section. It can be obtained from here https://apiportal.ns.nl/product#product=NsApp
After updating the configuration, restart Claude Desktop for the changes to take effect.
Related MCP server: NS Travel MCP Server
"Is my usual 8:15 train from Almere to Amsterdam running on time?"
"Are there any delays on the Rotterdam-Den Haag route today?"
"What's the best alternative route to Utrecht if there's maintenance on the direct line?"
"Which train should I take to arrive at my office in Amsterdam Zuid before 9 AM?"
"Which route to Amsterdam has the fewest transfers with a stroller?"
"What's the earliest train I can take to make my 10 AM meeting in The Hague?"
"When's the last train back to Groningen after a night out in Amsterdam?"
"Are there any weekend engineering works that might affect my Monday morning class?"
"Are there OV-fiets bikes available at Utrecht Centraal for my afternoon meeting?"
"Is Eindhoven Strijp-S station wheelchair accessible and what platforms does it have?"
"What trains are arriving at Utrecht Centraal in the next hour?"
"Has the train from Venlo to Schiphol Airport arrived on time?"
"How much does a first-class ticket from Amsterdam to Rotterdam cost?"
"What's the price for 2 adults and 1 child traveling to Den Haag?"
Variable | Description |
NS_API_KEY | Your NS API key (required) |
This MCP server provides comprehensive access to NS train information through the following endpoints:
Departures: Get real-time departure information including platform numbers, delays, and travel notes
Arrivals: Access upcoming train arrivals with origin stations, platform changes, and status updates
Journey Planning: Find optimal travel routes with transfers and real-time updates
Service Updates: Check for disruptions, maintenance work, and engineering activities
Ticket Prices: Get accurate pricing for single and return journeys
Travel Classes: Compare prices for first and second class travel
Group Pricing: Calculate fares for adults and children
Discount Options: Check joint journey discounts and special offers
Validity Details: View ticket validity periods and travel conditions
Station Details: Access comprehensive station information including:
Facilities and accessibility features
Platform layouts and track information
OV-fiets (bike rental) availability
Location and approach details
Multi-language Support: Information available in Dutch and English
Flexible Queries: Search by station name, code, or UIC identifier
Time Zones: Proper handling of time zones for international stations
Status Updates: Track changes, delays, and cancellations in real-time
This project is licensed under the MIT License - see the LICENSE file for details
Get real-time arrival information for trains at a specific station, including platform numbers, delays, origin stations, and any relevant travel notes. Returns a list of upcoming arrivals with timing, origin, and status information.
| Name | Required | Description | Default |
|---|---|---|---|
| station | No | NS Station code for the station (e.g., ASD for Amsterdam Centraal). Required if uicCode is not provided | |
| uicCode | No | UIC code for the station. Required if station code is not provided | |
| dateTime | No | Format - date-time (as date-time in RFC3339). Only supported for arrivals at foreign stations. Defaults to server time (Europe/Amsterdam) | |
| maxJourneys | No | Number of arrivals to return | |
| lang | No | Language for localizing the arrivals list. Only a small subset of text is translated, mainly notes. Defaults to Dutch | nl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's function and output format, but lacks details on potential limitations (e.g., rate limits, data freshness, error handling) or prerequisites (e.g., authentication needs). The description does not contradict any annotations, as none are provided.
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 appropriately sized and front-loaded, with the first sentence clearly stating the core purpose. Both sentences earn their place by adding value: the first defines the tool's function and scope, and the second specifies the return format. There is no redundant or wasted 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 the tool's moderate complexity (5 parameters, no output schema, no annotations), the description is reasonably complete. It covers the tool's purpose, scope, and return format, but could improve by addressing behavioral aspects like rate limits or error handling. The lack of an output schema means the description's detail on return values is helpful, though not exhaustive.
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%, so the input schema already documents all parameters thoroughly. The description does not add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't clarify station code formats or date-time usage). However, it implies the tool's purpose aligns with the parameters, maintaining the baseline score for high schema coverage.
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's purpose with specific verbs ('Get real-time arrival information') and resources ('trains at a specific station'), distinguishing it from siblings like get_departures (which handles departures) and get_station_info (which provides static station details). It explicitly mentions what information is included (platform numbers, delays, origin stations, travel notes) and the return format (list of upcoming arrivals).
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 implies usage context by specifying 'real-time arrival information for trains at a specific station,' which helps differentiate it from siblings like get_disruptions (disruption info) or get_travel_advice (route planning). However, it does not explicitly state when NOT to use this tool or name specific alternatives, such as using get_departures for departure data instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current server time (Europe/Amsterdam timezone) in RFC3339 format. This can be used as input for other tools that require date-time parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states this is a read operation that returns current time in a specific format and timezone, but doesn't mention potential limitations like rate limits, authentication requirements, or whether the time is synchronized with atomic clocks.
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 zero waste - the first states the core functionality with precise specifications, the second provides practical usage context. Every word serves a clear purpose in helping an agent understand and use this tool.
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 annotations and no output schema, the description provides excellent context about what the tool does, the format it returns, and its practical application. It could be slightly more complete by explicitly stating the return type or format details, but it's very effective given the tool's simplicity.
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 with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose and output format.
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 specific action ('Get'), resource ('current server time'), and format ('RFC3339 format') with precise timezone specification ('Europe/Amsterdam timezone'). It distinguishes itself from sibling tools by focusing on time retrieval rather than transportation data.
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 provides clear context about when to use this tool ('This can be used as input for other tools that require date-time parameters'), but doesn't explicitly mention when not to use it or name specific alternative tools for time-related functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get real-time departure information for trains from a specific station, including platform numbers, delays, route details, and any relevant travel notes. Returns a list of upcoming departures with timing, destination, and status information.
| Name | Required | Description | Default |
|---|---|---|---|
| station | No | NS Station code for the station (e.g., ASD for Amsterdam Centraal). Required if uicCode is not provided | |
| uicCode | No | UIC code for the station. Required if station code is not provided | |
| dateTime | No | Format - date-time (as date-time in RFC3339). Only supported for departures at foreign stations. Defaults to server time (Europe/Amsterdam) | |
| maxJourneys | No | Number of departures to return | |
| lang | No | Language for localizing the departures list. Only a small subset of text is translated, mainly notes. Defaults to Dutch | nl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns real-time information with a list of upcoming departures, including timing, destination, and status, which covers basic behavior. However, it lacks details on rate limits, authentication needs, error handling, or data freshness, which are important for a real-time API tool.
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 front-loaded with the core purpose in the first sentence, followed by additional details in a second sentence. Every sentence adds value without redundancy, and it is appropriately sized for a tool with 5 parameters and no annotations.
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 complexity (real-time data fetching with 5 parameters) and lack of annotations or output schema, the description provides a good overview of what the tool does and returns. However, it could be more complete by mentioning potential limitations (e.g., data availability for foreign stations) or response structure details, which would help compensate for the missing output schema.
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%, so the schema already documents all parameters thoroughly. The description does not add any parameter-specific semantics beyond what the schema provides (e.g., it doesn't explain station code formats or date-time usage further). Baseline 3 is appropriate as the schema does the heavy lifting.
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 specific action ('Get real-time departure information') and resource ('trains from a specific station'), distinguishing it from siblings like get_arrivals (arrivals vs. departures) and get_station_info (station metadata vs. departure data). It specifies the scope includes platform numbers, delays, route details, and travel notes.
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 implies usage context by specifying 'real-time departure information for trains from a specific station,' which distinguishes it from tools like get_disruptions (general disruptions) or get_travel_advice (route planning). However, it does not explicitly state when not to use it or name alternatives, such as clarifying that get_arrivals is for incoming trains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive information about current and planned disruptions on the Dutch railway network. Returns details about maintenance work, unexpected disruptions, alternative transport options, impact on travel times, and relevant advice. Can filter for active disruptions and specific disruption types.
| Name | Required | Description | Default |
|---|---|---|---|
| isActive | No | Filter to only return active disruptions | |
| type | No | Type of disruptions to return (e.g., MAINTENANCE, DISRUPTION) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some context by mentioning the tool 'can filter for active disruptions and specific disruption types,' which hints at filtering capabilities beyond the schema. However, it lacks details on rate limits, authentication needs, or what happens if no disruptions exist, leaving gaps in behavioral understanding for an agent.
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 appropriately sized and front-loaded, starting with the core purpose and followed by details on returns and filtering. Every sentence earns its place by adding value, such as listing returned information and filtering options, without redundancy or unnecessary elaboration.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the purpose and filtering but lacks details on output format, error handling, or how disruptions are structured, which could hinder an agent's ability to use it effectively without further context.
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 description coverage is 100%, so the schema already fully documents the two parameters (isActive and type). The description adds marginal value by mentioning filtering for 'active disruptions and specific disruption types,' which aligns with the schema but does not provide additional syntax or format details beyond what the schema specifies. This meets the baseline for high schema coverage.
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's purpose with specific verbs ('Get comprehensive information') and resources ('current and planned disruptions on the Dutch railway network'), distinguishing it from sibling tools like get_arrivals or get_departures which focus on different railway data. It explicitly lists the types of information returned (maintenance work, unexpected disruptions, etc.), making the scope 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?
The description provides clear context for when to use this tool by specifying it returns 'comprehensive information about current and planned disruptions,' implying it's for disruption-related queries rather than arrivals, departures, or other railway data. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as get_travel_advice for route planning, which could be related.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OV-fiets availability at a train station
| Name | Required | Description | Default |
|---|---|---|---|
| stationCode | Yes | Station code to check OV-fiets availability for (e.g., ASD for Amsterdam Centraal) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does without detailing behavioral traits like response format, error handling, rate limits, or whether it's a read-only operation. This leaves significant gaps in understanding how the tool behaves in practice.
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, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy to understand at a glance.
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 lack of annotations and output schema, the description is incomplete for a tool that likely returns availability data. It does not explain what the output includes (e.g., number of bikes, timestamps) or handle potential complexities, leaving the agent with insufficient context to use the tool effectively.
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 has 100% description coverage, so the schema already documents the 'stationCode' parameter with an example. The description does not add any additional meaning or context beyond what the schema provides, such as explaining the format of station codes or availability data, resulting in a baseline score of 3.
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's purpose with a specific verb ('Get') and resource ('OV-fiets availability at a train station'), making it immediately understandable. However, it does not explicitly differentiate from sibling tools like 'get_station_info', which might also provide station-related data but for different aspects.
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 provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools or specify contexts where this tool is preferred, such as for checking bike availability versus other station information tools like 'get_arrivals' or 'get_station_info'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get price information for domestic train journeys, including different travel classes, ticket types, and discounts. Returns detailed pricing information with conditions and validity.
| Name | Required | Description | Default |
|---|---|---|---|
| fromStation | Yes | UicCode or station code of the origin station | |
| toStation | Yes | UicCode or station code of the destination station | |
| travelClass | No | Travel class to return the price for | |
| travelType | No | Return the price for a single or return trip | single |
| isJointJourney | No | Set to true to return the price including joint journey discount | |
| adults | No | Number of adults to return the price for | |
| children | No | Number of children to return the price for | |
| routeId | No | Specific identifier for the route to take between the two stations. This routeId is returned in the /api/v3/trips call. | |
| plannedDepartureTime | No | Format - date-time (as date-time in RFC3339). Used to find the correct route if multiple routes are possible. | |
| plannedArrivalTime | No | Format - date-time (as date-time in RFC3339). Used to find the correct route if multiple routes are possible. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns detailed pricing information with conditions and validity,' which gives some indication of output behavior. However, it doesn't address important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or what happens when parameters are invalid. For a 10-parameter tool with no annotation coverage, this is insufficient.
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 efficiently structured in two sentences that cover purpose and return value. There's no wasted language, and it's appropriately sized for the tool's complexity. While it could be slightly more detailed given the lack of annotations, what's present is well-organized and front-loaded with the core functionality.
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 10-parameter tool with no annotations and no output schema, the description is incomplete. It doesn't explain the relationship between parameters (e.g., how routeId interacts with station parameters), doesn't mention error conditions or validation rules, and provides minimal guidance on the return format beyond 'detailed pricing information.' Given the complexity and lack of structured metadata, the description should do more to help an agent understand how to use this tool effectively.
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 description mentions 'different travel classes, ticket types, and discounts' which maps to some parameters (travelClass, travelType, isJointJourney). However, with 100% schema description coverage, the schema already documents all 10 parameters thoroughly. The description adds minimal value beyond what's already in the parameter descriptions, providing only high-level context without additional syntax or format details.
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's purpose: 'Get price information for domestic train journeys' with specific details about what's included (travel classes, ticket types, discounts). It distinguishes from sibling tools like get_arrivals or get_departures by focusing on pricing rather than schedules or status. However, it doesn't explicitly differentiate from potential pricing-related siblings that might exist in other contexts.
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 provides no guidance on when to use this tool versus alternatives. While sibling tools like get_travel_advice might include pricing information, there's no explicit comparison or context about when this specific pricing tool is preferred. The description mentions what the tool returns but not when it should be selected over other available tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a train station
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Station name or code to search for | |
| includeNonPlannableStations | No | Include stations where trains do not stop regularly | |
| limit | No | Maximum number of results to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'gets' information (implying a read operation) but doesn't mention any behavioral traits like rate limits, authentication needs, error handling, or what 'detailed information' entails (e.g., format, completeness). This leaves significant gaps for an agent to understand how to use it effectively.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 annotations and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes (e.g., station facilities, location, services), how results are structured, or any limitations (e.g., data freshness, availability). For a tool with 3 parameters and no structured output, this leaves too much ambiguity for reliable agent 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 description coverage is 100%, meaning all parameters are documented in the schema itself. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain how 'query' interacts with station codes vs. names or clarify 'detailed information' in relation to parameters). Baseline 3 is appropriate as the schema does the heavy lifting.
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 verb ('Get') and resource ('detailed information about a train station'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from siblings like 'get_arrivals' or 'get_departures' that also involve station data, which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'get_arrivals' and 'get_departures' that might overlap in station-related queries, there's no indication of when this tool is preferred or what specific 'detailed information' it provides that others don't.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed travel routes between two train stations, including transfers, real-time updates, platform information, and journey duration. Can plan trips for immediate departure or for a specific future time, with options to optimize for arrival time. Returns multiple route options with status and crowding information.
| Name | Required | Description | Default |
|---|---|---|---|
| fromStation | Yes | Name or code of departure station | |
| toStation | Yes | Name or code of destination station | |
| dateTime | No | Format - date-time (as date-time in RFC3339). Datetime that the user want to depart from his origin or or arrive at his destination | |
| searchForArrival | No | If true, dateTime is treated as desired arrival time |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: returns multiple route options, includes status and crowding information, supports real-time updates, and handles both departure and arrival time optimization. However, it doesn't mention rate limits, authentication requirements, error conditions, or pagination behavior for the returned routes.
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 efficiently structured in two sentences: the first establishes core functionality, the second adds important contextual details about timing and output. Every phrase adds value with zero redundant information, making it appropriately sized 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?
For a 4-parameter tool with no annotations and no output schema, the description does well by explaining what the tool returns (multiple route options with status/crowding info) and key behavioral aspects. However, it doesn't fully compensate for the lack of output schema by detailing the structure of returned data or error handling, leaving some gaps in completeness.
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%, so the schema already documents all 4 parameters thoroughly. The description adds marginal value by mentioning 'immediate departure or specific future time' and 'optimize for arrival time,' which helps contextualize the dateTime and searchForArrival parameters, but doesn't provide syntax or format details beyond what the schema provides.
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 verb ('Get detailed travel routes') and resource ('between two train stations'), specifying the scope includes transfers, real-time updates, platform info, and journey duration. It distinguishes from siblings like get_arrivals/get_departures (which focus on single stations) and get_disruptions (which doesn't provide 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 provides clear context for when to use this tool ('plan trips for immediate departure or for a specific future time') and mentions optimization options. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the differentiation is implied through the detailed functionality described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose targeting specific aspects of travel information, such as arrivals, departures, disruptions, pricing, and station details. The descriptions clearly differentiate each tool's function, with no overlap that could cause agent misselection.
All tool names follow a consistent verb_noun pattern using snake_case, starting with 'get_' followed by a descriptive noun (e.g., get_arrivals, get_prices). This predictable naming scheme enhances readability and usability for agents.
With 8 tools, the server is well-scoped for providing comprehensive travel information, covering real-time data, disruptions, pricing, and planning. Each tool serves a distinct and necessary function without being overwhelming or insufficient.
The tool set covers most core travel information needs, including arrivals, departures, disruptions, pricing, station details, and travel advice. A minor gap exists in lacking tools for booking or managing tickets, but agents can still handle common queries effectively with the provided tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
iRail MCP — Belgian rail (SNCB/NMBS) real-time via the community iRail API
Plan journeys by train, bus, tram, metro and ferry across 42 European countries.
Find EV charging stations, live availability and prices across the Netherlands via NDW data.
Real-time BART departures, trip planning, fares, stations, and advisories.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/KallivdH/ns-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server