justeat_restaurant_menu

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral disclosure burden. It transparently describes what the response contains: item fields (name, description, image, price, calorie text), modifier_groups for customizable items, and the special behavior for non-restaurant stores ('All items' category). This is useful and specific, though it does not mention pagination, error cases, or regional limits.

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 compact but contains minor redundancy: the first and second sentences both express that a full menu is returned. All sentences do contribute useful context (item fields, modifiers, non-restaurant behavior) and it is front-loaded with core purpose, but a small tighten would improve it.

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?

Given a single parameter and no output schema, the description adequately describes the returned data shape and key behaviors. It does not mention error conditions or how to obtain unique_name (but the schema says from search responses), so it is near complete for practical use.

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?

The only parameter 'unique_name' is fully described in the input schema as 'Restaurant slug, from a search response's unique_name field', giving 100% schema coverage. The description itself adds no additional parameter guidance beyond the main purpose, so it remains at the baseline 3.

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 states a specific verb and resource: 'Get one Just Eat restaurant's menu with prices', and clarifies it returns a full menu grouped into categories. This clearly separates it from the sibling 'justeat_restaurant' (likely a restaurant info tool) and other menu tools for different services.

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 implies usage: if an agent needs a Just Eat restaurant's menu, this is the tool. However, it does not explicitly state when not to use this or point to alternatives, such as justeat_restaurant for restaurant details or justeat_search for finding restaurants. This is merely implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.