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

Annotations already declare read-only/non-destructive, so the bar is lower; the description still adds real context beyond them — the UCMR5 sampling-coverage caveat and the default sort by max concentration. It does not discuss result pagination or how ties are broken, but nothing contradicts the 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?

Three dense sentences, zero filler, with the identify-and-sort behavior front-loaded before the filter options and the coverage caveat last. Every clause carries information.

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, yet the description still conveys what comes back (systems, ordered worst-first), what filters do, and the critical limitation that unsampled systems are omitted. An agent can call this correctly and interpret empty results without further information.

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 100%, so baseline is 3, but the description adds semantics the schema lacks: county requires state, and passing an analyte changes the ranking key ('rank by that analyte's maximum'). That is genuine value beyond the parameter descriptions.

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?

Specific verb+resource ('List water systems') with precise scope ('at least one PFAS detection under EPA UCMR5 occurrence monitoring 2023-2025') and even the default ordering ('worst first by maximum detected concentration'). It is clearly distinguishable from the system-level sibling get_system_pfas and from list_contaminants_with_violations.

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?

Explains the three filtering modes (state, county-requires-state, single analyte) and when the analyte filter changes ranking. It also gives an interpretation rule: 'absence means not sampled, not PFAS-free.' It does not explicitly name when to prefer a sibling (e.g. get_system_pfas for one system), so it stops short of 5.

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