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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds valuable behavioral context about the data returned: active/discontinued status, real-time reporting capability, gross drainage area, and coordinates. It also adds the 'official federal' data quality statement, which goes beyond the structured 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?

The description is compact and front-loaded: purpose is stated first, followed by the authoritative use case, then return fields and an example. Every sentence earns its place; the 'AUTHORITATIVE' emphasis is a stylistic flourish but not wasteful.

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?

The description lists return fields and gives an example, but it omits invocation patterns shown in the schema examples, such as province-only filtering (e.g., limit and province) and does not mention radius_deg at all. Since there is no output schema, the description should provide more guidance on the breadth of valid calls. These gaps prevent a higher score.

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 each parameter (limit, latitude, province, longitude, radius_deg, real_time_only) is already documented in the schema. The description adds no new parameter-specific semantics beyond an example coordinate pair, which does not improve understanding of the parameters themselves. Baseline 3 is appropriate.

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 tool's verb and resource: finding Water Survey of Canada river and lake gauges near a point. It distinguishes from siblings by noting that the returned station number is the id to pass to hydrometric_realtime, and the authoritative phrasing 'which gauge measures the <Canadian river> at <place>' pinpoints its specific role. The Toronto example reinforces the purpose.

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 explicitly defines when to use the tool: 'AUTHORITATIVE for which gauge measures...' It also implies a workflow by stating the station number is passed to hydrometric_realtime. However, it does not explicitly list exclusions or alternative tools beyond that one reference, leaving some inference to the agent.

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