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

Goes well beyond the readOnly/idempotent annotations by disclosing data provenance, the meaning of an empty result ('no advisory is not the same as a clean test'), and an explicit safety constraint that it never calls water clean or safe. It also previews the response shape (one sentence to say aloud plus the health department link).

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 criterion and output are front-loaded in the first sentence, and every sentence carries operational or safety information. The parenthetical county roll-call ('Miami-Dade, Broward, Palm Beach, Tampa Bay, Naples, the Panhandle...') is illustrative padding that could be trimmed without loss.

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?

With no output schema, five all-optional params, and open-world retrieval, the description covers what is returned (spoken sentence plus official link), the filter modes, and the important negative-result interpretation. Nothing an agent needs to call it correctly or present results safely 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%, so the baseline is 3. The description adds real semantic value by explaining how lat/lon plus miles produce a distance-sorted result versus how place triggers name matching, and what happens when both are omitted — behavior the per-parameter descriptions do not convey.

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 resource (Florida beach water health advisories), the exact criterion (enterococcus over the state limit with no lift posted), and the data source (the 32 coastal counties' own posts). An agent can tell this apart from beach_flags or live_conditions without opening any schema.

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?

Enumerates the three invocation modes precisely: position + radius for closest-first, place for beach/county matching, and neither for all open advisories in the state. It does not explicitly name a sibling (e.g. beach_flags) as the alternative for general flag status, so routing between siblings is left partly to inference.

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