Cruisify

Get one cruise

get_cruise

Read-onlyIdempotent

One cruise in full: the day-by-day itinerary, every future sailing with its price (or why there isn't one) and a booking link, and its Cruisify page. Give the url of a Cruisify cruise page, as search_cruises returns it, or the cruise's slug.

Input Schema

Name	Required	Description	Default
`url`	No	A Cruisify cruise page URL, as search_cruises returns it
`slug`	No	A cruise's slug: the last part of its URL

Output Schema

Name	Required	Description
`url`	Yes	The cruise's Cruisify page, which shows every date and the current price
`kind`	Yes	ocean, river or expedition
`ship`	Yes	The ship's name
`route`	Yes	Where it starts and ends: "Round trip from Southampton", "Southampton to New York"
`title`	Yes	The cruise's title
`nights`	Yes	Length in nights
`sailings`	Yes	Every future sailing
`itinerary`	Yes	Day by day, with consecutive days in one place as one row
`cruise_line`	Yes	The cruise line's name
`description`	Yes	A short description, or null
`destinations`	Yes	The destinations it visits, the main one first

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 5, 2026

addedOutput schema / properties / sailings / items / properties / book_via

Added value: +{
+  "description": "Who book_url sends the visitor to: the cruise line, or Trip.com where it sells this exact sailing",
+  "enum": [
+    "cruise_line",
+    "trip.com"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / sailings / items / required

Previous value: -[
-  "departure_date",
-  "return_date",
-  "sold_out",
-  "price",
-  "price_note",
-  "book_url"
-]New value: +[
+  "departure_date",
+  "return_date",
+  "sold_out",
+  "price",
+  "price_note",
+  "book_url",
+  "book_via"
+]

Changed1 schema field changedOct 9, 2026

changedOutput schema / 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"

First observedOct 9, 2026

TDQS

A4.2/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Cruisify 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?