Skip to main content
Glama

Search cruises

search_cruises
Read-onlyIdempotent

Search cruises sold to the UK market by destination, departure port, cruise line, ship, months or dates, length, budget, no-fly (UK departures) and ocean or river. Names or slugs both work, and anything we can't match comes back in not_understood. query takes free text ("a week in the fjords from Southampton next June"); structured fields win where both are given. Returns up to 20 cruises a page, with prices in pounds (each with its basis and the date it was checked), month counts and Cruisify links. The cursor holds only the page number, so for the next page call again with the same fields (applied_filters, without query) and next_cursor as cursor, up to 10 pages.

Input Schema

NameRequiredDescriptionDefault
kindNoocean or river cruises only
sortNodeparture (default), price, price_per_night, nights (shortest first) or newest
queryNoFree text, read into the fields above: "a week in the fjords from Southampton next June". Structured fields win where both are given. Leave it out when paging.
shipsNoShip names or slugs
cursorNonext_cursor from the previous page. It holds only the page number, so send it with that page's applied_filters
monthsNoDeparture months, YYYY-MM
no_flyNotrue: only cruises leaving from a UK port
date_toNoLatest departure date, YYYY-MM-DD
date_fromNoEarliest departure date, YYYY-MM-DD
nights_maxNoLongest length, in nights
nights_minNoShortest length, in nights
round_tripNotrue: round trips only; false: one-way only
cruise_linesNoCruise line names, slugs or short names: "P&O", "fred-olsen"
destinationsNoDestination names or slugs: "Caribbean", "norwegian-fjords" (list_destinations has them all)
max_price_gbpNoHighest price per person, in pounds
departure_portsNoDeparture port names or slugs: "Southampton" (list_departure_ports has them all)

Output Schema

NameRequiredDescriptionDefault
pageYesThis page's number, 20 cruises to a page
totalYesHow many cruises match
resultsYesThis page's cruises
by_monthYesMatching cruises per departure month (YYYY-MM), counted without any months or dates asked for
freshnessYesfresh: up to date; stale: some dates or prices may be out of date; cache_only: from the cruises we already held
search_urlYesThis search on Cruisify
landing_urlNoThe Cruisify page for this search, when there is one
next_cursorNoThe cursor for the next page, with applied_filters; absent on the last page we give (page 10 at most)
not_understoodYesWhat was asked for but left out of the search, and why
applied_filtersYesThe search as it ran, in search_cruises' own fields. Send it back, with next_cursor as cursor, for the next page

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / results / items / properties / book_url / description
      Previous value: -"Where to book: the priced sailing, or the cruise line when there is no price"New value: +"Where to book: the priced sailing (with the cruise line, or Trip.com where it sells that sailing), or the cruise line when there is no price"
  2. Changed2 schema fields changed
    • changedOutput schema / properties / not_understood / description
      Previous value: -"What was asked for but left out of the search: tell the user"New value: +"What was asked for but left out of the search, and why"
    • changedOutput schema / properties / results / items / properties / url / description
      Previous value: -"The cruise's Cruisify page: give this link to the user"New value: +"The cruise's Cruisify page, which shows every date and the current price"
  3. First observed

TDQS

A4.2/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources