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

The description discloses key behavioral traits beyond the readOnlyHint: it is an estimate rather than an observed fix, it is the heaviest call because it builds a route, and it can fail to extrapolate when the estimated_position equals the last known lat/lon. This gives the agent critical expectations about accuracy, cost, and failure semantics.

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 long but every sentence earns its place: it fronts the core purpose, then gives prioritized tool-selection guidance, and finally covers user communication and failure behavior. There is no redundant filler or repetition of the schema.

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?

Given the tool's analytical complexity and open-world context, the description is complete: it explains staleness, computation inputs, tool ordering, output caveats, and user-presentation expectations. An output schema exists, so return-value details are not required to be repeated here.

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 input schema already fully documents all three parameters and the exactly-one-of mmsi/imo/uuid requirement (100% coverage). The description adds no identifier-specific semantics, so the schema carries the parameter burden and the baseline score of 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 'estimate[s] where a vessel is right now when its last AIS position is stale,' specifying the computation inputs: last known fix, destination port, and route-based ETA. It also explicitly distinguishes this from an observed position, separating it from get_vessel and get_vessel_pro.

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 gives explicit tool-selection guidance: use get_vessel first, use get_vessel_pro for ETA/destination, and use this tool only when both the last known position is old and a destination/ETA exists. It also says to offer the estimate to the user first, making when-to-use and when-not-to-use unambiguous.

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