Loading ToolBench
Unofficial MCP server for SynXis CRS (Central Reservation System) API
The server has a structured tool interface with a custom ToolResponse model and basic parameter documentation. All 4 tools are explicitly registered and have input schemas visible in the code. However, descriptions are generic and lack LLM-optimization, parameters lack type constraints (enums), and critical error handling guidance is missing. The server follows a consistent pattern but falls short of production-grade quality in several key areas. Naming is clear and action-oriented (search_, get_, create_). Tool definitions are visible and schemas are present, but descriptions are terse (avg ~50 chars) and do not guide the LLM on when to use each tool versus similar ones.
Create a new hotel reservation.
Check room availability for a property.
Get rate information for a property.
Search for hotels by location. Find properties in a specific city, state, or region.
Tool descriptions lack LLM-optimization and context. Descriptions are 20 - 50 chars and do not explain WHEN to use each tool, dependencies between tools, or expected output structure. E.g., 'Check room availability for a property' omits that this tool must follow search_properties() and should precede get_rates(). LLMs cannot reliably infer tool selection logic from such sparse descriptions.
Parameters accept free-form strings where enums would be more precise. E.g., 'room_type' in get_rates and create_reservation accepts arbitrary strings ('STD', 'DLX', 'SUI') but has no enum constraint. Description shows examples but does not declare the full set of valid values. LLMs will hallucinate invalid room types. Similarly, date parameters lack format declarations (regex pattern, ISO 8601 enforcement).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 63 | - | v1 |
Output structure is standardized via ToolResponse but lacks detailed documentation in tool descriptions. The LLM cannot infer that responses include 'data', 'next_steps', and 'error' fields. No documentation of what 'data' contains for each tool. E.g., search_properties returns a list of properties, but the description does not specify the fields in each property object (name, brand, location, amenities, etc.).
Error handling logic is present (try/except blocks catch ValueError, TypeError, RuntimeError, OSError) but error responses do not guide the LLM on recovery. The ToolResponse includes an 'error' field but no 'next_steps' guidance for retryable vs. fatal errors. E.g., if search_properties() fails with a ValueError, the LLM sees an error string but doesn't know whether to retry, call a different tool, or ask the user.
Parameter descriptions are minimal and do not include constraints. E.g., 'start_date' is described as 'Check-in date (YYYY-MM-DD)' but does not state minimum/maximum (e.g., no past dates, no dates >365 days ahead), whether the date must be in a specific timezone, or what happens if start_date >= end_date. 'adults' and 'children' lack min/max bounds.
The create_reservation tool accepts guest data (first_name, last_name, email, phone) as direct parameters. While the schema is visible, there is no validation logic shown and no description of what happens on validation failure (e.g., invalid email format, missing required fields). The description does not state whether an email/phone is required or optional.
No documentation of idempotency. The create_reservation tool is clearly destructive (writes state), but the description does not explain what happens if called twice with the same parameters. Is it idempotent (returns the same reservation)? Or does it create a duplicate? This ambiguity is dangerous for agents retrying on failures.