uber_eats_search_history

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 doesn't state whether this is read-only, whether results are paginated, how many results are returned, the ordering of results, or what the output schema looks like. The parenthetical '(API)' hints at a data source but adds little insight.

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 concise sentence that communicates the core purpose efficiently. There is no wasted verbiage. It could add a couple more useful details (e.g., result count, ordering), but the brevity itself is not a flaw.

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?

Despite having an output schema and zero parameters, the description is thin. For a zero-parameter retrieval tool, it doesn't explain what to expect from the output (beyond 'recent search queries'), how many items, or whether the results are time-ordered. The output schema exists but the description doesn't orient the agent on what data will come back. Adequate minimum but with gaps.

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 tool has 0 parameters, so the schema fully covers the parameter surface — there's nothing to document. The description need not add parameter semantics when no parameters exist. The baseline 4 for zero-parameter tools is appropriate.

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 'Recent search queries from the user's Uber Eats search history (API)' identifies the resource (search history) and scope (recent queries). It distinguishes from siblings like uber_eats_search and uber_eats_recommend by focusing on historical queries rather than performing searches. However, it lacks a clear verb and could be more explicit about what 'recent' means.

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?

No guidance on when to use this tool versus alternatives. It doesn't contrast with uber_eats_search (which presumably performs a search) or clarify that this is for retrieving history for analysis/recall rather than executing a new search. The context is implied by the name and description but no when/when-not guidance is given.

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