Loading ToolBench
MCP server for the Trip Loom travel planning application, providing tools for trip management, destination search, flight/hotel booking, itinerary creation, and weather information
Critical gaps across all dimensions. Tool definitions are inferred from a React component file (tool-call-renderer.tsx) rather than explicit MCP server registration, this alone caps individual tool scores at 50. Descriptions are present but generic (avg ~40 chars, well below 194-char baseline). Input schemas visible but lack depth: most parameters have only type and description, no enums, ranges, or format constraints. No output schemas documented. No error handling guidance. No tool annotations (readOnlyHint/destructiveHint). The MCP server code itself (apps/mcp-server/package.json) shows SDK v1.27.1 but actual tool definitions are not visible in the provided source, only React UI renderers. This is a fundamental architecture issue: tools should be registered in the MCP server, not inferred from frontend components.
Add a new activity to an itinerary day
Add a new day to an existing itinerary
Create a flight booking for a trip
Create a hotel booking for a trip
Create a new itinerary for a trip
Delete an activity from an itinerary
Get detailed information about a specific destination
Tool definitions inferred from React component (tool-call-renderer.tsx) rather than explicit MCP server registration. No actual MCP tool handler code visible. This violates the tool registration pattern and makes it impossible to verify actual implementation.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields. Baseline: 100% of A+ tools have documented return types.
Descriptions are generic and under 50 chars on average (baseline 194 chars). Examples: 'Retrieve current trip plans and details' (40 chars), 'Retrieve user preferences for trip planning' (43 chars). Too brief to guide LLM selection or explain when to use vs similar tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | <=2025-11-25 | v2 |
Get recommended destinations based on user preferences
Retrieve current trip plans and details
Retrieve user preferences for trip planning
Get weather information for a destination
Search for destinations by name or criteria
Search for available flights
Search for available hotels
Suggest destinations based on user preferences and trip parameters
Suggest flight options for a trip
Suggest hotel bookings for a destination and date range
Suggest a new trip based on user preferences
Transfer conversation back to the supervisor agent
Transfer conversation to the destination specialist agent
Transfer conversation to the flight specialist agent
Transfer conversation to the hotel specialist agent
Transfer conversation to the itinerary specialist agent
Update an existing itinerary activity
Update trip details
No input validation constraints. Parameters like 'budget' (numeric) and 'date' (string) lack ranges, formats, or enums. LLMs will pass invalid values (negative budgets, malformed dates) without guidance.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Destructive tools like delete_itinerary_activity lack explicit marking. LLMs cannot distinguish safe reads from dangerous writes without annotations.