Cruisify

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered; the description adds the useful behavioral note that sailings may have no price and the response explains why, signalling a nullable field the agent should not treat as an error. The rest of the return-value summary overlaps with the output schema, so it does not push higher.

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, front-loaded with the payload summary and closed with the input rule. No filler and nothing repeated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present the description need not document return shape, and annotations carry the safety profile, so the essentials are covered. The only gap is the unspecified behavior when both or neither of url/slug are provided, which matters because zero parameters are marked required.

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 both parameters are already described there, so the baseline is 3. The description adds only the 'or' relationship — that either a full URL or a slug suffices — without addressing what happens when both or neither are supplied, even though required is empty.

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 the resource ('one cruise') and enumerates exactly what comes back: day-by-day itinerary, every future sailing with price and booking link, and the Cruisify page. That level of specificity makes it immediately distinguishable from search_cruises and the list_* siblings, which are enumeration tools rather than single-entity detail fetches.

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 ties invocation to the output of search_cruises ('Give the url ... as search_cruises returns it'), which tells the agent this is the follow-up detail call. It does not state when-not to use it (e.g. versus search_cruises for browsing), but for a detail tool the context is clear enough.

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 adds one genuine behavioral nuance — Cruisify pages exist only 'where there are some' — implying the field can be absent, but says nothing about ordering, completeness of the cruise counts, or scope limits.

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 with no filler. The trailing clause 'and their Cruisify pages where there are some' is grammatically awkward and slightly harder to parse than needed, but nothing 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?

An output schema exists, so return-value detail is not the description's burden, and there are no parameters or nested objects to document. Annotations cover the safety profile, leaving only the missing routing guidance as a 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 tool takes zero parameters, so there is no parameter semantics for the description to explain; baseline 4 applies. Schema coverage is 100% and no compensation is required.

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 resource (cruise lines we cover) and enumerates the payload: ships, upcoming cruise counts, and Cruisify page links. It is clearly a catalog-listing tool and distinguishable from get_cruise or search_cruises, though it never explicitly contrasts itself with those siblings.

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 stated alternative, and no condition under which an agent should prefer this over search_cruises or list_destinations. The catalog nature only implies usage; nothing in the text routes the agent.

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 this a read-only, idempotent, non-destructive, closed-world listing, so the safety profile is covered. The description adds that entries are annotated with UK flags, cruise counts, and page links, which is useful payload context, but it says nothing about ordering, pagination, or freshness/'we hold' implications.

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 covering resource, enrichment, and the filter, with the parameter instruction placed last. It is slightly run-on with stacked clauses, but nothing is wasted and the core purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and annotations cover the safety profile; the one parameter is documented. What remains thin is routing guidance versus the sibling list tools, but for a simple single-flag listing this is close to 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 only one boolean parameter, so the schema already carries the semantics. The description's 'uk_only for UK ports only (no-fly cruises)' largely restates the schema text, adding only the no-fly framing. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (departure ports) and scope (the cruises we hold), and states what accompanies each entry: UK marking, upcoming cruise counts, and a Cruisify page link. That is enough to separate it from list_destinations, list_cruise_lines, and search_cruises, though it never names those siblings 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?

Usage is only implied via the parameter note 'Set uk_only for UK ports only (no-fly cruises)'. There is no statement of when to prefer this tool over search_cruises or get_cruise, and no exclusions or prerequisites.

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 closed-world, so the safety profile is covered. The description adds genuine non-annotation context about what the payload contains (cruise counts, page links), but says nothing about ordering, pagination, or cost of the call.

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 sentence that is front-loaded with the resource and then the returned fields, with no filler. The trailing clause 'where there is one' is slightly awkward but conveys a real conditional about missing page links.

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 parameterless list tool with a full output schema, the description covers what is needed: the universe of entities returned and the shape of each entry. Nothing essential is missing, though ordering and completeness guarantees are unstated.

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 tool takes zero parameters and schema coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-arg operation.

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 (destinations, both ocean and river) and the payload the agent gets back: upcoming cruise counts per destination plus a Cruisify page link where available. It is clearly distinct from list_cruise_lines and list_departure_ports, though it never explicitly names or contrasts those siblings.

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 mention of alternatives like search_cruises or list_departure_ports, and no stated context for choosing this enumeration over a filtered search. The agent must infer the trigger entirely from the resource name.

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 read-only and idempotent annotations, the description discloses many important behavioral traits: UK-market scope, unmatched terms returned in not_understood, free-text parsing with structured fields taking precedence, 20 results per page, GBP pricing with basis and checked date, and a 10-page cursor limit. These are exactly the operational details an agent needs before calling the tool.

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 dense but well structured: it starts with the search scope, then query behavior, then return format, then pagination. Every sentence carries useful information, with no filler or redundant restatement.

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 16-parameter search tool with no required fields, an output schema, and safety annotations, the description is complete enough to call correctly. It covers filtering, free-text behavior, matching failures, return contents, pricing currency, and pagination mechanics, so the agent is not left guessing on material behaviors.

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 baseline is 3, but the description adds meaningful cross-parameter semantics: names or slugs are accepted, unmatched values surface in not_understood, query is interpreted into structured fields, and structured fields win. It also explains the cursor paging loop, though some of these details are also repeated from the schema descriptions.

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 and resource: search cruises sold to the UK market, with a clear list of searchable dimensions. It is easy to distinguish from sibling lookup tools such as list_destinations and from get_cruise by its search and pagination scope, though it does not explicitly name those 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?

Usage is implied through the filter list and paging instructions, but the description does not explicitly say when to use this search versus get_cruise or the list_* helpers. The query precedence rule and paging advice are helpful, but alternative-selection guidance is missing.

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