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

Annotations only declare read-only/non-destructive/closed-world, but the description adds critical interpretation semantics: empty results mean the system was not sampled under UCMR5 rather than PFAS-free, and UCMR5 is occurrence monitoring, not compliance monitoring. Those two caveats prevent the most likely agent misreporting, which is exactly what annotations cannot convey.

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?

Purpose and scope are front-loaded, then caveats, then the sibling hand-off — a sensible order. It is a dense multi-clause paragraph; the concentration units and MCL-context details are useful but make the first sentence long enough to be harder to scan than it needs to be.

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, and the description compensates by describing the shape of the return (detection set, counts, max/mean in µg/L and ppt, MCL reference values). For a single-parameter read tool, nothing an agent needs to call or interpret 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?

Schema coverage is 100% and the single parameter's description already supplies an example format ('IL0970450'). The description reinforces that the key identifies 'one water system' but adds no format, validation, or lookup-fallback detail beyond the schema, so the baseline 3 applies.

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 and resource ('PFAS results for one water system by PWSID') and pins the data source and time window (EPA UCMR5, 2023-2025). It also enumerates what is returned (sampled status, which of 29 PFAS plus lithium detected, counts, max/mean concentrations), which no sibling tool covers.

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?

Explicitly routes the agent: 'Use this for one known system; use list_systems_with_pfas_detections instead to find or rank systems with detections across a state, county, or single analyte.' It names the alternative and the exact conditions selecting each, including the case where the caller has no PWSID and needs discovery.

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