Loading ToolBench
MCP server providing access to Michelin restaurant data with filtering and search capabilities
The Michelin MCP server has 6 tools with clear naming conventions (all start with 'getAll' verb). Descriptions are present but brief (30-90 chars, below the 194-char baseline). All tools use Zod schemas with proper type definitions. However, parameter descriptions are minimal or absent in the schema objects themselves, and output schemas are completely undocumented. The server lacks error handling guidance, recovery hints, and comprehensive parameter documentation. Tools follow single-responsibility principle well, but descriptions lack WHEN/WHY guidance that LLMs need for proper tool selection.
Get a list of all awards ordered by ranking ascending.
Get a list of all cities ordered by the number of restaurants in descending order. Call again with the next offset to get more cities.
Get a list of all countries ordered by the number of restaurants in descending order. Call again with the next offset to get more countries.
Get a list of all cuisines ordered by the number of restaurants in descending order. Call again with the next offset to get more cuisines.
Get a list of all facilities and services ordered by the number of restaurants in descending order. Call again with the next offset to get more facilities and services.
Get a list of all restaurants with given filters. Do not provide empty strings or null values as filters. Omit the filter to get all restaurants.
Output schemas completely undocumented. LLMs cannot predict response structure (pagination fields, data types, field names). Tools return JSON.stringify(result) but no schema definition is visible in the code or documentation.
Parameter descriptions in Zod schemas are missing or minimal. 'offset' parameter lacks guidance on pagination semantics (what happens at end of list?). 'filter' object in getAllRestaurant has no description of how filters combine (AND vs OR?), or what happens with invalid filter values.
No error handling or recovery guidance. Tools make database calls without documented failure modes. What happens on timeout? Network failure? Invalid offset? SQL error? LLM receives no guidance on whether to retry, fix input, or abandon.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Tool descriptions are 30-90 characters, well below the 194-character baseline. They describe WHAT but lack WHEN/WHY context. 'Get a list of all cities...' doesn't explain: Should I call this first? When is pagination needed? What distinguishes this from getAllCountry in the LLM's mind?
getAllRestaurant filter parameter has complex nested object but no documentation of valid combinations, mutual exclusivity, or default behavior when multiple filters apply. The instruction 'Do not provide empty strings or null values' should be enforced server-side, not delegated to LLM.
Pagination design is unclear. offset and limit are hardcoded server-side (100 or 20). nextOffset is returned but semantics undefined, does the client always use it, or can it increment freely? What if offset > total?
Missing chaining IDs in context. Typical agent workflow: call getAllRestaurant, get restaurants, then what? Response should include enough context (restaurant_id, city, country) to enable downstream operations, but this is undocumented.