Four well-defined tools with complete input schemas, strong descriptions (150 - 250 chars each), and clear parameter documentation. Tool names follow verb_noun convention (irail_*). All parameters have type and description. Station aliasing and fuzzy matching are well-documented. Output schemas are not explicitly documented in the source, which is the primary gap. Error handling is mentioned in comments but not formalized in tool definitions. No tool annotations (readOnlyHint, destructiveHint) despite all tools being read-only.

• Add explicit output schemas to each tool definition. Document the structure of liveboard entries (train_id, destination, scheduled_time, delay_minutes, platform, is_canceled), journey legs (departure, arrival, transfers, delay), train stops, and disturbance objects. Use JSON Schema with type, properties, and required fields.
• Add readOnlyHint: true to all four tool definitions in the McpToolDefinition interface. This signals to LLMs that these tools are safe to call without confirmation and can be retried without side effects.
• Formalize error handling in tool descriptions. Add a sentence like: 'Returns error if station is unrecognized (try search_stations or use English exonyms like "Brussels-South"). Delays are in minutes; platforms may change (platform_changed flag indicates deviation from usual platform).'
• Add JSON Schema constraints: minValue/maxValue for 'limit' (1 - 50, 1 - 6), format: 'date' for 'date' parameter, pattern for time strings ('HH:MM' or 'YYYY-MM-DDTHH:MM'). This enables client-side validation and reduces invalid LLM calls.
• Document the transport mechanism explicitly. Add a comment or README section stating whether this server uses HTTP, STDIO, or SSE, and include a minimal example of how to invoke it (e.g., via MCP client library or curl).