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., "@traintrack-mcp check live status of 12627"
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.
An MCP server for TrainTrack that gives AI agents access to Indian Railways train search, schedules, live status, trains between stations, station data, and PNR status.
It uses the MCP stdio transport, requires no API key, and talks to https://traintrack.stupidlabs.lol/ by default. TrainTrack uses unofficial NTES/Indian Railways data, which may occasionally be delayed, incomplete, or unavailable. Confirm time-sensitive journey details through official railway channels.
Node.js 18 or newer
An MCP-compatible client
Related MCP server: SBB Open Data MCP Server
After the package is published:
npm install --global traintrack-mcpTo run it directly from a source checkout:
npm install
npm startNo environment variables are required for the hosted TrainTrack API.
Add this to the client's MCP configuration:
{
"mcpServers": {
"traintrack": {
"command": "npx",
"args": ["-y", "traintrack-mcp"]
}
}
}Add this to ~/.codex/config.toml:
[mcp_servers.traintrack]
command = "npx"
args = ["-y", "traintrack-mcp"]
tool_timeout_sec = 60Add this to ~/.config/opencode/opencode.json:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"traintrack": {
"type": "local",
"command": ["npx", "-y", "traintrack-mcp"],
"enabled": true
}
}
}Environment variable | Default | Description |
|
| TrainTrack deployment to use. |
|
| Positive request timeout in milliseconds. |
For example:
{
"mcpServers": {
"traintrack": {
"command": "npx",
"args": ["-y", "traintrack-mcp"],
"env": {
"TRAINTRACK_BASE_URL": "https://trains.example.com/"
}
}
}
}Tool | Inputs | What it returns |
|
| Trains matching a name, number, or text |
|
| Train identity, endpoints, and running instances |
|
| Scheduled stops, times, running days, and coordinates |
|
| Live stops, delays, platforms, current reported position, and route geometry |
|
| Direct trains between two station codes |
|
| Exceptional service information such as cancellations or diversions |
|
| Booking, passenger, train, and chart status |
|
| Bundled station name and coordinates |
|
| Stations matching a name or code |
|
| Batched live tracking for up to 10 trains |
| none | Public API availability and service status |
Dates use DD-MMM-YYYY, for example 26-Jul-2026. Train numbers contain 4–6 digits, station codes contain 1–10 letters or digits, and a PNR contains exactly 10 digits.
TrainTrack applies these default limits per client IP and per endpoint. This MCP server does not add another rate limiter. An upstream 429 response is returned to the MCP client as a tool error with its HTTP status, response details, and X-Request-ID when available.
Operation | Default upstream limit |
Train search | 60/minute |
Train information | 30/minute |
Train schedule | 20/minute |
Live train status | 12/minute |
Trains between stations | 20/minute |
Train exceptions | 20/minute |
PNR status | 2/minute |
Station coordinates | 120/minute |
Station search | 120/minute |
Batched live tracking | 6/minute |
Health check | 120/minute |
The hosted service also protects its railway-data provider from overload, so temporary 502 errors can occur even before a client endpoint limit is reached. Wait briefly before retrying a 429 or 502 response.
Caching happens in TrainTrack, not in this MCP process. The MCP tools return the upstream response unchanged, including its cached field. A response with "cached": true came from an earlier identical request or was shared with a simultaneous identical request; it does not mean the data was just refreshed.
Data | Maximum default cache window |
Live running status | 45 seconds |
Train exceptions/service updates | 5 minutes |
Train information | 30 minutes |
Current running instance | 30 minutes |
Trains between stations | 30 minutes |
Train search | 12 hours |
Train schedules | 12 hours |
PNR results are never stored in the result cache. Identical simultaneous PNR requests may still share one in-flight lookup. Treat PNRs as sensitive travel information and avoid putting real values in shared logs, screenshots, or telemetry.
See the hosted TrainTrack API documentation for the full API behavior.
npm install
npm run check
npm testThe project uses ESM throughout and relies on Node's built-in Fetch API.
Nitin Bansal (freakynit) — nitinbansal85@gmail.com
Check whether the public TrainTrack API is available. Upstream limit: 120 requests/minute.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the rate limit (120 requests/minute), a key behavioral trait beyond the simple check operation. Without annotations, this adds necessary context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check with no parameters and no output schema, the description is complete, covering purpose and rate limit.
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 has no parameters (100% coverage), so description adds no parameter info; baseline for 0 parameters is 4.
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 the verb 'Check' and the resource 'whether the public TrainTrack API is available', distinguishing it from sibling tools that deal with train 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?
Provides clear context for use (checking API availability) and mentions the upstream rate limit, though it does not explicitly exclude alternatives or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find direct trains between two station codes, optionally sorted by fastest journey or earliest departure. Upstream limit: 20 requests/minute; results may be cached for up to 30 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Indian Railways station code, for example "HWH" or "NDLS". | |
| from | Yes | Indian Railways station code, for example "HWH" or "NDLS". | |
| sort | No | Optional result order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the upstream rate limit and caching behavior but does not mention return format, authentication requirements, or error handling.
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-load the purpose and constraints. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain the return format or error cases. For a 3-parameter tool, it is somewhat complete but missing key information about results.
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 all parameters. The description adds semantic value by specifying 'direct trains', which implies no transfers, and clarifies the sorting options.
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 'Find direct trains between two station codes' with a specific verb and resource. It mentions optional sorting, distinguishing it from siblings like 'search_trains' or 'get_train_schedule'.
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 for direct trains but does not explicitly state when not to use this tool or suggest alternatives. No when-to-use or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up Indian Railways PNR booking, passenger, and chart status. PNR data is sensitive. Upstream limit: 2 requests/minute; PNR results are never stored in the result cache.
| Name | Required | Description | Default |
|---|---|---|---|
| pnr | Yes | Exactly 10 PNR digits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses sensitivity of PNR data, upstream rate limit of 2 requests/minute, and that results are never cached. This adds valuable behavioral context beyond a simple read operation.
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 purpose, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, description explains what is returned (booking, passenger, chart status) and critical constraints. It is fairly complete, though output structure is not detailed.
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% as the param description already explains the pattern. Description adds no extra meaning beyond the schema's description.
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 the tool looks up Indian Railways PNR booking, passenger, and chart status, with specific verb and resource. It distinguishes from siblings as no other tool mentions PNR.
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?
Usage context is implied by the name and description, but no explicit guidance on when to use vs alternatives or when not to use. For a single-purpose tool, this is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the name and bundled map coordinates for an Indian Railways station code. Upstream limit: 120 requests/minute.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Indian Railways station code, for example "HWH" or "NDLS". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It implies a read operation and mentions rate limits, but doesn't disclose response format or caching behavior. Adequate but not detailed.
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 action, no unnecessary words. 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 one-parameter tool, the description provides the core purpose and a constraint (rate limit). Missing details like coordinate format, but overall sufficient for selection.
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 description does not add significant meaning beyond the schema's parameter description. Baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets name and map coordinates for a station code, using a specific verb and resource. It distinguishes from sibling tools which focus on trains, schedules, and other 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 rate limit (120 req/min) provides context, but no explicit when-to-use or when-not-to-use guidance. Since siblings are mostly unrelated, the need for exclusion guidelines is lower.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get exceptional service information such as cancellations or diversions. Read the returned message field. Upstream limit: 20 requests/minute; results may be cached for up to 5 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| train_number | Yes | Train number containing 4 to 6 digits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses rate limiting (20 requests/minute) and caching (up to 5 minutes), which are behavioral traits beyond the basic purpose. Since no annotations are provided, the description carries the full burden and adequately covers operational constraints, though it does not mention error behavior or auth requirements.
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 exceptionally concise: two sentences covering purpose, usage guidance, and constraints. Every sentence provides necessary information 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's simplicity (one parameter, no output schema, no annotations), the description is complete. It covers what the tool does, how to interpret results, and operational limits. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, train_number, is fully described in the input schema with pattern and description. With schema coverage at 100%, the baseline is 3. The description adds no extra semantic information 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 tool retrieves exceptional service information like cancellations or diversions. It uses a specific verb 'Get' and a specific resource 'exceptional service information', distinguishing it from sibling tools like get_train_info or get_train_schedule which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to 'Read the returned message field' but does not explicitly state when to use this tool versus alternatives or when not to use it. It provides a usage hint but lacks comparative or contextual guidance with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a train's identity, endpoints, and available running instances. Upstream limit: 30 requests/minute; results may be cached for up to 30 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| train_number | Yes | Train number containing 4 to 6 digits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses critical behavioral traits: a rate limit of 30 requests/minute and a 30-minute cache, which are not inferable from the schema. It lacks authentication info but is otherwise transparent.
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 redundancy. The first sentence front-loads the purpose, and the second adds essential constraints. Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description covers the return value (identity, endpoints, instances) and operational constraints (rate limit, caching). It could specify the format of endpoints or instances, but it is largely 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 description coverage is 100%, so the baseline is 3. The description does not add additional meaning or usage tips beyond the schema's description of the train_number parameter.
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 uses specific verbs ('Get') and explicitly names the resources returned ('identity, endpoints, and available running instances'), clearly differentiating it from sibling tools like get_train_schedule or get_train_live_status.
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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. The usage context is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live station-by-station progress, delays, platforms, current reported position, and route geometry. Upstream limit: 12 requests/minute; live results may be cached for up to 45 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional service start date in DD-MMM-YYYY format, for example "26-Jul-2026". | |
| train_number | Yes | Train number containing 4 to 6 digits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses rate limiting and caching, which are important behavioral traits. It does not cover error handling or response structure, but still adds significant value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence states purpose concisely; second sentence provides essential behavioral constraints. Every word earns its place, 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?
The description enumerates key output fields (progress, delays, platforms, position, route geometry), which compensates for the lack of an output schema. For a simple 2-param tool, this is sufficiently 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 description coverage is 100% (both date and train_number have descriptions). The description adds no new parameter-level details; it only restates the overall purpose. 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 explicitly states the tool provides live station-by-station progress, delays, platforms, current position, and route geometry. This clearly differentiates it from sibling tools like get_train_info (static info) and get_train_schedule (planned schedule).
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 includes rate limit (12 req/min) and caching behavior (up to 45s), which guides usage. However, it does not explicitly contrast when to use this tool versus alternatives like get_train_schedule or search_trains for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a train's scheduled stops, running days, times, and available station coordinates. Upstream limit: 20 requests/minute; results may be cached for up to 12 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional service start date in DD-MMM-YYYY format, for example "26-Jul-2026". | |
| train_number | Yes | Train number containing 4 to 6 digits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an upstream rate limit of 20 requests per minute and potential caching of up to 12 hours. With no annotations, this adds useful behavioral context, though it omits authentication requirements or error handling details.
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 long, front-loading the purpose and adding only essential behavioral constraints. Every sentence earns its place 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 (two parameters, no output schema, no annotations), the description covers purpose and key behavioral notes. It could mention error scenarios or output format, but it is largely complete for a straightforward lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds minimal parameter semantics. It implies the output includes the listed fields but does not elaborate on input parameters beyond what the schema already 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 it retrieves a train's scheduled stops, running days, times, and station coordinates. The verb 'Get' and object 'schedule' are specific, and the content distinguishes it from siblings like get_train_live_status or get_train_info.
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?
No guidance on when to use this tool versus alternatives. The description does not mention when not to use it or point to sibling tools like search_trains for broader searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search bundled Indian Railways stations by code or name. Upstream limit: 120 requests/minute.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results. | |
| query | Yes | Station name or code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses a rate limit ('120 requests/minute'), which is a key behavioral constraint. It does not mention idempotency or side effects, but for a read-only search tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence is front-loaded with the core purpose, and the second provides a critical constraint. Every word earn 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?
The tool has no output schema and the description does not describe the return format. For a search tool, users would benefit from knowing the structure of results. However, given the simple query and 100% parameter coverage, the description is partially 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%, so the schema itself documents both parameters. The description adds little beyond 'by code or name' which is already implied by the schema field 'Station name or code.' 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 this tool 'Search bundled Indian Railways stations by code or name.' It uses a specific verb ('search') and resource ('stations'), and distinguishes it from sibling tools which focus on trains, schedules, and PNR status.
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 for finding stations by query, but does not mention when to use alternatives like get_station_coordinates, nor provides exclusions or prerequisites. It offers minimal guidance beyond the basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Indian Railways trains by name, number, or text. Upstream limit: 60 requests/minute; results may be cached for up to 12 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Train name, number, or search text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses rate limits and caching behavior. But it does not mention that the operation is read-only, nor describe response structure or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states core purpose, second adds important usage constraints. Efficient and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with one parameter and no output schema, the description is largely complete. It covers purpose and key constraints. Lacks explanation of return format, but given simplicity this is acceptable.
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 schema description already explains the parameter. The tool description repeats the same information, adding no new semantic value beyond constraints like min/max length.
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 verb (Search), resource (Indian Railways trains), and method (by name, number, or text). It distinguishes from siblings like search_stations or find_trains_between_stations by focusing on a generic query search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions an upstream rate limit and caching, giving useful context. However, it does not specify when to use this tool versus alternatives (e.g., find_trains_between_stations for route-based search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live tracking for up to 10 trains in one request. Individual train failures are returned in the trains array. Upstream limit: 6 requests/minute; successful live results may be cached for up to 45 seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| train_numbers | Yes | One to ten unique train numbers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: batch size limit, individual failure handling, rate limit (6 req/min), and caching (up to 45s). 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 efficiently cover purpose, limit, failure handling, and rate limits. No wasted words; 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?
While there is no output schema, the description hints at the output format by mentioning failure returns. For a simple batch tracking tool, this is sufficiently 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%, and the description only reiterates the maxItems limit already present in the schema. It adds no new meaning 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 live tracking' and the resource 'up to 10 trains'. It distinguishes from sibling tools like get_train_live_status by indicating batch capability.
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 batch tracking and includes rate limits and caching info, but does not explicitly state when to prefer alternatives like get_train_live_status for single trains.
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. Dates show when Glama detected each change.
v1.0.0check_traintrack_healthfind_trains_between_stationsget_pnr_statusget_station_coordinatesget_train_exceptionsget_train_infoget_train_live_statusget_train_schedulesearch_stationssearch_trainstrack_trainsEach tool serves a unique function, from searching trains and stations to live tracking and PNR status, with no apparent overlap in purpose.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., get_train_info, search_stations, check_traintrack_health), ensuring predictability.
With 11 tools, the set is well-scoped for an Indian Railways data API, covering essential operations without unnecessary redundancy.
Core functionalities like search, schedule, live status, PNR, and exceptions are covered. Minor gaps like fare or seat availability exist but are not critical for the api's purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Hosted MCP server for live public-data APIs and Skills for AI agents.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
MCP server connecting AI agents to non-custodial staking data across 130+ networks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/freakynit/traintrack-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
