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

Annotations declare readOnlyHint=true, so the description doesn't need to state the operation is read-only. The description adds crucial behavioral context: it details the return structure (name, macros, serving label, source, note) and, critically, warns that `source` is the user's own claim, not a server-verified guarantee. This is exactly the kind of nuance that goes beyond annotations.

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 bit long, but every sentence earns its place: it explains purpose, return contents, use case, conceptual distinctions, and the source caveat. Some redundancy exists ('their staples' and 'curated list of what they stock' overlap), but the structure is front-loaded and information-dense. It could be slightly tighter, so 4.

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?

There is no output schema, so the description must carry the burden of explaining return values – and it does: 'Returns each item's name and, when the user saved them, macros...a serving label, a source, and a short note.' It also explains the nontrivial caveat about source trustworthiness. For a tool with zero params, this description fully covers what an agent needs to know.

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 trivially covers 100%. Per the rubric, 0 params earns a baseline of 4. The description doesn't waste space on parameters, and it doesn't need to. It focuses on output semantics instead, which 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 opens with 'Read the user's PANTRY' – a specific verb + resource. It goes further to differentiate the pantry from 'what they've logged (their diary)' and 'their frequents', clearly distinguishing this tool from sibling tools like get_day or get_range. This is a textbook example of purpose clarity.

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 states the tool is for 'suggesting meals from what they actually have' and 'pre-fill macros when they log one', giving practical use cases. It implicitly says when NOT to use it by separating pantry from diary and frequents, but does not explicitly name alternative tools by their tool names (e.g., 'use get_day for diary'). Since the distinction is clear, it earns a 4 rather than a 5.

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