Loading ToolBench
Transport for London (TfL) Unified API MCP — keyless. Live London transport: line status, stop search, real-time arrivals, journey planning, Santander cycle docking, and disruptions. No app key required for moderate use.
Six well-defined tools with clear, actionable descriptions (avg 150 chars) and complete input schemas. All parameters are typed and described. Tool names follow verb_noun convention (line_status, stop_search, arrivals, plan_journey, bike_points, disruptions). No output schemas documented, a significant gap for agent planning. Error handling is minimal; tools throw generic errors without recovery guidance. Missing tool annotations (readOnlyHint, idempotentHint). All tools are READ_ONLY and idempotent, but this is not declared in the schema.
Real-time predicted arrivals at a stop. Pass the naptanId from stop_search (e.g. "940GZZLUOXC"). Results are sorted by timeToStation (seconds away), nearest first.
Santander Cycle docking stations with live availability (bikes, empty docks, total docks in additionalProperties). Pass an optional search to filter by name/area; omit it to list all docking stations.
Current disruptions for the given transport modes, with description and affected lines.
Current service status for London transport lines. Pass either a comma-separated list of modes (e.g. "tube,dlr") OR a specific lineId (e.g. "victoria", "central"). Returns each line with lineStatuses + statusSeverityDescription (e.g. "Good Service", "Minor Delays").
Plan a journey across London transport. from/to may be stop names, postcodes, or "lat,lon" coordinates. Returns journey options (legs, durations, modes). If a location is ambiguous, the API returns disambiguation options instead of journeys — refine the input or use a naptanId/coords.
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., naptanId from stop_search for arrivals). Agents must infer response structure from descriptions alone.
No tool annotations (readOnlyHint, idempotentHint, destructiveHint). All six tools are READ_ONLY and idempotent, but this is not declared in the schema. Agents cannot distinguish safe tools from destructive ones without explicit hints.
Error handling lacks recovery guidance. Generic errors like 'TfL: 404 ...' or 'Required argument missing' do not tell the LLM what to do next. Missing pattern:recovery-guide implementation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Search for stops/stations by name. Returns matches with a naptanId (the "id" field) used by the arrivals tool, plus modes, zone, and lat/lon.
plan_journey accepts ambiguous location formats (stop names, postcodes, lat/lon) but does not validate format or guide the LLM on disambiguation. Description mentions 'disambiguation options' but does not explain how to handle HTTP 300 responses or what the agent should do.
bike_points and disruptions have optional parameters with no defaults documented. bike_points.search and disruptions.modes are optional, but the behavior when omitted is unclear in the description (e.g., 'Omit for all docks' is vague).