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

Beyond the annotations (readOnlyHint, idempotentHint, openWorldHint, non-destructive), the description discloses several non-obvious behaviors: no API key is required, lat/lon input silently selects the nearest prediction station, results are in local station time, and values are relative to a tidal datum (default MLLW). These are operationally important traits the annotations do not cover. No contradiction with the annotation set.

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?

Four sentences with the core function front-loaded in sentence one. Each sentence earns its place: function and data source, input modes (station vs lat/lon), output characteristics (times, heights, local time, datum), and use cases. No filler or redundant restatement of the tool name.

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 present, the description carries the output burden and does so well: it characterizes the return as high/low tide times and heights per day over an inclusive range, in local time, datum-relative. It also covers input alternatives and defaults. Minor gaps remain — failure modes for invalid station IDs or date ranges and any limits on range length — but nothing that would block 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?

Schema coverage is 100% — all 7 parameters have descriptions, so the baseline is 3. The description largely restates schema content (the '9414290' station example, MLLW default, inclusive date ranges). It adds only marginal interpretive value, such as flagging that results are in local station time, which affects how begin_date/end_date should be interpreted.

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 opening sentence names a specific verb and resource: 'Return high and low tide predictions (times and heights) from the keyless NOAA Tides & Currents (CO-OPS) public API'. The data source (NOAA CO-OPS) and output type (high/low tides) make it easy to distinguish from environmental siblings like weather_current, weather_forecast, sun_times, and water_levels without opening their schemas.

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 final sentence gives explicit use-case routing: 'Use it for tide tables, beach and boating planning, or coastal scheduling.' This tells an agent when to select this tool. However, it does not name alternatives or state when NOT to use it (e.g., real-time observed water levels would belong to the water_levels sibling), leaving exclusions to inference.

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