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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds genuine context on data provenance and behavior ('label data only; food is included only with diet typical') and enumerates the returned fields. It does not cover latency, resolution failure behavior, or the non-exhaustiveness of interaction checking (that caveat only appears in the schema), keeping it out of 5 territory.

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 core capability is front-loaded in the first sentence, and the enumerated outputs and return fields are each load-bearing given there is no output schema. It is dense rather than padded, though the return-field list reads somewhat as an inventory and the total length is near the upper bound for a single tool description.

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 complex 11-parameter tool with no output schema, the description compensates well by naming agent_summary, resolutions, suggestions, interactions, nutrient_totals and data_gaps, plus the summary-vs-full size trade-off. Edge-case behavior (unresolved products, empty results) and interaction-checking limits remain undocumented here, so it is strong but not exhaustive.

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 coverage is 91%, so the baseline would be 3, and the description clears that bar by adding meaning the schema does not: candidate products are evaluated as additions and excluded from nutrient_totals, and conditions 'change how NIH reads a dose'. It also summarizes the four accepted product forms. It could have clarified servings defaults or the life_stage constraints, but the added semantics are substantive.

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 (checking a supplement stack for a person) and enumerates the concrete outputs: per-nutrient totals vs NIH UL/RDA-AI, product overlaps, UL rationale, and single-product fixes. That is well beyond a tautology. It stops short of a 5 because it never distinguishes itself from the sibling interactions_check, which also covers medication interactions, leaving a real ambiguity unresolved.

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 gives clear conditional guidance: pass medications and conditions to check interactions, use candidate products for 'considering adding', and use diet "typical" versus explicit foods. What is missing is exclusionary routing — no statement of when to call interactions_check or nutrients_reference instead, so sibling selection is left to inference.

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