get_water_quality

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

With no annotations, the description carries full behavioral burden. It discloses the data source, the ranking methodology against EPA-style thresholds, and the required site ID format. It implies a read-only operation via 'Get' and describes the nature of results. While it doesn't cover error handling or pagination, it provides substantive behavioral context beyond a bare name.

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 description is two sentences, front-loaded with the core purpose, then lists the measured parameters, the ranking system, and the ID format. Every sentence adds value with no redundancy or 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?

Despite having no output schema, the description effectively communicates what the tool returns (a list of recent results for the listed parameters, each ranked). It covers the required argument format, the data source, and the ranking scale. For a single-parameter read-only lookup, this is sufficient for correct invocation.

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?

The schema already documents the single parameter with an example, and the description essentially repeats that format. Since schema coverage is 100%, the baseline is 3. The description adds a small clarification by explaining the ranking context, but it does not add meaning beyond what the schema provides.

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 clearly states the verb 'Get' with a specific resource 'recent water-quality results' and enumerates the exact parameters (dissolved oxygen, pH, turbidity, temperature, E. coli, nitrate, phosphorus). It also specifies the data source (EPA Water Quality Portal) and the ranking scheme, distinguishing it from siblings like get_stream_flow and get_basin_health.

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 description provides clear context that this tool is for water-quality data from a monitoring site, which implicitly differentiates it from the sibling tools for flow and basin health. However, it does not explicitly state when to prefer this over alternatives or provide exclusion conditions, so it slightly misses the top tier.

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