Track Rappi order ETA

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

The annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the trailing 'Read-only' just restates structured data. The description does add slight value beyond annotations: the 'unofficial' qualifier signals reliability caveats and 'live' implies a real-time-returning behavior rather than a static fetch. It does not explain what the live tracking returns or how it degrades.

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 short sentence with information front-loaded and zero filler words. It is concise, though the brevity stems partly from under-specification rather than efficient completeness, since it omits sibling differentiation that would earn its place.

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?

With 38 siblings including overlapping ETA/status tools and no output schema, the description should clarify its unique niche and its return behavior. It does not explain how 'live tracking' differs from the one-shot rappi_get_order_eta, nor what the returned data looks like, leaving an agent guessing about when this tool applies.

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 parameter meaning; it does not mention any parameter. The enums self-document two of three params (summary/structured/raw and markdown/json values are self-explanatory), and order_id is self-evident from context, but the description adds nothing about what privacy_mode changes or what each response_format produces.

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 names a specific verb+resource ('Live tracking / ETA for one order') and adds a useful scoping qualifier ('unofficial user-order-home tracking'). However, it does not distinguish itself from the near-twin sibling rappi_get_order_eta, whose name and purpose overlap heavily, so an agent cannot confidently choose between the two without opening both schemas.

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 when-to-use guidance is provided. Given 38 siblings including several ETA/status tools (rappi_get_order_eta, rappi_get_order_status, rappi_get_order), the description offers no conditions for preferring this tool, no exclusions, and names no alternatives.

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