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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behavior beyond them: the tier.level taxonomy, far_above semantics and its clear_line wording, the blood-lead timing escalation, the unit_check / unit mix-up heuristic, and the official_guidance/official_limits/context return fields with sourcing and age gating.

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 purpose is front-loaded, but the bulk is a single run-on paragraph dense with nested parentheticals and abbreviations that is hard to parse. Most sentences carry genuine information, yet the packaging impedes scanning and would benefit from structure.

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?

No output schema exists, so the description must carry the return contract, and it does: it enumerates tier.level values, clear_line, unit_check, official_guidance with sources and age gating, official_limits, and context. For a 4-param, no-output-schema tool it is thorough enough to call correctly.

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 already 100%, so the baseline is 3, but the description adds meaning beyond the schema: unit conversion behavior ('ug/L and ug/dL are converted into the table's unit and entered shows what was typed'), the ug/L = ng/mL equivalence, and how a value >10x the highest 95th percentile signals a unit mix-up.

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?

States a specific verb (places a result among reference percentiles) and resource (CDC NHANES population percentiles), plus the scope (newest survey cycle, everyone or one age group). It is clearly distinguishable from siblings (additive_status, check_product, chemical_sources, compare_products, food_category), which do product/food/chemical-source work rather than single-result interpretation.

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?

Gives operational usage hints ('Pass unit as printed on the report', omit unit to use the key's unit) and a boundary note ('Context only, not a diagnosis'). However it never states when to reach for this over siblings like additive_status or compare_products, and gives no explicit when-not conditions, so usage is only implied.

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