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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds substantial non-obvious behavioral context: cable_count is written as a default 0 by ingest, connectivity_grade returns null, filtering on cable_count yields nothing, and 0 must be read as UNKNOWN. This is exactly the kind of data-provenance caveat an agent cannot infer from structured fields.

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 mode are front-loaded, followed by the critical caveat, example calls, and routing exclusions. It is dense and somewhat repetitive (the cable_count/0 point is restated), but each block is load-bearing for a tool with a genuine data-quality trap.

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 an output schema present, the description needn't explain return shape, and it still supplies the unavailable-field caveat, both operating modes, defaults, worked examples, and alternative-tool routing. An agent has everything required to call it correctly and interpret the results.

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 description coverage is 100% and the schema already documents lat/lon aliases, the radius_km default of 200, and that omitting coordinates returns the catalogue. The description largely restates this mode behavior rather than adding syntax or format 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?

The description states a specific verb and resource (subsea/submarine cable landings + global cable catalogue) and explicitly distinguishes its two operating modes: coordinate-based landing-point lookup vs. no-arg catalogue. It is immediately separable from sibling fiber tools like get_fiber_intel and get_metro_fiber.

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?

It gives explicit when-to-use conditions (pass lat+lon+radius_km for landing points, omit coordinates for the catalogue), concrete example calls, and a hard 'Do NOT use for' list naming four alternatives (get_fiber_intel, get_fiber_readiness, get_metro_fiber, get_peering_intel). Nothing about tool selection is left to inference.

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