Loading ToolBench
Read-only travel planner tools with live Amap data
Travel Planner MVP has 12 tools with basic descriptions and input schemas, but significant quality gaps. All tools are READ_ONLY and lack error handling guidance. Descriptions are present but generic (avg ~80 chars, below 194-char baseline). Parameter descriptions exist but lack constraint details (ranges, formats, enums). No output schemas documented. Tool names are action-oriented (search-, validate-, normalize-) but descriptions don't explain WHEN to use each tool or what distinguishes similar ones (e.g., validate-request vs validate-plan vs validate-flights). No tool annotations (readOnlyHint, idempotentHint). File-based I/O pattern (input/output JSON paths) is unusual for MCP and complicates agent composition, agents must manage temp files rather than passing structured data between tools.
Collect live locations, routes, and nearby POIs
Compile normalized social notes into attraction cards
Check whether the Amap key is configured
Check Python, Amap, rail MCP, and browser readiness
Evaluate a normalized itinerary JSON file
Normalize a 12306 query-tickets payload into comparable records
Verify the configured Amap key with a live request
File-based I/O pattern breaks tool composition. Tools accept 'input' (JSON file path) and 'output' (optional path) instead of structured parameters and return values. Agents must manage temp files, serialize/deserialize JSON, and track file paths, violating the chat data model. This prevents natural tool chaining and increases error surface.
No output schemas documented. Agents cannot predict what fields to expect from tool responses, forcing them to guess at downstream tool parameters. E.g., search-places returns results but no schema shows whether results include 'place_id', 'poi_id', or 'id', breaking chaining to other tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Search live Amap POI data
Check browser-derived flight offers, including price freshness
Check browser-derived lodging offers, including price freshness
Validate complete travel plan content
Validate intake completeness and detect explicit requirement conflicts
Descriptions lack constraint details and WHEN-to-use guidance. E.g., 'normalize-rail' and 'validate-flights' both process external data, but descriptions don't explain the difference or when to call each. Parameter descriptions omit ranges (e.g., 'limit' has no min/max), formats (e.g., 'earliest' is 'HH:MM' but not stated), or enums (e.g., 'seat_class' values not listed).
No error handling guidance. All tools are READ_ONLY but descriptions don't explain failure modes or recovery steps. E.g., if 'search-places' returns no results, should the agent retry with different keywords, expand the city, or ask the user? No guidance provided.
Tool annotations missing. No readOnlyHint, idempotentHint, or destructiveHint declared. Agents cannot determine which tools are safe to retry, which modify state, or which are read-only without inferring from names and descriptions.