Loading ToolBench

Reading the current corpus…

china-rail-mcp MCP server · C · ToolBench

← Browse

china-rail-mcp

github.com/TakeruF/china-rail-mcp

Read-only MCP server for Chinese railway schedules, fares, stops, and seat availability.

<=2025-11-25STDIO6 tools

63/100

Definition Quality85

Protocol Readiness47

Supportability38

Spec posture

Inferred effective spec <=2025-11-25·current baseline 2026-07-28

Static source inference · medium confidence · detected: Dynamic Client Registration

Deprecated protocol patterns detected

Summary

Strong tool naming (all verb-prefixed), comprehensive parameter schemas with proper Zod validation, and clear descriptions. All 6 tools have explicit descriptions (avg ~120 chars) and input schemas with type constraints. Tool annotations present (readOnlyHint, idempotentHint, destructiveHint). Key gaps: output schemas are not formally documented (tools return text-wrapped JSON without declared structure), error handling is minimal (toolError() function exists but recovery guidance is absent), and parameter descriptions in schema are sparse (e.g., 'query' param has description but many filter params lack inline guidance). Pagination is well-implemented (limit/offset with defaults). No security issues detected (read-only operations, no secrets in params).

Tools (6)

compare_trainsread onlysource verified78/100

Filter, sort, and paginate journeys; this does not make subjective recommendations.

get_availabilityread onlysource verified82/100

Get normalized official seat availability for an exact station pair, train, and date.

get_provider_statusread onlysource verified90/100

Return the official provider, its verified capabilities, and anonymous-session policy.

get_train_detailsread onlysource verified87/100

Get a published official stop sequence for an exact train number and date, including booking status. A timetable may be available before tickets go on sale.

search_stationsread onlysource verified87/100

Search public Chinese railway stations. City names are not silently resolved to a specific station.

search_trainsread onlysource verified85/100

Search official read-only 12306 route, fare, and availability data within the current ticket-query window. Results are paginated after filtering. Times are Asia/Shanghai.

Issues (5)

HIGHresponse-shaper ↗

Output schemas not formally documented. Tools return text-wrapped JSON via text() helper, but no structured schema is declared for LLM parsing. LLMs cannot plan downstream calls or extract fields reliably.

get_provider_statussearch_stationssearch_trainsget_train_detailsget_availabilitycompare_trains

HIGHrecovery-guide ↗

Error handling lacks recovery guidance. toolError() function wraps exceptions but does not categorize errors (retryable vs user-fixable) or suggest next steps. LLMs receive raw error messages without actionable context.

search_stationssearch_trainsget_train_detailsget_availabilitycompare_trains

MEDIUMtool-description ↗

Parameter descriptions in Zod schemas are minimal. Filter parameters (departAfter, departBefore, trainTypes, seatClass, onlyAvailable) lack inline descriptions explaining their purpose and constraints. LLMs must infer meaning from names alone.

search_trains

Recommendations

Document output schemas explicitly. Define the structure returned by each tool (e.g., search_trains returns {journeys: [{trainNumber, departure, arrival, price, seatClass, availability}], total, hasMore}). Include this in tool descriptions or a separate schema field.
Enhance error handling in toolError(). Categorize errors: if provider.searchStations() returns 'Station not found', respond with 'Station not found. Try a partial name or nearby city.' If a date is in the past, respond with 'Date must be in the future (current ticket window: today to +30 days).'
Add inline descriptions to filter parameters in Zod schemas. E.g., departAfter: z.string().describe('Filter: only show trains departing at or after this time (HH:MM, Asia/Shanghai).'). This makes constraints visible to LLMs without reading JSON Schema.
Clarify compare_trains vs search_trains in descriptions. E.g., search_trains: 'Search and filter trains in one call.' compare_trains: 'Re-filter and re-sort previously fetched results; use this to refine a search without calling the API again.' This prevents tool confusion.
Add a rate-limit or polling-guard note to server instructions. E.g., 'Do not call search_trains or get_availability more than once per minute for the same route. Results are cached server-side.' This prevents agent runaway.

Spec posture evidence

Inferred effective spec: <=2025-11-25.

Relies on Dynamic Client Registration (deprecated) - use Client ID Metadata Documents (CIMD)

Score history

Overall score trend

First recorded score · v2 rubric

63/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	63	<=2025-11-25	v2