Loading ToolBench
MCP server for restaurant booking with AI-powered recommendations
The server exposes a single tool 'search_restaurants' with a well-structured input schema and comprehensive parameter descriptions. However, there are critical gaps in output schema documentation, error handling guidance, and adherence to composition patterns. The tool schema is visible and detailed, but the output response structure is not documented in the provided source, making it impossible to verify downstream chaining. The description is adequate (169 chars, within baseline range of p10=34, p90=392) but lacks explicit guidance on when to use this tool vs. alternatives or what the LLM should expect from the response.
Search for restaurants based on location, cuisine, keyword, mood, event, radius, price level, and locale
Output schema not documented. The tool description and input schema are complete, but there is no specification of what fields the response contains, their types, or how to chain results to downstream tools (e.g., 'placeId' field names, pagination support). Test script references 'placeId' in downstream tools, but output structure is not formally documented in the tool definition.
Missing error handling guidance. The schema does not document recovery strategies for common failure modes (e.g., invalid lat/long, no results found, rate limit hit). Error responses are not defined, leaving the LLM without actionable direction on retries or fallbacks.
Tool composition incomplete. The test script shows calls to 'get_restaurant_details' and 'get_booking_instructions' tools, but these are not defined in the tool list provided. This indicates either incomplete tool exposure or broken tool chains, the server claims only 1 tool but the test expects 3.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 56 | - | v1 |
Default coordinates (Taiwan: 24.1501164, 120.6692299) in parameter description. The rubric explicitly prohibits example values in descriptions because LLMs tend to reuse them literally. The default should be specified as a schema constraint (not description text), or the description should not mention it at all.
Locale parameter lacks enum constraint. The description lists examples ('en', 'zh-TW', 'ja', 'ko', 'th') but does not enforce them as an enum. LLMs may pass arbitrary locale strings that the Google API rejects, causing failures without self-correction guidance.
Price level numeric constraint is incomplete. Parameter defines minimum=1, maximum=4, but description text still says '1=inexpensive, 4=very expensive' without explicitly stating what 2 and 3 mean. LLMs may guess or interpolate invalid values.