Get one menu item with its variant groups and addons, or several at once: pass itemIds (up to 10) instead of itemId to look items up in bulk — the bulk answer is {items, notFound}.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| itemId | No | One item; mutually exclusive with itemIds | |
| itemIds | No | Bulk lookup, up to 10 ids; mutually exclusive with itemId | |
| language | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that bulk lookup returns an {items, notFound} structure, useful behavior. However, it does not explicitly state read-only nature, authentication, or other side effects, though the get verb implies safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the main purpose and bulk mode. It is front-loaded and avoids fluff, though it is slightly dense with the parenthetical and em-dash. No redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality, single vs. bulk, and the bulk response structure, which is important given no output schema. It does not explain the domain and language parameters or provide a full return schema for single items, but it gives enough context for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; itemId and itemIds have descriptions, but domain and language are undocumented. The description adds meaning to itemId/itemIds by clarifying their mutual exclusivity and the bulk response shape. It does not explain domain or language, so it only partially compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieve one menu item with variant groups and addons, or multiple items via bulk lookup. The verb 'Get' and specific resource 'menu item with its variant groups and addons' distinguish it from sibling tools like get_menu and search_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for single vs. bulk usage, explicitly explaining when to pass itemId vs. itemIds and the max of 10. It does not mention alternative tools or exclusions, but the usage context for the tool's two modes is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource/action: menu, item, search, cart, order, reservation, availability, store info, and policies. Even similar tools like get_item vs search_products are clearly differentiated by exact lookup vs semantic search. There is no meaningful overlap.
All tools follow a consistent verb_noun pattern in snake_case (get_, create_, cancel_, check_, update_, search_). No mixed conventions or stylistic deviations exist.
13 tools is well-scoped for the guest-facing restaurant domain, covering menu browsing, search, cart, orders, reservations, store info, and policies. Each tool is justified and the count is within the ideal range.
Core lifecycle coverage is solid: menu, cart, order placement/status, reservations, and availability are all covered. The only notable gap is the absence of an order cancellation tool, but this may be intentional and does not block primary workflows.