iFood privacy audit

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a small but meaningful behavioral hint: the tool is concerned with privacy redaction defaults and fail-closed behavior. It does not, however, explain what kind of audit output to expect, whether it scans across orders/merchants, or what 'fail-closed' concretely means for the returned data.

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 short—seven words—so it is concise by volume. But it is closer to a tagline than a specification. It front-loads the core idea, yet omits the verb and resource needed to make those words useful. A good short description can be one sentence, but this one does not fully earn its brevity because it leaves key interpretive work to the agent.

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?

For a tool with no output schema, no parameter documentation, and a cryptic description, an agent has very little to go on. The annotations confirm it is a safe, read-only, idempotent operation, which is useful, but the description does not explain what an audit contains, how to interpret 'redaction defaults' or 'fail-closed checkout,' or how the response_format affects the output. Given the 0% schema description coverage and absent output schema, this is a significant completeness gap.

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 carries the burden. However, with only one parameter (response_format), which is an enum with a default, the parameter is effectively self-documenting: markdown vs json output. The description doesn't mention the parameter, but little is lost because the enum names are self-explanatory and the schema provides the default. The description could have noted how the audit output is structured, but the parameter itself is simple.

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 phrase 'Redaction defaults and fail-closed checkout' suggests an audit-related operation about privacy redaction and checkout security, which is somewhat actionable. However, it lacks a clear verb and resource: it doesn't explicitly say what the tool does (e.g., 'audit', 'list', 'review') or what it operates on, leaving an agent to infer the tool's scope and distinguish it from the many iFood sibling tools.

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 provides no explicit guidance on when to use this tool versus alternatives like ifood_checkout, ifood_get_order, or ifood_connection_status. The term 'fail-closed checkout' implies a relationship to checkout or security/privacy auditing, but the description does not state conditions, prerequisites, or exclusions, so an agent cannot reliably determine when it should be invoked.

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