Loading ToolBench
A restaurant order management MCP server for miyamo2 diner that allows searching menus and accepting orders.
Two tools with basic schemas and descriptions present, but multiple critical gaps prevent higher scoring. Naming follows verb_noun pattern (search_, accept_) and starts with action verbs, which is good. However, descriptions are generic and lack depth. Parameter descriptions exist but lack contextual detail about constraints and dependencies. No output schema documentation. Error handling is absent, the accept_order tool silently skips invalid orders without informing the agent. The schema quality is moderate: parameters have types and descriptions, but several lack actionable constraint information (e.g., category enum is mentioned in description but not formally constrained in schema).
miyamo2 diner will accept your order and return the total amount in Japanese yen.
searchs miyamo2 diner's menu for dishes matching your criteria.
Missing output schema documentation. Neither tool documents what fields the response will contain or their types. LLMs cannot plan downstream operations or extract the right data without knowing response structure.
Category parameter in search_menu has valid values documented only in description text ('main | tapas | dessert | beverage') but not as a formal JSON Schema enum constraint. LLMs cannot reliably parse text descriptions of enums, this should be formalized as enum:["main","tapas","dessert","beverage"].
No error handling or recovery guidance. The accept_order tool silently skips orders with invalid menu names or zero quantity (via 'continue' statements in main.go). LLMs receive no signal that an order was rejected, they cannot self-correct or ask the user for clarification.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
Descriptions lack depth and actionable context. 'searchs miyamo2 diner's menu for dishes matching your criteria' is too generic, it does not explain when to use this tool (e.g., 'Call this first to browse the menu and find dishes by name, price range, or category before placing an order'). Average description length is 30-50 chars; baseline for A+ tools is 194 chars.
Parameter 'name' in search_menu is optional but semantically ambiguous, is it a substring match or exact match? The implementation does exact match ('*arguments.Name != menu.Name'), but this is not documented. LLMs may expect fuzzy/partial matching.
No pagination or result limits on search_menu. If the menu grows large, responses could return hundreds of items, wasting tokens and degrading LLM reasoning. No mention of limiting results or fetching in pages.
Missing case-sensitivity warning in search_menu. The description says nothing about case sensitivity, yet the code does exact string matching. If a user asks for 'pizza' (lowercase) instead of 'Pizza', the search silently returns no results instead of suggesting corrections.