uber_eats_add_favorite

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. The description states 'Save' implies a write/mutation operation, but doesn't disclose whether the action is reversible, whether favorites already exist are duplicated or deduplicated, whether authentication is required, or what response is returned. For a mutation tool with no annotation coverage, more behavioral transparency is needed.

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 and efficiently organized with a clear Args breakdown. The one-line purpose statement followed by parameter explanations is readable and front-loaded with the core purpose. Slightly verbose with the Args formatting that partially duplicates schema information, but generally efficient.

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 5 parameters with 0% schema description coverage and no annotations, so the description needs to do substantial work. It explains which parameters apply to which kind, which is useful. However, it does not explain return values (though output schema exists), prerequisites like being logged in, or behavior in edge cases like duplicate favorites. For a moderate-complexity tool with a kind-based branching logic, this is adequate but not complete.

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 for the schema's lack of documentation. The description does add value by explaining which parameters apply to which 'kind' (uuid/url for restaurants, restaurant for items), which is meaningful guidance beyond the bare schema. This is a good example of the description compensating for schema gaps, though it could be slightly more detailed about required vs optional fields.

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 saves a restaurant or menu item as a favorite, with a specific verb ('Save') and resource ('restaurant or menu item'). It's distinguishable from siblings which focus on cart management, checkout, search, and profile operations. However, it doesn't explicitly differentiate from any near-sibling like a 'remove_favorite' tool (which doesn't exist), so it's clear but not fully differentiated.

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 context ('Save a restaurant or menu item as a favorite') but provides no explicit when-to-use or when-not-to-use guidance or alternative tool references. The Args section provides some direction on parameter selection based on kind, but there's no explicit guidance on choosing this over other tools, though the sibling list makes it fairly obvious this is the right tool for favorites.

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