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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new context beyond them: the data provenance ('From Gangwaze's own schedule, which can change') warns the agent results are volatile, and it discloses a secondary output (the sailing's roll call page 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?

Three sentences, front-loaded with the primary question, and each sentence carries distinct information (lookups, roll call side effect, data source caveat). The middle clause 'with who is next' and the semicolon-joined alternatives are dense enough to slow parsing, so it stops short of 5.

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 and zero required parameters, the description carries the return-value burden, and it does describe what comes back: a director name, the next director, a ship, the next ship, and a roll call link. It does not say whether multiple matches can be returned (e.g. several ships for one director), which leaves a small gap for a lookup tool.

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 baseline is 3. The description goes further by explaining the combination semantics — that 'ship plus sail date' is an alternative way to identify a sailing — and by implying the director parameter is for the case where no ship is being asked about, which the schema does not spell out as an exclusivity rule.

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 names the exact resource (cruise director) and the two lookup directions: director-by-ship/date/sailing and ship-by-director-name. It also scopes the lines covered (Carnival, Royal Caribbean), which no sibling tool touches. The phrasing is a question rather than a verb+resource statement and the clause 'with who is next' is slightly opaque, keeping it below a 5.

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 clearly delineates the input modes: a date or one sailing for the forward lookup, and the director name for the reverse lookup ('when no ship is asked about' appears in the schema). It also states the extra condition that a sailingId or ship+sail date unlocks the roll call link. No explicit exclusions or sibling routing are given, so not a 5.

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