Gangwaze

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

Annotations already declare readOnly, idempotent, non-destructive and non-openWorld, so the safety profile is covered. The description adds the valuable behavioral detail of what data the comparison surfaces, which is the main thing an agent needs to judge usefulness.

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?

Front-loaded with the verb and scope, then a dense but purposeful enumeration of compared attributes. The second sentence on id provenance is short and earns its place; the field list is long but each item is information the agent needs.

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, the description correctly takes on the burden of describing return content, and it does so thoroughly. The only gap is the cabin parameter's effect on pricing and the 2–3 id limit, which remain schema-only.

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 50% and both parameters already carry inline descriptions in the schema. The description only reinforces that ids come from searchCruises and says nothing about the cabin filter or the 2–3 id cardinality constraint, so it adds little beyond the schema baseline.

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?

States a specific verb (compare) plus the exact resource (2–3 specific sailings) and enumerates the compared dimensions: dates, ports, price, price per night, verdict vs six-month average, ship age/size, family suitability, rating, CDC score. It is clearly distinct from the sibling searchCruises, which it identifies as the source of ids.

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?

"Takes sailing ids from searchCruises" establishes the prerequisite workflow step and implies this is the follow-up to a search. It gives no explicit when-not-to-use or alternative comparison tool, but the context is clear and no competing sibling exists.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and a closed-world scope, so the safety profile is covered. The description adds real behavioral value beyond them: it warns that a place with very different sub-regions returns a list instead of a single answer, which changes how an agent must handle the response. It does not mention rate limits or data freshness, keeping it out of 5 territory.

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?

Two sentences, no filler. The core output content is front-loaded and the edge-case caveat follows it, so an agent gets the essential meaning first.

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 one parameter, full schema coverage, and a complete annotation set, the description covers what the tool returns and the one non-obvious response shape. It lacks any note on result limits or data recency, but nothing critical for correct invocation is missing.

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% and the schema already defines 'place' with an example, so the baseline would be 3. The description goes further by classifying what counts as a place ('port, region or destination') and by explaining that ambiguous place names resolve to a list of candidates, which adds interpretive meaning for the one required parameter.

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 exactly what the tool returns: month-by-month average temperature and rainfall for a cruise port, region, or destination, plus warmest/driest months. That is specific enough for an agent to separate it from data-oriented siblings like getPortGuide or searchCruises. It stops short of naming any sibling, so it does not earn 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?

Usage is implied rather than stated: an agent can infer this is the tool for climate/seasonality questions, but there is no explicit 'use this when... instead of...' routing against getPortGuide or searchCruises. The note about sub-region lists is edge-case behavior, not guidance on when to choose this tool.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds real value by enumerating the returned attributes and by warning that '"No issues recorded" is not a guarantee of none' — an interpretive caveat an agent scoping a recommendation genuinely needs.

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?

Two sentences, zero filler. The scope statement leads, the returned fields follow, and the caveat is deliberately placed last rather than buried mid-sentence.

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, the description correctly carries the burden of describing the response and does so thoroughly, plus a useful caveat. The only gap is behavior when the ship or cabin does not exist (error vs empty result), which an agent might want to know.

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 both parameters carry examples ('Allure of the Seas', '9318' or 'D126'). The description restates that lookup is by ship and room number but adds no new constraint or format detail, so the baseline of 3 is correct.

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?

States a specific verb and resource ('One specific cabin by ship and room number') and then enumerates exactly what is returned (deck, side/position, category, size, sleeps, connecting cabin, known issues, cruiser reports). The emphasis on 'one specific cabin' implicitly separates it from the list-style sibling getShipCabins.

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 makes the use case clear (look up a single cabin identified by ship and cabin number), so usage is implied, but it never names an alternative or an explicit when-not condition. An agent must infer that getShipCabins is the list-level counterpart rather than being told.

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

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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed-world lookup, so the safety profile is covered. The description usefully adds the scope of returned data (ratings with review counts, tier taxonomy, fleet size), but says nothing about name-matching behavior, miss handling, or freshness of ratings.

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?

A single dense sentence with the resource stated first and the return contents listed after the colon. Every clause carries information, though the comma-separated inventory is slightly list-heavy.

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, the description does the right thing by summarizing what comes back, which is adequate for a simple one-parameter lookup. It still omits what happens when the name does not resolve and whether partial names are accepted, which an agent would need for reliable 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% and the single 'line' parameter is documented with examples ("Carnival", "Seabourn"). The description contributes only the phrase 'one cruise line', adding no format, matching, or normalization detail beyond the schema — baseline 3.

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?

States a specific verb implied (fetch) and resource (one cruise line), and enumerates the payload contents: traveler-type descriptions, ratings, tier, fleet size. It is implicitly distinguishable from the sibling getShipProfile because it scopes to the line rather than a ship, but it never names or contrasts with that sibling explicitly.

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?

There is no when-to-use guidance, no statement of prerequisites, and no mention of alternatives such as getShipProfile for vessel-level data. Usage is only inferable from the description of returned content.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real value by disclosing that every answer links deck plan pages and, importantly, that venue records are incomplete — an unlisted venue means unrecorded, not missing.

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 is front-loaded and every clause carries information: the modes, example values, the link guarantee, and the completeness caveat. The opening sentence is long and heavily parenthetical, which slightly hurts scanability but avoids waste.

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 only three flat parameters and no output schema, the description covers the mode selection, the kind of answer returned, and the key data-quality caveat. The remaining gap is the combined-parameter case (venue plus deck), which an agent may reasonably need to know.

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 the baseline is 3, but the description adds meaning beyond the schema: venue accepts a kind of venue ("bars"), and the response adds forward/midship/aft and port/starboard positioning. The one gap is not stating what happens when both ship, deck, and venue are supplied together.

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?

States a specific resource (deck plans) and verb-like behavior (locate venues/facilities and their deck positions) with three explicit query modes. An agent can immediately distinguish this from getShipCabins or getShipProfile without opening the schema.

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?

Explicitly describes the three invocation modes: pass venue, pass deck, or pass neither, each with an example value ("pizza", "theater", "10"). It does not name a sibling tool to prefer for cabin-specific questions, so the routing to alternatives is left implicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. Because there is no output schema, the description carries the burden of describing what the response contains, and it does so concretely (overall style, daytime/evening rules, formal-night frequency, jeans/shorts/swimwear and venue rules).

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?

A single compact sentence, front-loaded with the resource and followed by the content list. It is a noun fragment rather than a sentence, but every clause maps to actual returned content, so little is wasted.

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?

For a read-only, single-parameter lookup with no output schema, the main risk is the agent not knowing what comes back — the enumeration of returned content addresses that. An explicit statement that only a cruise line name is needed to call it would close the remaining gap.

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% for the single 'line' parameter, including an example ("Royal Caribbean"), so the baseline is 3. The description adds no syntax or format detail beyond what the schema already provides.

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 specific resource (a cruise line's dress code) and enumerates its sub-topics — daytime/evening rules, formal nights, venue rules, theme nights — which clearly separates it from getCruiseLineProfile or getShipProfile. It is a content inventory rather than a verb+resource statement, but the resource and scope are unambiguous.

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?

There is no guidance on when to call this versus siblings such as getCruiseLineProfile (which likely also carries line-level policy). No prerequisites, no exclusions, no indication that the caller should already know the cruise line.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds real value by disclosing the shape of the returned data (drink value caps, daily limits, gratuity), which matters because no output schema exists.

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?

One sentence, no filler, with the resource and the returned-content list front-loaded. Every clause earns its place by telling the agent what it gets back.

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?

For a no-required-param read-only lookup with no output schema, the description covers both scope and the fields returned, and annotations handle the safety semantics. The only gap is the absence of any routing guidance among the twelve sibling lookup tools.

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 single parameter has 100% schema description coverage ('Cruise line name; omit for all lines'), so the schema fully carries parameter meaning. The description's 'by cruise line' phrasing is consistent with it but adds nothing beyond the schema; a 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?

Names a specific resource (beverage/drink packages) and enumerates the returned fields (package names, max drink value, daily limits, gratuity), which clearly separates it from siblings like getDressCode or getCabinDetail. It lacks an explicit verb, but the scope is unambiguous.

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?

There is no explicit when-to-use or when-not-to-use statement, and no alternative sibling is named. Usage is only implied by the 'by cruise line' framing plus the schema's 'omit for all lines' note, which is enough to infer a filtered lookup but not documented guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description adds value by disclosing the result payload shape (price, duration, rating, link) despite there being no output schema, plus the refinement workflow of re-issuing the same query with added price bounds. It does not mention result counts, ranking, or rate limits, which keeps it short of a 5.

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 tight sentences, front-loaded with what the tool returns, then filtering parameters, then the refinement pattern, then the sibling alternative. Each sentence carries distinct information and nothing is repeated from the schema or annotations.

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, the description carries the payload description job and does it (price, duration, rating, link), and it covers the port/activity/price workflow plus the sibling alternative. Minor gaps remain: no indication of result volume, ordering, or truncation behavior for a broad port query.

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% with per-parameter descriptions (units, examples, omit-behavior), so the baseline is 3. The description adds interaction semantics the schema cannot express: that narrowing by price requires repeating the same port and activity parameters, clarifying cross-call parameter coupling.

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?

States a specific verb+resource (bookable shore excursions and resort day passes in a cruise port) and enumerates the returned attributes (price, duration, rating, link). It explicitly draws the boundary against the closest sibling by naming getSailingExcursions for the multi-port case, so an agent can route without opening either schema.

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?

Gives explicit when-to-use conditions: pass activity to narrow by kind, minPrice/maxPrice to narrow by price, and re-call with the same port+activity to refine an earlier answer by price. It also names the alternative (getSailingExcursions) and the exact condition that selects it, leaving nothing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful context about what the guide contains, but it does not disclose return format, response size, or any behavioral constraints beyond what annotations provide.

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?

A single front-loaded sentence listing the guide's contents. Every item earns its place by telling the agent what information is returned, with no filler.

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?

For a simple one-parameter read-only lookup with no output schema, the description adequately enumerates the returned guide's coverage areas, which compensates for the missing output schema. It could be slightly more complete by noting the return format, but no critical calling information is missing.

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?

There is only one parameter, and the schema describes it fully ('Port name, e.g. "Cozumel"') at 100% coverage. The description adds no parameter-level detail such as naming conventions or common aliases, so the baseline score of 3 applies when the schema carries the full burden.

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?

States a specific resource ('cruise port') and enumerates the guide's coverage areas, which implicitly distinguishes it from siblings like getPortExcursions by focusing on general port information rather than bookable tours. It is clear what the tool returns, though it does not explicitly name an alternative.

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?

Usage is implied by the content list (use it to learn about a port's amenities, safety, and logistics), but there is no explicit when-to-use guidance or mention of when another sibling tool would be better. No prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds nothing behavioral beyond that: no default limit, no sort order for 'biggest', no refresh/pagination behavior, and no statement of what makes a drop qualify as 'biggest'.

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?

One compact sentence with the resource front-loaded and no filler, which is efficient. However, the bulk of the sentence is a return-field list rather than purpose or usage, so the space is not optimally spent.

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, the description usefully enumerates the returned fields (cabin type, prices, percent dropped, sail date, booking link), which covers the return shape. It still omits sorting, default limit, and any caveats needed to call a ranked-list tool correctly.

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 single 'limit' parameter has 0% schema description coverage, and the description never mentions it, its bounds (1-10), or its default when omitted. The word 'biggest' hints at sorting but does not connect it to the limit parameter, so the description fails to compensate for the schema gap.

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?

States a specific resource (current cruise price drops) with a clear intent of surfacing the biggest drops. It distinguishes itself implicitly from getPriceHistory by the 'current' framing, but never names a sibling or contrast explicitly, so an agent must infer the boundary itself.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as getPriceHistory or searchCruises. An agent gets a topic but no routing logic for choosing this tool over the price-related siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the analytic outputs (six-month history, average, percent deviation, verdict, price-drop membership), which matters since no output schema exists.

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?

Two tight sentences with the payload front-loaded and zero filler; the prerequisite sentence follows the outcome sentence logically.

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, the description carries the return-value burden and does so by enumerating the five things the agent gets back. Combined with annotations covering safety and 100% schema coverage on inputs, nothing material is missing for 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 description coverage is 100%, so both parameters (id and cabin) are already documented, including the cabin enum and the id format example. The description only adds provenance for the id ("from searchCruises") and says nothing about the cabin filter, so 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?

Specific verb (judge) and resource (one sailing's current fare), with an enumeration of exactly what the tool returns. It explicitly scopes to a single sailing, which cleanly separates it from sibling getPriceDrops (a list) and compareSailings (multi-sailing comparison).

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 names the source of the required id ("from searchCruises"), which establishes the intended call order and prerequisites. It gives clear context but stops short of naming an explicit alternative or a when-not-to-use condition, e.g. against compareSailings.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds real substance by disclosing the selection logic (up to three picks per port that fit the time ashore with an hour to spare before all aboard) and the per-port outputs (hours ashore, totals). It stops short of describing pagination or failure modes.

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?

Dense but front-loaded: what it returns, then the selection guarantee, then how to supply a sailing, then filters, then the sibling alternative. Every clause carries information, though the description packs several ideas into three long sentences.

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, the description does the work of explaining the return shape (hours ashore, up to three picks, per-port totals) and the cross-port filter behavior. Remaining gaps are minor for a read-only, idempotent 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 clarifying that activity and minPrice/maxPrice narrow EVERY port rather than a single port, which is a cross-parameter behavior the schema does not express. The sailing-id-vs-ship/date relationship is also restated usefully.

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?

States a specific resource (shore excursions), the scope (every port of one sailing, one call, itinerary order) and explicitly distinguishes itself from getPortExcursions. An agent can identify it without opening the schema.

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?

Gives both routing ('Use this instead of calling getPortExcursions once per port') and input alternatives (a sailing id from searchCruises, or ship plus sail date). When-to-use and which sibling to avoid are both explicit.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), but with no output schema the description usefully discloses the returned payload: cabin categories, counts, size range, occupancy, and guarantee categories. It omits pagination/ordering behavior, keeping it from a 5.

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?

A single front-loaded sentence naming the resource and grouping before enumerating fields; no filler or repetition of annotations. The field list is dense but each item is informative.

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?

For a read-only, single-parameter lookup with full annotation coverage, the definition gives the agent enough: what is queried and what is returned. Only the missing sibling differentiation and any result ordering limits keep it below complete.

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 there is a single required 'ship' parameter fully documented with an example in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 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?

States a specific verb (get) and resource (a ship's cabins) plus the grouping dimension and returned fields, so the agent knows exactly what comes back. It does not differentiate itself from the sibling getCabinDetail, which is the closest candidate for confusion, so it stops short of 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?

There is no when-to-use or when-not-to-use guidance. Nothing tells the agent to prefer this over getCabinDetail for per-cabin information, and no prerequisites (e.g., a valid ship identifier source) are given.

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

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

With annotations already declaring readOnly/idempotent, the description still adds substantial context: data is derived from schedule and charted route rather than live GPS/AIS, it is exact at port calls and estimated in transit, and times are port-local. This is precisely the kind of accuracy caveat an agent needs before presenting the result to a user.

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?

Content is front-loaded with the core answer and the accuracy caveat follows immediately. The first sentence is dense with three parenthetical cases but every clause carries information; nothing is redundant.

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?

No output schema exists, yet the description still tells the agent what comes back (upcoming stops, approximate coordinates, tracker and sailing links) and how reliable it is. That is complete for a single-parameter lookup.

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?

There is only one parameter ('ship') and the schema documents it fully at 100% coverage, including an example. The description adds no additional parameter meaning, so it sits at the baseline for well-covered schemas.

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 opens with a specific verb-phrase and resource ('Where a ship is right now') and then enumerates the three distinct states the tool resolves: in port, at sea, between sailings. This is unmistakably different from siblings like getShipProfile or searchCruises, so an agent can route to it without inspecting the schema.

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 scenario is clear — use this when you need the ship's current location and upcoming stops. There is no explicit when-not or named alternative, but for a single-purpose lookup tool the implied context is unambiguous.

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

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

The annotations already declare readOnlyHint, idempotentHint, non-destructive behavior, and closed-world scope, so the safety profile is covered. The description adds useful behavioral scope by listing the profile fields returned, including editorial content and CDC inspection data, though it does not discuss permissions or response formatting.

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 two sentences: the first front-loads the tool purpose and data scope, and the second routes the agent to the right alternatives. Every sentence earns its place with no redundant restatement of the name or title.

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?

For a read-only, single-parameter profile tool with no output schema, the description is complete: it enumerates the returned data categories and points to sibling tools for related questions. The annotations cover safety behavior, and no critical invocation detail is missing.

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 schema has 100% description coverage and already documents the single 'ship' parameter with an example, so the schema does the heavy lifting. The description adds no additional syntax or naming guidance beyond what the schema provides.

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 opens with 'One ship:' and then enumerates the exact profile data returned, making the verb+resource purpose unmistakable. It also explicitly distinguishes this tool from getDeckPlan, getShipPosition, and getCruiseDirector, so an agent can select it without opening the schema.

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 names three alternative sibling tools and gives the precise condition for each: venue/deck questions go to getDeckPlan, current location goes to getShipPosition, and cruise director goes to getCruiseDirector. This is explicit when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds valuable behavioral detail beyond that: omitted filters remain unfiltered, results are always soonest first, and the response contains the match count, cheapest fare, top lines, 10 soonest sailings with IDs, and a gangwaze.com link. It does not cover rate limits or auth prerequisites, but the annotations carry the safety profile.

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 three tight sentences with no wasted wording. It front-loads the search purpose and filter breadth, then immediately explains filtering semantics and return behavior. Dense but appropriate for a 20-parameter search tool.

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?

No output schema exists, so the description must explain return values, and it does: match count, cheapest fare, top lines, 10 soonest sailings, ordering, IDs for follow-up tools, and a full-results link. Combined with the fully documented input schema and read-only annotations, an agent has everything needed to call the tool correctly.

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%, so the schema already documents every parameter in detail. The description mentions broad filter categories and the nights "lo:hi" format, but it does not add meaning beyond the schema's per-field documentation. A baseline score of 3 is appropriate when the schema does the heavy lifting.

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: "Search upcoming cruise sailings". It enumerates the scope of filters and the return shape, and names compareSailings/getPriceHistory as follow-up tools for the returned IDs. An agent can distinguish this search tool from the sibling detail/profile tools 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 description gives clear usage context: pass the full filter set, omitted fields are unfiltered, and results are always soonest first. It does not explicitly state when not to use this tool or name an alternative search tool, so it falls short of a full when/when-not/alternatives statement.

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