uber_eats_get_address

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

With no annotations provided, the description carries the full burden. It discloses the key behavioral trait: 'no login browser' - meaning this tool works without requiring authentication. This is valuable context. It doesn't describe pagination or return format, but for a zero-parameter getter that returns the current address, this is largely sufficient. However, it doesn't explicitly state whether the call is read-only (though implied).

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?

Two sentences, both earning their place. The first sentence states purpose, the second gives usage guidance with explicit precedence over uber_eats_login. Zero waste, front-loaded with the core purpose. Excellent structure for a tool description.

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?

This is a simple zero-parameter getter with an output schema present. The description is complete for the agent's needs: it explains what it returns, that it works without login, and when to prefer it. The only minor gap is not describing what the output structure looks like, but since an output schema exists, the description needn't explain return values. Given its simplicity, this is well-covered.

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?

With 0 parameters and 100% schema coverage, the schema has nothing to document, so baseline is 4. The description provides context on what the returned value represents (current delivery address from saved config), which adds meaning beyond the empty schema. No parameter detail is needed since there are no parameters.

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 what the tool does: retrieves the current delivery address from saved session/config. It distinguishes it well from siblings like uber_eats_saved_addresses and uber_eats_set_address by emphasizing it reads from saved session/config without login. The phrase 'current delivery address' is specific and clear, though it could be slightly more explicit about being a read-only getter.

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 explicitly tells the agent when to use this tool: 'Prefer this (with get_preferences) before uber_eats_login when starting a chat.' This provides a clear precedence instruction and names the companion tool (get_preferences) and the alternative to avoid (uber_eats_login). This is excellent usage guidance that maps to the 'when to use' dimension.

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