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

With no annotations, the description carries the full burden, and it does substantive work: it discloses the 200-item / 50-text-item budget, the cost model for text items, the rule that magnesium, vitamin E, folic acid and niacin limits compare only against the supplement part, and the lower-bound semantics (intake_is: at_least, missing_from, unresolved). It still omits the response shape beyond status vocabulary, and says nothing about permissions, failure modes, or whether large unresolved batches are rejected.

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 dense sentences, both front-loaded: the purpose comes first, then the edge-case rules. The parenthetical 'a text item costs what resolve charges for one phrase' is compressed but earns its place by warning about cost. No filler sentences, though the second sentence packs three separate behavioral rules into one breath.

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 nested-schema tool with no annotations and no output schema, the description covers the critical semantics: what is compared, how supplement-only limits are partitioned, and how unresolved items degrade the result to a lower bound or unknown. Remaining gaps are the concrete response structure and the population/locale defaults, which the description leaves entirely to the schema.

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 top-level schema descriptions cover only about a third of parameters: items and population carry no top-level description, so the text has to compensate. It adds real meaning for items (200 cap, 50-text cap, per-text cost tied to resolve) that the schema does not state. But it says nothing about the population defaults (sex any, age 30, general, US) or how locale affects the measure calculations.

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 and resource: it checks a day of foods and supplements against recommended intakes and upper limits for a population. The scope is explicit (one day, up to 200 items, supplement-specific limits handled separately). It never names a sibling such as nutrition or reference_values, so the agent must infer differentiation from the other tool names alone.

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?

Usage is implied by the framing 'checked against recommended intakes and upper limits for a population' — use it when you have a day's intake and want a pass/fail-style assessment. There is no explicit when-not guidance, no mention of when to prefer nutrition, compare, or reference_values, and no stated prerequisites beyond the implicit need to supply resolvable items.

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