Track iFood order

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context by explaining that dedicated tracking URLs return 404 and that this tool reads a live GET payload, meaning data may change between calls. This goes beyond the annotation information and does not contradict it.

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 extremely compact and front-loads the critical failure mode ('Dedicated /tracking URLs 404') before giving the endpoint and safety note. Every sentence contributes without repetition or filler.

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 no output schema, the description should clarify what the agent actually receives when tracking an order, such as status fields or delivery progress. It also leaves privacy_mode and response_format semantics unexplained, so an agent cannot confidently know how to control the output or interpret the result.

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 only makes order_id inferable from the endpoint; privacy_mode and response_format are not explained at all, leaving their effects on the tracking output unclear despite having enum definitions.

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 gives a concrete verb and resource: it 'Reads the live GET /v3/customers/me/orders/:id payload' and ties that to order tracking. Mentioning that dedicated /tracking URLs 404 helps distinguish it from a literal tracking endpoint, though it does not explicitly differentiate it from sibling tools like ifood_get_order.

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?

It provides a clear workaround context: dedicated tracking URLs are broken, so this tool reads a live payload instead. However, it does not explicitly say when to prefer this over sibling tools such as ifood_get_order or ifood_get_order_eta, leaving the choice somewhat implied.

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