Loading ToolBench
A 12306 ticket search server based on the Model Context Protocol (MCP).
The 12306 MCP server provides 5 tools for searching train tickets and retrieving station/route information. All tools have basic descriptions and structured input schemas with enums for constrained parameters (train types, sort fields). However, multiple definition quality issues prevent a higher score: (1) descriptions are minimal (10-20 chars in many cases), failing the rubric's baseline of 194 chars average for production tools; (2) output schemas are not documented anywhere in the visible code, the tool definitions register inputs but provide no response structure guidance; (3) parameter descriptions, while present, are shallow and lack actionable format/constraint details; (4) error handling is not visible in the tool definitions, no recovery guidance or categorization; (5) no pagination parameters despite tools returning lists (search results, stations, cities). The tools themselves are reasonably named with clear verbs (search_, get_), but the implementation lacks the depth required for LLMs to reliably compose multi-step workflows.
Get a list of all available cities with train stations
Get a list of all available train stations
Get detailed route information for a specific train on a specific date
Search for interline (transfer) train tickets between two stations on a specific date with optional filters for train type and sorting
Search for train tickets between two stations on a specific date with optional filters for train type and sorting
Output schemas are not documented. None of the 5 tools declare what fields their responses contain, making it impossible for LLMs to plan downstream operations or extract required data for tool chaining.
Tool descriptions are too brief (10-30 chars). The rubric baseline for production tools is ~194 chars. Descriptions should state WHAT the tool does, WHEN to use it, and any prerequisites. Current descriptions are insufficient for LLM selection logic.
Missing pagination support. Tools returning lists (search_tickets, search_interline_tickets, get_stations, get_cities) lack page/offset/limit parameters and do not document result limits. Large result sets risk context window exhaustion.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No error handling guidance in tool definitions. Tools provide no documentation of failure modes, recovery steps, or what to do if a station is not found or a date is invalid. Error responses will lack actionable context for the LLM.
Parameter descriptions lack actionable format details. The 'date' parameter states 'Travel date in format YYYY-MM-DD' but does not indicate whether past dates are allowed, how far ahead bookings can be made, or how the tool behaves on invalid dates.
Station parameter accepts both names and codes but provides no guidance on resolution priority or fallback behavior. Description says 'Departure station name or code (e.g., 北京 or BJP)' but does not explain what happens if both a name and code match different stations.