Skip to main content
Glama

MolTravel

by com.moltravel

ferryhopper_trip_details

[ferryhopper] Get full details for a single sailing leg, looked up by the tripId returned by search_trips_v2. Returns the trip's departure/arrival time, ports, and operating company, plus the vessel's technical specs, onboard amenities, and photos. Use this to answer questions about a vessel such as: does it have wifi / a restaurant / a snack bar / an open deck / a lift or elevator / wheelchair or disabled access / a designated smoking area? Is it pet-friendly, or does it allow pets on board? Does it have cabins, or a garage / vehicle deck for cars and motorbikes? How many passengers or vehicles does it carry (capacity)? How long is the vessel (length in meters)? What is its IMO number or MMSI (maritime identification numbers used for registry/tracking lookups)? Is this vessel accessible, family-friendly, or suitable for passengers who need mobility assistance? What does the vessel look like (photos)? If no detailed specs exist for the vessel in the source system, vessel.hasDetails is returned as false and every spec/amenity field is null — this means the data is unavailable, not that the vessel lacks that amenity. Also returns the trip's bookable accommodation tiers (seat/cabin classes) with their price and a photo of that accommodation, when available. Throws if the tripId is malformed or the trip is no longer bookable (e.g. it has already departed, was cancelled, or sold out) — re-run search_trips_v2 to get a fresh tripId in that case.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tripIdYesThe trip identifier for a single sailing leg, as returned in tripsById/bookingSolutions by search_trips_v2. Do not fabricate this value.

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description must carry the full behavioral burden. It does so exceptionally: it discloses the null semantics ('data is unavailable, not that the vessel lacks that amenity'), the exact throwing conditions (malformed tripId, trip already departed/cancelled/sold out), and the fallback action. It also mentions when hasDetails is false.

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?

This is a long description, but every sentence earns its place: purpose, primary output, example user questions, null safety semantics, error handling, and data provenance. It is front-loaded with the key lookup relationship and the fallback advice is placed exactly where the failure mode is discussed.

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?

Since there is no output schema, the description is comprehensive enough for a single-trip details endpoint: it covers what is returned, the null/unavailability construct, error behavior, and re-query strategy. The agent can select and invoke it without requiring another schema.

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?

The schema already covers tripId well with 100% coverage, including 'Do not fabricate this value.' The description adds slight value by emphasizing the tripId originates from search_trips_v2 and by tying invalid IDs to error behavior, but does not need to carry much weight here due to the excellent schema.

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?

The description leads with a strong verb+resource framing: 'Get full details for a single sailing leg, looked up by the tripId returned by search_trips_v2.' It clearly differentiates itself from sibling tools by naming the exact source of lookup and the kind of data returned (vessel details, amenities, photos).

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

Usage Guidelines5/5

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

The description explicitly says where to obtain the tripId from (search_trips_v2), what user questions it answers (wifi, access, capacity, etc.), and how to handle stale/homomorphic IDs by re-running search_trips_v2. This gives clear and actionable when-to-use guidance.

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

All MolTravel toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation3/5

Most tools are namespaced by vendor and resource, so ferry, tour, flight, hotel, and experience searches are broadly distinguishable. However, hotel search exists in both skiplagged and trivago, ferryhopper_search_trips is a deprecated duplicate of search_trips_v2, and several skiplagged calendar/anywhere tools overlap in flight-price discovery, which can cause misselection.

Naming Consistency2/5

Naming conventions are mixed across the set: plain underscores (airports_search), vendor-prefixed underscores (ferryhopper_get_ports), redundant prefixes (skiplagged_sk_hotels_search, trivago_trivago-accommodation-search), and hyphenated sub-APIs (tourradar_b2b-tour-details, tourradar_vertex-tour-search). There is no consistent verb_noun pattern and at least one version-suffixed deprecated name.

Tool Count1/5

With 56 tools, the server falls into the extreme-mismatch count band. The breadth is partly explained by eight vendor integrations, but many lookups, near-duplicate searches, and deprecated tools could be consolidated or split into focused MCP servers.

Completeness4/5

The tool surface covers most of the travel-planning lifecycle: airports, airlines, visa rules, FCDO advice, flights, hotels, cars, ferries, experiences, and tours including search, details, and tour booking. The main gaps are that only tours have an actual booking flow and there is no update/cancel or post-booking management.

Resources