irail_disturbancesCurrent disturbances, incidents, and planned works on the Belgian rail network (SNCB NMBS Infrabel) — strikes, track works, line closures affecting Belgian train service. Returns title, summary, type (planned or disturbance), link, and last-updated time. Example: irail_disturbances({})
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max disturbances to return, 1-50 (default 15) |
Changes observed during successful MCP inspections.
Input schema / examplesAdded value: +[
+ {
+ "limit": 20
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description does not need to repeat safety traits. It adds value by listing returned fields (title, summary, type, link, last-updated time) and mentioning the network scope, but does not disclose potential behavioral nuances like rate limits or data freshness.
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 concise (one sentence plus an example) and front-loads the core purpose. Every sentence is informative, though the example is slightly redundant given the schema's examples. Still, it is well-structured and avoids verbosity.
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 optional parameter, no output schema, comprehensive annotations), the description provides sufficient context: it names the network, lists output fields, and shows a usage example. It could elaborate on output format details, but the listed fields suffice for an agent to understand what to expect.
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% (the only parameter 'limit' is fully described with range 1-50 and default 15). The description does not mention the parameter, so it adds no additional semantic value beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'current disturbances, incidents, and planned works' on the Belgian rail network. It lists output fields (title, summary, type, link, last-updated time) and provides a usage example. This differentiates it from sibling tools like irail_journey, irail_liveboard, and irail_train, which focus on different aspects of rail 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 implies the tool is for checking disruptions via phrases like 'current disturbances' and 'affecting Belgian train service,' and includes an example call. However, it does not explicitly state when to use this tool over alternatives or provide when-not-to-use guidance, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.