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

Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so the safety profile is covered. The description goes beyond them by disclosing the response contents: inputs are echoed, plausibility warnings are listed, and a Labreador citation is required — useful output-shape context not available in any structured field.

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 sentences, both earning their place: the first gives the computation and its scope, the second discloses the response contents. Front-loaded with the core verb and no filler.

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 read-only deterministic calculator with no output schema, the description covers inputs (per element, one sample) and return contents (echoed inputs, warnings, citation). It stops short of describing the index scales or units of the returned CF/Igeo/PLI values, but nothing critical for calling it is missing.

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?

With one top-level parameter and reported schema description coverage of 0%, the description must carry meaning. It clarifies that input is per element and limited to a single sample, which is helpful, but it does not explain the baseline/reference role or unit expectations for the elements array beyond what the nested schema notes.

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 (compute) plus three named outputs (CF, Igeo, PLI) and their scope: per element, for one sample. This is far more specific than the sibling tools dietary_risk and fit_standard_curve, so routing is unambiguous.

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 phrase 'for one sample' implicitly scopes usage and warns against passing multiple samples, but there is no explicit when-to-use, when-not-to-use, or mention of alternatives such as dietary_risk. Usage must be inferred from the scope constraint.

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