CruiseHops

Explore departure dates

list_departures

Read-onlyIdempotent

List bounded, paginated unique dated sailings for a public ship-itinerary group ID. Preserves cabin/date filters; older event-specific group IDs remain supported.

Input Schema

Name	Required	Description
`q`	No	Free-text cruise search; use suggest_cruise_terms to resolve precise entity names.
`page`	No	One-based result page; default 1.
`ship`	No	Source-native ship ID from items[].ship.id, not a suggestion term ID. Prefer terms for names.
`sort`	No
`view`	No	Default groups combines departures for each ship itinerary; sailings returns one row per unique dated sailing. Event-specific fares remain available within each sailing.
`terms`	No	Stable term IDs from suggest_cruise_terms; prefer these for entity-name filtering.
`dateTo`	No	Inclusive latest departure date (YYYY-MM-DD).
`source`	No	Source ID: carnival, royal_caribbean, msc, norwegian, celebrity, princess, holland_america, costa, disney, virgin, aida, tui_cruises, p_and_o, cunard.
`amenity`	No	Exact captured amenity name from get_sailing ship.amenities[].name.
`groupId`	Yes	Public ship-itinerary group ID from search_cruises items[].groupId; this is not a sailing ID. Older event-specific group IDs remain supported.
`dateFrom`	No	Inclusive earliest departure date (YYYY-MM-DD).
`pageSize`	No	Items per page, 1–50; default 3.
`returnBy`	No	Inclusive latest disembarkation date, YYYY-MM-DD; excludes unknown return dates. This deadline never expands with dateFlexDays.
`nightsMax`	No	Maximum nights, inclusive. Prefer nightsMin/nightsMax for cruise trip lengths; legacy durationMin/durationMax are days-only.
`nightsMin`	No	Minimum nights. Uses advertised nights, otherwise calendar nights between captured departure and return dates. Unknown durations cannot match.
`roundtrip`	No
`cabinClass`	No	Normalized cabin class: inside, oceanview, balcony, suite, or other, as captured on the offer.
`destination`	No	Shared destination suggestion ID or destination label. Umbrella destinations such as Caribbean include mapped subregions across cruise lines. Specific regions remain strict; generic Caribbean does not imply Eastern Caribbean. Prefer suggest_cruise_terms to resolve names.
`durationMax`	No	Maximum normalized duration in days, not advertised nights.
`durationMin`	No	Minimum normalized duration in days, not advertised nights.
`visitedPort`	No	Visited port selection: shared port suggestion ID or source-native items[].visitedPorts[].id. Reviewed equivalent ports match across cruise lines; source still restricts the line.
`dateFlexDays`	No	Optional departure flexibility, 0–30 days before dateFrom and after dateTo. Requires both dates when positive. Exact matches stay in items; outside-window options are separate dateAlternatives. All other filters remain strict. Use only when the user permits flexible dates.
`departurePort`	No	Departure port selection: shared port suggestion ID or source-native items[].departurePort.id. Reviewed equivalent ports match across cruise lines; source still restricts the line. Different embarkation ports remain distinct.
`priceMaxCents`	No	Maximum captured USD cents per person for two guests; 50000 means USD 500/person. Not a party total.
`departureTerms`	No	Port IDs from suggest_cruise_terms, matching departure only (OR within this list). General terms ports also match visited ports. Other filters still apply.
`includeUnavailable`	No

Output Schema

Name	Required	Description	Default
`kind`	Yes
`page`	Yes
`items`	Yes
`total`	Yes
`groupId`	Yes
`pageSize`	Yes
`priceContext`	Yes
`dateAlternatives`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

changedInput schema / properties / source / description

Previous value: -"Source ID: carnival or royal_caribbean."New value: +"Source ID: carnival, royal_caribbean, msc, norwegian, celebrity, princess, holland_america, costa, disney, virgin, aida, tui_cruises, p_and_o, cunard."

First observedOct 27, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds useful context: results are bounded and paginated, cabin/date filters are preserved, and older event-specific group IDs remain supported. It stops short of detailing pagination defaults or output shape, but the output schema covers return values.

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?

Two dense sentences with no wasted wording, and the core resource and scope are front-loaded. Every clause adds either scoping, pagination, filter, or compatibility information.

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

Completeness3/5

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

Given the high schema coverage, output schema, and annotations, the description is adequate for identifying the tool and its groupId anchor. However, for a 26-parameter list endpoint, it lacks guidance on when to use it versus search_cruises or get_sailing, and does not clarify the important default 'groups' view behavior.

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 description coverage is 88%, so the schema already documents nearly all 26 parameters thoroughly. The description reinforces the groupId scope and legacy-ID support, but adds little parameter meaning beyond what the schema and field descriptions already provide.

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 states a specific verb and resource: 'List ... unique dated sailings' scoped to a 'public ship-itinerary group ID.' This is clear enough to distinguish it from detail-oriented siblings like get_sailing, but it does not explicitly name or contrast an alternative tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what is listed but gives no explicit when-to-use guidance, prerequisites, or alternatives. It does not say to call search_cruises first to obtain the groupId, nor when to prefer this over compare_sailings or get_sailing.

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

All CruiseHops tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?