Skip to main content
Glama

Find and rank cruises with today's prices

search_cruises
Read-only

Accepts the request in plain words (q) or as fields. Searches every sailing Fantasize tracks (23 cruise lines, ~30,000 sailings, priced every night) by region, dates, departure port, ports visited, line, length, cabin and budget. Returns up to 25 sailings with the price per person (taxes and port fees in), per night and for a cabin of two, every cabin grade's price, whether the fare is low, typical or high against that sailing's usual price, the ports of call, and book_url - a link the person opens to book that exact sailing. Default ranking is best_value (furthest below its usual price).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoThe person's request in plain words, e.g. "alaska in july from seattle, balcony, under $3000 for two". Read by fixed rules; the answer says how it was understood and which words were not. Any other argument given overrides what q says.
lineNoCruise line, e.g. "Royal Caribbean", "NCL", "Princess", "Viking"
shipNoShip name or part of it
sortNobest_value
tierNo
cabinNoCabin grade to price. Omit to quote balcony where sold, else the next grade.
limitNo
monthNoDeparture month, YYYY-MM
regionNoWhere the cruise goes: caribbean, bahamas, alaska, mexico, mediterranean, northern-europe, european-rivers, asia, repositioning, hawaii, bermuda, panama-canal, south-america, antarctica, australia, ... (every region with sailings on sale)
calls_atNoA port the ship must visit, e.g. "Juneau", "Santorini", "Cozumel"
depart_toNoLatest departure date, YYYY-MM-DD
from_portNoDeparture port, e.g. "Seattle" or "Barcelona"; several comma-separated: "Miami,Fort Lauderdale"
nights_maxNo
nights_minNo
depart_fromNoEarliest departure date, YYYY-MM-DD
only_below_usualNoOnly fares measurably below their usual price
max_price_per_nightNoBudget per person per night, USD
max_price_per_personNoBudget per person for the whole cruise, USD

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / region / description
      Previous value: -"Where the cruise goes: caribbean, bahamas, alaska, mexico, mediterranean, northern-europe, european-rivers, asia, repositioning, hawaii, bermuda, panama-canal, south-america, antarctica, australia, ... (cruise_options lists them all with counts)"New value: +"Where the cruise goes: caribbean, bahamas, alaska, mexico, mediterranean, northern-europe, european-rivers, asia, repositioning, hawaii, bermuda, panama-canal, south-america, antarctica, australia, ... (every region with sailings on sale)"
  2. Changed1 schema field changed
    • addedInput schema / properties / q
      Added value: +{
      +  "description": "The person's request in plain words, e.g. \"alaska in july from seattle, balcony, under $3000 for two\". Read by fixed rules; the answer says how it was understood and which words were not. Any other argument given overrides what q says.",
      +  "type": "string"
      +}
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: nightly re-pricing, default best_value ranking ('furthest below its usual price'), a 25-result cap, and the fare-vs-usual classification. It doesn't mention pagination or latency, so not 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the two input modes then moves to results, so the agent reads the important routing fact first. Dense but every clause carries information; only the long enumeration of returned fields borders on over-stuffing.

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?

Covers input modes, searchable dimensions, default ranking, result cap, and full return shape for a complex 18-param tool with no output schema. Nothing needed to invoke or interpret results is missing given the annotations cover the safety profile.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 72%, above the 80% baseline region, and the schema documents most params well (date formats, comma-separated ports, region list). The description restates the searchable axes but adds little syntax-level meaning beyond the schema; the q-override hint is the main value-add.

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

Purpose5/5

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

States a specific verb and resource ('Searches every sailing Fantasize tracks'), defines searchable dimensions, and describes the return payload (per-person/per-night pricing, cabin grades, value rating, ports, book_url). An agent can distinguish this as the primary search/rank tool against siblings like get_cruise (single detail) and last_minute_cruise_deals (narrowed subset).

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?

Implies the tool's role (search across all sailings, natural-language or structured input) and notes that explicit args override what q says, but never states when to prefer compare_cruise_lines, cruise_options, or last_minute_cruise_deals. No exclusions or alternative-selection guidance, so the agent must infer routing from sibling names alone.

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