uber_eats_suggest_cart

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the tool 'analyzes the menu' and recommends categories (mains, sides, drinks), but doesn't disclose whether it reads-only or writes to cart (the name 'suggest_cart' suggests it suggests rather than adds, but this isn't explicitly stated). Whether it mutates the cart vs. just proposes is ambiguous and should be disclosed given zero annotation coverage.

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 efficient: a one-sentence purpose statement followed by a short Args block. No wasted words or redundant elaboration. It's front-loaded with the core purpose before details. Slightly truncated by the absence of behavioral notes, but what's present is tight.

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 tool has an output schema (presumably describing the suggested cart), hosts 2 parameters, and zero annotations. The description covers purpose and both params, but lacks disclosure about whether suggestions are added to cart or just displayed, what happens if the restaurant_url is invalid, and how preference data is sourced. For a suggestion tool these are meaningful gaps, though the output schema may cover return format.

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 0%, so the description must compensate. It does add meaning for both parameters: restaurant_url is explained as 'Restaurant URL or slug' and social_context as 'Who you're eating with (alone, couple, family, friends)' with illustrative examples. However, the values for social_context are only implied in prose, not enumerated, and the description doesn't fully clarify what constitutes a valid restaurant_url. Acceptable but could go further.

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 'Suggest what to order from a specific restaurant based on group size and preferences' with a specific verb+resource (suggest cart for a restaurant) and mentions it 'analyzes the menu and recommends mains, sides, and drinks.' It distinguishes reasonably from siblings like uber_eats_recommend (general recommendations) and uber_eats_restaurant_menu (menu viewing) by being cart-focused. However, it doesn't explicitly contrast with the similarly-flavored uber_eats_recommend.

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 when to use it (when you need order suggestions from a specific restaurant for a group), and the social_context parameter signals the grouping use case. However, there's no explicit when-not-to-use guidance or alternatives mentioned, leaving the agent to infer distinction from similar tools like uber_eats_recommend and uber_eats_add_to_cart.

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