Gangwaze Cruise Tools

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate those. It adds value by listing what fields are compared (e.g., price verdict against six-month average, CDC inspection score), giving the agent a concrete picture of the output. It doesn't disclose any side effects or error conditions, but those are covered by the read-only annotation and are not expected.

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 a single sentence that front-loads the core action and then lists the comparison fields efficiently. There is no filler or repetition, and every clause adds information about what the tool does.

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?

The description lists all the comparison dimensions, which is what an agent needs to know about the output. It also mentions the prerequisite (ids from searchCruises). Since there is no output schema, this description serves as the primary source for expected results. It could mention constraints like max 3 sailings, but that's in the schema. Overall, it's complete for an agent to decide when and how to use it.

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 50% per signal, though both parameters actually have descriptions in the schema. The description only mentions the source of ids ('from searchCruises') and does not elaborate on the cabin parameter at all. The schema already explains cabin types and ids format, so the description adds minimal semantic value beyond what the schema provides. At 50% coverage, the description should compensate more but doesn't.

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 ('compare') and resource ('sailings'), scoped to '2–3 specific sailings', and enumerates the exact comparison dimensions (dates, ports, price, verdict, ship age/size, family suitability, rating, CDC score). This clearly differentiates it from siblings like searchCruises (which finds sailings) and getPriceHistory (which shows trends).

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 explicitly says 'Takes sailing ids from searchCruises,' which establishes the prerequisite workflow: first search, then compare. It implies the tool is for comparing already-selected sailings rather than discovery. It doesn't explicitly name alternatives or when not to use it, but the reference to searchCruises gives clear usage context.

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?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses what the tool actually returns: month-by-month averages, the warmest and driest months, and a possible list of sub-region choices. This is substantial behavioral context, especially important 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?

Two sentences with no filler: the first states the core output, and the second covers the conditional list behavior. The most important information is front-loaded and every sentence earns its place.

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 tool with no output schema, the description sufficiently explains what result to expect and when a list result may occur. There is no missing critical information that would prevent an agent from selecting or invoking 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?

The schema fully documents the single 'place' parameter, including its type, required status, and an example. The main description reinforces that the place can be a port, region, or destination and adds sub-region behavior, but it does not add much beyond the schema's own parameter description, so the high-coverage 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?

The description names a specific verb-resource pair: obtain month-by-month average temperature and rainfall for a cruise port, region, or destination, plus the warmest and driest months. This clearly distinguishes it from the ship-focused and itinerary-focused siblings like getShipProfile, getCabinDetail, and searchCruises.

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 clearly states the intended input scope — a cruise port, region, or destination — and explains the behavior for places with very different sub-regions, which guides how the tool should be used. It does not explicitly name alternative tools or exclusions, but the weather-climate purpose provides clear context.

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?

While annotations already declare read-only, idempotent, and closed-world behavior, the description adds a valuable caveat that 'No issues recorded' is not a guarantee of none, disclosing data completeness limitations. It also clarifies that 'known issues' include categories like obstructed view, noise, and long walk, giving the agent accurate expectations about data quality.

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 a single, front-loaded sentence that states the core purpose and then enumerates the returned fields. It is efficient, contains no filler, and the appended caveat earns its place as meaningful additional context. Minor structural improvements are possible, but it remains compact and readable.

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?

Since there is no output schema, the description takes on the burden of explaining return contents, and it covers deck, side, position, category, size, occupancy, connecting cabin, known issues, and cruiser feedback. For a two-parameter read-only lookup, this is sufficiently complete for an agent to invoke the tool correctly and interpret 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?

The input schema already fully covers both parameters with descriptions, examples, and patterns (100% coverage). The description only restates 'by ship and room number' without adding new semantic detail, so a baseline score of 3 is appropriate per the rubric.

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 identifies the tool as retrieving details for one specific cabin, identified by ship and cabin number. It lists the exact information returned (deck, side, position, category, size, occupancy, connecting cabin, issues, cruiser feedback), which distinguishes it from sibling tools like getShipCabins that likely handle broader cabin listings.

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 implies usage for a single-cabin lookup through 'One specific cabin by ship and room number,' but it does not explicitly state when to use this tool over alternatives. It also does not mention getShipCabins or other siblings, so the guidance is implicit rather than 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 declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds the scope of a single line and the specific data categories returned, but it does not disclose behavior such as error handling, data freshness, or how ratings are aggregated.

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 a single compact sentence that front-loads the scope ('One cruise line') and then lists the key data categories. There is 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?

For a simple one-parameter read-only tool, the description covers the main return categories well. There is no output schema, so a bit more detail about the exact response shape could help, but the listed contents are sufficient for an agent to know what information is available.

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 single 'line' parameter is already documented with examples. The description does not add additional meaning to the parameter itself, so the baseline 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 identifies the resource (one cruise line) and enumerates the profile contents: traveler-type descriptions, ratings, tier, and fleet size. It is distinguishable from siblings like getShipProfile because it is line-level, though it does not explicitly name alternatives.

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 guidance on when to use this tool versus alternatives such as getShipProfile or searchCruises. The content implies it is for cruise-line-level profile information, but no when-to-use or when-not-to-use direction is provided.

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 and idempotentHint, so the safety profile is covered. The description adds topical detail but does not disclose any additional behavioral traits such as data availability, matching behavior, or response format. It is adequate but adds no behavioral context beyond the annotations.

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, well-structured sentence that front-loads the core subject ('A cruise line's dress code') followed by a compact colon-separated list of coverage areas. Every element adds value and there is 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?

Given a single fully-documented parameter, no output schema, and annotations covering the read-only/idempotent nature, the description provides enough information for an agent to call the tool correctly. It could additionally state whether results vary by line or whether some lines lack data, but that is a minor 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?

The only parameter, 'line', has 100% schema description coverage with an example ('Royal Caribbean'). The tool description does not add parameter-level details, but the schema fully documents the parameter, so the baseline 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 uses a specific verb-resource pairing ('get' + 'dress code') and enumerates the exact content areas covered: daytime/evening rules, formal nights, jeans/shorts/swimwear, venues, and theme nights. This clearly distinguishes it from sibling tools like getCruiseLineProfile or getShipProfile.

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 clearly establishes the domain: cruise line dress codes. It does not explicitly name alternatives or when-not-to-use conditions, but the resource is specific enough that an agent can infer when to select it. No prerequisites or exclusions are needed for this simple read query.

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 and idempotentHint, so the safety profile is covered. The description adds useful behavioral context by specifying the scope of results (package names, value, daily limits, gratuity) and the cruiseline filter dimension.

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 a single compact sentence with a colon-separated list of returned details, front-loading the resource and scope. There is no filler or redundant material.

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 optional parameter, read-only/idempotent annotations, and a description that lists the return contents, an agent has enough information to select and invoke this tool correctly. The lack of an output schema is compensated by the explicit list of returned fields.

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 optional parameter, and the schema already explains 'Cruise line name; omit for all lines'. The description adds minimal semantic value beyond what the schema provides, so the baseline 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 identifies the tool's resource (beverage packages by cruise line) and enumerates the specific returned details: package names, maximum drink value, daily limits, and gratuity. None of the sibling tools target drink packages, so it is readily distinguishable.

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 context is implied: it provides beverage-package details and can be filtered by cruiseline. However, it does not explicitly state when to use this tool instead of alternatives like getCruiseLineProfile or when not to use it.

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 description correctly implies a read-only lookup of bookable offerings with a link to book externally, which is consistent with readOnlyHint and idempotentHint. It does not delve into behavioral details like response format, pagination, or availability, but annotations reduce the burden here.

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 conveys the resource, the data returned, and the port context. No filler or repetition of the 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 one-parameter read-only tool with no output schema, the description gives enough context about what the user gets: price, duration, rating, and link. It could be more explicit about the response shape or result limits, but the simplicity of the tool keeps gaps minor.

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 documentation covers the single 'port' parameter fully with format and example, and the description reinforces that it is a cruise port. Since schema coverage is 100%, the description does not need to compensate much for parameter meaning.

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 retrieves shore excursions and resort day passes for a cruise port, and lists meaningful result attributes. It is distinct from sibling tools like getPortGuide or searchCruises, though it doesn't explicitly contrast with them.

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 context is clear: use it when excursion or day-pass options for a specific port are needed. However, there is no explicit when-not-to-use guidance or mention of sibling alternatives such as getPortGuide for general port information.

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 and idempotentHint, so the safety profile is covered. The description adds value by specifying the scope of information (comfort, safety score, wifi, car rental) beyond the annotations. No contradictions or hidden side effects are mentioned, which is appropriate for a read-only operation.

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 that immediately states the resource type and then lists specific topics. No wasted words, and the key information is presented in an efficient, scannable manner.

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 guide with one parameter and no output schema, the description covers the content scope well. It doesn't mention output format (text vs structured) or error handling for unknown ports, but given the low complexity and existing annotations, these omissions are minor. The description is effectively complete for an agent to decide whether to call it.

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 supplies full parameter documentation with 100% coverage and an example ('Cozumel'). The description does not add extra syntax or constraints, which is acceptable given the schema's completeness. Baseline 3 is appropriate when the schema already carries the parameter meaning.

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 ('get') and resource ('port guide') and enumerates the covered topics (beaches, shopping, terminals, etc.), which clearly distinguishes it from sibling tools like getPortExcursions and getBestTimeToVisit. The agent can identify exactly what this tool returns without ambiguity.

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 implicitly signals that this is the general-purpose port guide, as opposed to siblings focused on specific aspects (excursions, timing, cabins). There is no explicit 'use for X, not for Y', but the content list makes the intended use inferable. A slight boost for clarity, but it lacks an explicit contrast with alternatives.

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 provide readOnlyHint=true, idempotentHint=true, and openWorldHint=false, covering the basic safety profile. The description adds output field details and the 'biggest' qualifier, but does not disclose any additional behavioral traits such as result limits, data source, or pagination. It does not contradict annotations.

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 a single concise sentence that front-loads the core purpose and then lists the returned fields. Every word adds value, with no filler or redundancy.

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 tool with one optional parameter and no output schema, the description should explain the parameter and result semantics. It lists return fields but omits any explanation of 'limit' and does not clarify whether results cover all cruises or a subset. An agent cannot confidently invoke the tool correctly without this missing context.

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 only parameter, 'limit', has a schema definition with minimum and maximum but no description. Schema description coverage is 0%, and the tool description does not mention the parameter at all, leaving its purpose and effect on results completely unexplained. 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?

The description clearly states the tool returns the biggest current cruise price drops and lists the specific fields included (cabin type, prices, percent dropped, sail date, booking link). It implicitly differentiates from siblings like getPriceHistory by emphasizing 'current', but it does not explicitly name alternatives.

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 tool's purpose implies it should be used when current price drops are needed, but the description gives no explicit guidance on when to prefer it over related tools like getPriceHistory or searchCruises. There is no mention of when not to use it or alternative conditions.

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 establish readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond annotations by listing the exact return components (history, average, percent, verdict, drop-list status) and the required input source, which is especially important given there is no output schema. No contradiction.

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 carry all essential information: the purpose, the output list, and the input source. The most critical detail (what the tool returns) is front-loaded, and there is zero filler or repetition of schema content.

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, two-parameter tool with no output schema, the description adequately covers the return value composition and input provenance. It does not define the 'verdict' logic or response format, and it omits the optional cabin parameter in prose, but the schema covers the parameter and the tool's simplicity keeps these gaps minor.

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 id and cabin are already documented in the schema. The description reinforces that the id comes from searchCruises, which the schema example also shows, but it adds no meaning for the cabin parameter. With high schema coverage, the baseline 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 opens with a specific verb ('Judge') and resource ('one sailing's current fare'), then enumerates the concrete outputs: six-month history, average, percent above/below, verdict, and price-drop membership. This clearly differentiates it from sibling tools like compareSailings (multi-sailing comparison) and getPriceDrops (likely just the drop list).

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 states the input must be a sailing id from searchCruises, implying a sequential workflow. However, it gives no explicit guidance on when to choose this tool over getPriceDrops (which overlaps on the price-drop list) or compareSailings, and provides no exclusions or prerequisites beyond the id source.

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 declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate those. The description adds content context (what data is returned) but does not disclose any additional behavioral traits such as output format, potential errors, or scope limitations. With annotations covering safety, a score of 3 is appropriate.

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 a single sentence that is front-loaded with the core grouping and immediately lists the included data categories. It contains no filler or redundant wording, making it highly efficient.

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 tool with one parameter and no output schema, the description adequately conveys the return content (categories, counts, size range, occupancy, guarantee categories). It does not mention possible limitations or output structure, but these are not critical for a simple lookup. It is nearly complete, though it could hint at the difference from getCabinDetail.

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 the 'ship' parameter with an example. The description does not add any parameter-level meaning beyond what the schema provides, 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?

The description states a specific verb and resource: get cabins, grouped by type, and explicitly lists the data provided (categories, counts, size range, occupancy, guarantee categories). It clearly distinguishes this from sibling tools like getCabinDetail (which likely handles specific cabins) and getShipProfile (general ship info).

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 does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites beyond the required ship parameter. While the purpose is clear, it leaves the agent to infer usage context from the sibling names alone.

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 and idempotentHint=true, so the safety profile is covered. The description adds context about the returned data (e.g., CDC inspection score, venues, editorial) but does not disclose additional behavioral aspects like error handling, rate limits, or data freshness. It does not contradict the annotations.

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 a single, front-loaded sentence that efficiently lists the data categories without fluff. It is concise and immediately communicates the scope, though it could be slightly more structured (e.g., separating core attributes from editorial details).

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 profile lookup with one parameter, the description adequately covers what the tool returns. It lists all major data fields, and since there is no output schema, this serves as the primary documentation. It does not mention edge cases or pagination, but those are unlikely for a single-ship profile.

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 'ship' is fully described in the schema with an example ('Carnival Breeze') and coverage is 100%. The description does not add extra meaning beyond the schema, 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?

The description clearly states the resource (one ship) and enumerates the specific data categories (year built, size, guests, crew, cabin counts, ratings, etc.), making it unambiguous what this tool returns. It distinguishes itself from siblings like getShipCabins (which focuses on cabin details) and getCruiseLineProfile (which is about the cruise line).

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 implies this is for retrieving a comprehensive ship profile, but it does not explicitly state when to use this tool versus alternatives such as getShipCabins or getCruiseLineProfile. There is no mention of exclusions or conditions, leaving the agent to infer usage from the content description alone.

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 openWorldHint, so the description correctly does not repeat the safety profile. It adds genuinely useful behavior: the 'omitted fields are unfiltered' rule and the deterministic soonest-first ordering, plus the 10-sailing cap and the external gangwaze.com link. No contradiction with annotations.

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 with the purpose front-loaded, followed by the key behavioral rule and then the return contract. Zero filler; every clause earns its place. Appropriate for a 20-parameter tool whose heavy detail lives in 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?

With no output schema, the description correctly takes on the return contract, disclosing match count, cheapest fare, top lines, the 10 soonest sailings and the external link. Combined with 100% schema coverage of all 20 parameters, nothing an agent needs to invoke it correctly 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 description coverage is 100% with extremely detailed per-parameter guidance (formats, mapping rules, OR-ed behavior), so the baseline is 3. The description adds only a high-level enumeration of filter dimensions and the nights 'lo:hi' format hint; it does not meaningfully extend what the schema already documents, but it does not need to.

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 — search upcoming cruise sailings — and enumerates the filter dimensions (destination, region, dates, length, line, ship, port, etc.). It is clearly distinct from the sibling get*/compare* tools, which perform different operations; the return statement even names compareSailings/getPriceHistory as downstream consumers, reinforcing what this tool is not.

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?

Provides clear context that this is the entry-point search tool whose returned ids feed into compareSailings/getPriceHistory, giving an agent an implicit call sequence. It does not, however, explicitly state when not to use it or name an alternative for a different need, so it stops short of full exclusion guidance.

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