Loading ToolBench
A FastAPI-based server for managing travel itineraries with trip planning, day-by-day activities, hotels, and transfers
Three tools with basic schemas and descriptions, but significant gaps in parameter documentation, output schema clarity, and error handling. Tool names follow verb_noun convention (recommend_, create_, read_), which is good. However, descriptions are minimal (10-50 chars), parameter descriptions are sparse or missing, and output schemas are not documented. No error handling guidance, no pagination support for list operations, and no tool annotations. The create_itinerary tool accepts a complex nested 'days' array but provides no guidance on structure or validation. Overall, this is a D-grade server with functional but underdeveloped definitions.
Create a new trip itinerary with days, hotels, transfers, and activities
Retrieve all trip itineraries from the database
Get a recommended itinerary based on the number of nights
Output schemas not documented. LLMs cannot infer what fields are returned or plan downstream calls. E.g., recommend_itinerary returns a TripItinerary object, but the response structure (id, name, nights, region, days with nested hotels/transfers/activities) is not visible in the tool definition.
Parameter descriptions are missing or incomplete. The 'days' parameter in create_itinerary is described only as 'List of day objects with day_number, hotel, transfers, and activities', no guidance on required fields, nesting depth, or validation rules. LLMs cannot construct valid payloads without explicit field documentation.
No error handling or recovery guidance. recommend_itinerary returns 404 if no itinerary matches the nights parameter, but the tool description does not explain this failure mode or suggest alternatives (e.g., 'Try a different night count' or 'Call read_itineraries to see available options').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
read_itineraries lacks pagination. No limit, offset, or page_size parameters. If the database grows to hundreds of itineraries, the tool will return all records, bloating the response and exhausting context windows. Should accept limit (default 20) and offset parameters.
Tool descriptions are too brief (10-50 chars). 'Get a recommended itinerary based on the number of nights' and 'Retrieve all trip itineraries from the database' lack context on WHEN to use each tool, what they return, or how they differ. Descriptions should be 50-200 chars and answer: what, when, and what's returned.