Ferryhopper

Server Details

The Ferryhopper MCP server is a connector for LLMs and AI Agents in maritime travel that exposes ferry routes, schedules, and booking options. It enables AI assistants to search ports and connections across 33 countries and 190+ ferry operators, provide real-time ferry itineraries with indicative prices, and assist users with planning island-hopping or multi-leg journeys by processing natural language queries about ferry times, passenger counts, and travel durations.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 54 days
Last Tested: 2026-10-10 18:30
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.1/5.0

Scored 2026-09-24 10:05 across 6 tools

Disambiguation4/5

The tools are mostly distinct: search_ferry_trips handles multi-leg searches, trip_details provides vessel/amenity details, get_ports finds ports, get_disruptions finds travel issues, and get_direct_connections_for_ports finds reachable destinations. The only overlap is search_trips, which is explicitly deprecated in favor of search_ferry_trips, so an agent could be confused about which to call, but the deprecation note mitigates this.

Naming Consistency4/5

Most tools follow a consistent get_/search_ verb + noun pattern (get_ports, get_disruptions, get_direct_connections_for_ports, search_ferry_trips, trip_details). trip_details breaks the pattern slightly by not having a verb prefix, and search_trips is a shorter variant of search_ferry_trips, but overall the naming is predictable and readable.

Tool Count5/5

Six tools is well-scoped for a ferry travel domain: port lookup, route discovery, trip search, trip details, and disruption info. Each tool covers a distinct user need without redundancy, and the deprecated search_trips is the only extra weight.

Completeness4/5

The surface covers the core ferry booking workflow: find ports, find connections, search trips, get trip details, and check disruptions. A notable gap is the lack of a booking or fare-comparison tool, but the server appears focused on search/discovery rather than booking, so the coverage is reasonable for that scope.

Available Tools

6 tools

get_direct_connections_for_portsGet Direct ConnectionsA

Read-only

Inspect

Find all direct ferry routes and reachable destination ports from a given origin port without layovers or transfers.

ParametersJSON Schema

Name	Required	Description	Default
`portLocation`	Yes	Location name or search term used to find matching ports (not limited to exact port codes).

Output Schema

ParametersJSON Schema

Name	Required	Description
`departurePort`	Yes	The name of the departure port
`connectedDestinations`	Yes	List of ports directly connected to the departure port

TDQS

A4.3/5.0

Behavior4/5

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

The description adds the behavioral constraint of returning only direct, non-stop routes, which goes beyond the readOnlyHint annotation. The annotation already establishes that the operation is read-only and safe; the description enriches this by clarifying the filtering behavior. It does not mention edge cases like empty results, but given the readOnlyHint and the presence of an output schema, this is adequate.

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 a single, well-structured sentence that front-loads the main action and key constraint. It is concise without sacrificing necessary information, making it easy to parse quickly. No unnecessary words or repetition.

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?

Given the tool's simplicity (one parameter, read-only operation), full schema coverage, and existing safety annotations, the description provides all necessary context. It explains what the tool does, the direct-route filter, and the origin port requirement. The return value structure is presumably covered by the output schema, so there are no obvious gaps.

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 has 100% coverage for the portLocation parameter, describing it as a 'Location name or search term used to find matching ports'. The tool description adds that this is the origin port ('from a given origin port'), clarifying the parameter's role beyond the generic schema description. This is meaningful additional context, though not extensive.

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 clearly states the tool's function: finding direct ferry routes without layovers. It uses a specific verb 'Find', specifies the resource 'direct ferry routes and reachable destination ports', and includes the key differentiator 'without layovers or transfers' which distinguishes it from trip search tools like search_trips that may include connections. An agent can immediately understand its purpose and difference from siblings.

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?

The description implies usage when direct connections from a single origin are needed, as it explicitly states 'without layovers or transfers'. However, it does not name alternative tools like search_trips or provide explicit when-not-to-use conditions. The usage context is only implied, not clearly delineated with alternatives or exclusions.

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

get_disruptionsGet DisruptionsA

Read-only

Inspect

Find all ferry travel disruptions, including delays, weather alerts, and strikes for a given date and country.

ParametersJSON Schema

Name	Required	Description	Default
`country`	Yes	ISO 3166-1 alpha-2 country code to filter disruptions by country (e.g. "GR" for Greece).
`tripDate`	Yes	Departure date in ISO format YYYY-MM-DD (e.g. 2026-03-15).

Output Schema

ParametersJSON Schema

Name	Required	Description
`disruptions`	Yes	List of active disruptions matching the requested date and country.

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate the tool's read-only nature. It adds a small behavioral detail by listing the types of disruptions (delays, weather alerts, strikes), which provides context, but it does not disclose any side effects or limitations beyond what annotations already indicate. The description aligns with the annotations.

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 a single, well-structured sentence that front-loads the primary action ('Find all ferry travel disruptions') and packs the scope ('for a given date and country') efficiently. Every word contributes to conveying the tool's purpose without redundancy or filler.

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?

The tool has a clear purpose, two required parameters with thorough schema descriptions, an output schema (so return format is assumed to be known), and annotations covering the safety profile. The description is sufficient for an agent to understand when to invoke it and what inputs to provide. No critical information about calling the tool is missing, though it does not mention any pagination or filtering nuances.

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 100%, with both parameters (country and tripDate) having clear descriptions including format examples. The description's phrase 'for a given date and country' simply repeats what the schema already documents. It adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.

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 uses a specific verb 'Find' and names the resource 'ferry travel disruptions' with concrete examples (delays, weather alerts, strikes). The tool name 'get_disruptions' is also specific, and it is clearly distinct from siblings like search_trips or trip_details, which focus on connections and itineraries. The purpose is unambiguous.

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?

The description does not explicitly mention when to use this tool versus alternatives, but the purpose is clear enough that an agent can infer it should be used when disruptions are relevant. It does not provide any 'when not to use' guidance or mention sibling tools, so usage is implied rather than explicit.

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

get_portsGet PortsA

Read-only

Inspect

Find ferry ports, harbors, maritime terminals, port IDs, codes, and geographic locations.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`ports`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered at the structured level. The description adds a preview of what results contain (IDs, codes, locations) and does not contradict the annotations. It omits scope (all ports vs. regional), ordering, or pagination, but with a zero-parameter read tool this is a modest gap.

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?

A single front-loaded sentence with no filler. The only minor issue is mild redundancy in the list ('ferry ports, harbors, maritime terminals' are overlapping categories), but it is short, scannable, and every clause contributes meaning.

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?

For a zero-parameter, read-only listing tool with an output schema, the description is essentially complete: it states what is found and what the caller receives. It could note whether the port set is exhaustive or filtered by a region, but nothing an agent needs to invoke it correctly is missing.

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?

There are 0 parameters, so the baseline is 4 — there is nothing to describe beyond the schema, which is empty. The description usefully signals what the caller can expect back (port IDs, codes, geographic locations), which is the meaningful semantic content for a param-less listing tool.

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 has a specific verb ('Find') and a clear resource class: ferry ports, harbors, and maritime terminals, plus what it returns (port IDs, codes, geographic locations). It is distinct from the siblings, which cover trips, disruptions, and connections. However, it doesn't name or explicitly contrast any sibling, so differentiation is left implicit.

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 context is implied by the resource type — this returns port identifiers that would feed sibling tools like trip or connection lookups — but there is no explicit when-to-use guidance or mention of alternatives. The purpose is self-evident enough that an agent would not misroute it, but no exclusion or priority is stated.

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

search_ferry_tripsSearch Ferry TripsA

Read-only

Inspect

Search ferry trips as an ordered chain of 1 to 5 legs. Takes human-readable location names (e.g. city or port name) for each leg, not port codes — no need to call get_ports first. Availability flags (cabin, vehicles, pets, e-ticket) are reported per segment.

One leg: a plain one-way search.
Two legs where leg 2 reverses leg 1 (e.g. leg 1 Piraeus→Mykonos, leg 2 Mykonos→Piraeus): a round trip.
Up to 5 legs otherwise (e.g. A to B, then B to C, then C to D): an island-hopping chain.

Legs after the first must depart from the location the previous leg arrived at, and must be in chronological order (a later leg may share the same date as an earlier one, but may not precede it).

The response returns each leg's available options independently (legs[].options) — options are never filtered against another leg's options. Consecutive legs must leave enough time between one leg's arrival and the next leg's departure to be a valid connection; this is not pre-filtered server-side or reflected in this output, so do not assume every combination of options across legs is a valid connection — the widget the user interacts with enforces this.

ParametersJSON Schema

Name	Required	Description	Default
`legs`	Yes	An ordered chain of sailing legs. A one-way search is a single leg. A round trip is 2 legs where leg 2 reverses leg 1 (e.g. leg 1 Piraeus→Mykonos, leg 2 Mykonos→Piraeus). An island-hopping chain is up to 5 legs, e.g. A→B, then B→C, then C→D. Each leg after the first must depart from the location the previous leg arrived at.

Output Schema

ParametersJSON Schema

Name	Required	Description
`legs`	Yes	One entry per requested leg, in chronological order. For a one-way search this has 1 entry. For a round trip (2 legs where leg 2 reverses leg 1) index 0 is outbound and index 1 is the return. For a longer island-hopping chain there are 2-5 entries, one per leg.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds significant behavioral detail beyond that: availability flags per segment, that legs[].options are independent and not filtered against each other, that connection validity is not pre-filtered server-side, and that the widget enforces it. These are non-obvious behaviors that the agent must know to interpret results correctly. No contradiction with annotations.

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?

The description is longer than average but every section earns its place. It front-loads the core purpose and then uses bullet points to clarify leg patterns. The connection-validity caveat is important and placed at the end. It is structured and readable, not verbose or repetitive. Slight deduction for length, but justified by the tool's complexity.

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?

Given the complexity of multi-leg searches, the description covers all critical operational details: leg ordering, human-readable location names, independent option reporting, and the lack of server-side connection filtering. It also clarifies that the widget enforces connections, which prevents the agent from over-promising. With an output schema present, the description needn't detail return fields. Nothing an agent needs to call this correctly is missing.

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 coverage is 100% for the only parameter (legs), and the schema itself provides detailed descriptions with examples. The description adds further semantics by explaining the leg chain patterns (one-way, round-trip, island-hop), reinforcing that locations are human-readable rather than port codes, and clarifying the chronological ordering constraint. This adds value beyond the schema, so a 4 is appropriate.

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 opens with a specific verb and resource: 'Search ferry trips as an ordered chain of 1 to 5 legs.' It clearly distinguishes itself from sibling tools by specifying human-readable location names instead of port codes and by covering multi-leg chains (one-way, round-trip, island-hop). This goes beyond a generic statement and fully differentiates it from tools like get_direct_connections_for_ports and search_trips.

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?

The description provides strong usage context: it explains when to use it (one-way, round-trip, multi-leg) and explicitly states that there's no need to call get_ports first. It also describes the constraints on leg ordering. It does not explicitly name alternative tools or say 'use X instead,' but the context is clear enough for an agent to decide. A small deduction for not explicitly excluding cases better served by a sibling.

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

search_tripsSearch Trips (Deprecated)A

Read-only

Inspect

Deprecated: prefer search_ferry_trips, which covers this tool plus round-trip and multi-leg search and per-segment availability flags. Get a list of available one-way ferry trips between two ports on a specific date.

ParametersJSON Schema

Name	Required	Description
`date`	Yes	Departure date in ISO format YYYY-MM-DD (e.g. 2026-03-15).
`arrivalLocation`	Yes	Arrival location as a human-readable name or search term (e.g. city, port name), not a port code.
`departureLocation`	Yes	Departure location as a human-readable name or search term (e.g. city, port name), not a port code.

Output Schema

ParametersJSON Schema

Name	Required	Description
`foundDirectItinerariesForTrip`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

Annotations (readOnlyHint=true, openWorldHint=true, destructiveHint=false) cover the safety profile. The description adds the deprecation status and the one-way scope, but doesn't disclose other behavioral details like pagination or result ordering. Since annotations already convey safety, a 3 is appropriate for the moderate added context.

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 concise sentences. The deprecation notice is front-loaded, immediately guiding the agent away from this tool, followed by a crisp purpose statement. No redundant or filler content.

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?

Given the output schema exists, return values are covered elsewhere. The description explains the deprecation, the alternative, and the exact scope. All required parameters are documented in the schema. An agent has everything needed to decide whether to use this tool and how to call it correctly.

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 100%, so the schema already documents each parameter (date, arrivalLocation, departureLocation) with clear descriptions. The tool description adds no additional parameter information beyond what's in the schema, so baseline 3 applies.

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 the exact function: list one-way ferry trips between two ports on a date. Explicitly names the replacement tool (search_ferry_trips) and the additional features it provides, clearly distinguishing it from siblings. The verb 'Get a list' is specific and the resource is defined.

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?

Explicitly instructs to prefer search_ferry_trips and explains why (covers this tool plus round-trip, multi-leg, per-segment flags). This gives clear when-to-use guidance and names the alternative. The scope is unambiguous: one-way trips on a specific date between two ports.

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

trip_detailsTrip DetailsA

Read-only

Inspect

Get full details for a single sailing leg, looked up by the id of one of the options returned by search_ferry_trips (legs[].options[].id). 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_ferry_trips to get a fresh tripId in that case.

ParametersJSON Schema

Name	Required	Description	Default
`tripId`	Yes	The trip identifier for a single sailing leg, as returned in legs[].options[].id by search_ferry_trips. Do not fabricate this value.

Output Schema

ParametersJSON Schema

Name	Required	Description
`trip`	Yes
`vessel`	Yes
`vesselImages`	Yes	Vessel photos ordered for display (e.g. in a carousel). Empty if no photos are available.
`accommodations`	Yes	Bookable accommodation tiers for this trip (seat/cabin classes), one entry per fare code as priced by the source system — multiple entries may share the same type/image at different prices (e.g. different berth counts within the same cabin category).

TDQS

A4.8/5.0

Behavior5/5

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

Even though annotations declare readOnlyHint and destructiveHint, the description adds substantial behavioral context: the null-when-no-details semantics, accommodation tier return, and throwing behavior for malformed or stale tripIds. It also correctly conveys the open-world nature of missing vessel data.

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?

The description is longer than average but every section earns its place: purpose, usage examples, null semantics, return contents, and error recovery. It is front-loaded with the core purpose, and the question list, while somewhat extensive, is a useful set of concrete queries the tool can answer.

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?

Given the output schema exists, the description does not need to enumerate return fields, yet it still covers key result categories, null behavior, error conditions, and recovery steps. An agent has everything needed to decide when to call it and how to react to failure.

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 documents tripId's provenance and warns not to fabricate it, so the baseline is 3. The description adds extra value by clarifying that a stale or malformed tripId causes a throw, and by framing tripId as the id of a single sailing leg option. This goes slightly beyond the schema without contradicting it.

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 states a specific verb and resource: 'Get full details for a single sailing leg', and ties the lookup to an id from search_ferry_trips. It clearly distinguishes this from sibling search/list tools by focusing on per-trip detail retrieval.

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 when to use the tool ('Use this to answer questions about a vessel'), where the tripId comes from, and what to do if the trip is no longer bookable: 're-run search_ferry_trips to get a fresh tripId'. This gives clear, actionable routing and recovery guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesSep 24, 2026

Addedsearch_ferry_trips
Removedsearch_trips_v2

Changedtrip_details1 field changed

changedInput schema / properties / tripId / description

Previous value: -"The trip identifier for a single sailing leg, as returned in tripsById/bookingSolutions by search_trips_v2. Do not fabricate this value."New value: +"The trip identifier for a single sailing leg, as returned in legs[].options[].id by search_ferry_trips. Do not fabricate this value."

2 tool updatesAug 24, 2026
- Addedsearch_trips_v2
- Addedtrip_details

1 tool updateJul 15, 2026

Changedsearch_trips7 fields changed

removedOutput schema / properties / foundDirectItinerariesForTrip / items / properties / segments / items / properties / marketingCompany / additionalProperties
```
Removed value: -false
```

added

Output schema / properties / foundDirectItinerariesForTrip / items / properties / segments / items / properties / marketingCompany / anyOf

Added value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "iconURL": {
+        "format": "uri",
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "name",
+      "iconURL"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / foundDirectItinerariesForTrip / items / properties / segments / items / properties / marketingCompany / properties
```
Removed value: -{
-  "iconURL": {
-    "format": "uri",
-    "type": "string"
-  },
-  "name": {
-    "type": "string"
-  }
-}
```
removedOutput schema / properties / foundDirectItinerariesForTrip / items / properties / segments / items / properties / marketingCompany / required
```
Removed value: -[
-  "name",
-  "iconURL"
-]
```
removedOutput schema / properties / foundDirectItinerariesForTrip / items / properties / segments / items / properties / marketingCompany / type
```
Removed value: -"object"
```

changed

Output schema / properties / foundDirectItinerariesForTrip / items / properties / segments / items / properties / ownerCompany / description

Previous value: -"This is the original owner of the vessel. This company's code is the one that should be used in the proceeding booking flow."New value: +"This is the original owner of the vessel."

changedOutput schema / properties / foundDirectItinerariesForTrip / items / properties / segments / items / required

Previous value: -[
-  "vehicleIsMandatory",
-  "departurePort",
-  "arrivalPort",
-  "departureDateTime",
-  "arrivalDateTime",
-  "ownerCompany",
-  "marketingCompany",
-  "vessel",
-  "accommodations"
-]New value: +[
+  "vehicleIsMandatory",
+  "departurePort",
+  "arrivalPort",
+  "departureDateTime",
+  "arrivalDateTime",
+  "ownerCompany",
+  "vessel",
+  "marketingCompany",
+  "accommodations"
+]

1 tool updateJun 3, 2026

Changedget_disruptions1 field changed

changedOutput schema / properties / disruptions / items / properties / reason / enum

Previous value: -[
-  "PORT_MODIFICATION",
-  "TIME_MODIFICATION",
-  "VESSEL_CHANGE",
-  "STRIKE",
-  "WEATHER",
-  "COMMUNICATION",
-  "VESSEL_SUSPENSION"
-]New value: +[
+  "PORT_MODIFICATION",
+  "TIME_MODIFICATION",
+  "VESSEL_CHANGE",
+  "STRIKE",
+  "WEATHER",
+  "COMMUNICATION",
+  "TECHNICAL_ISSUE",
+  "TRIP_CANCELLATION"
+]

Related MCP Connectors

Flight MCP
com.flight-mcp
Search and compare flight offers through a cache-aware Streamable HTTP MCP server for AI agents.
Travel & Transportation Search
1
Furgonetka.pl - Logistics & Shipping MCP ServerOAuth
pl.furgonetka.api
Furgonetka MCP Server is an extension for LLMs (such as Claude) that integrates AI assistants with Poland's most popular courier brokerage platform. The server enables models to interact directly with services from various couriers (including InPost, DPD, DHL, UPS, and Poczta Polska) through a single, unified interface. With this integration, your AI stops just "writing about logistics" and starts actually managing it.
E-commerce & Retail Monitoring Travel & Transportation
2
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
Dappier
com.dappier.mcp
The Dappier MCP server connects LLMs and AI agents to real-time, rights-cleared, proprietary data from trusted sources across various domains. It provides specialized knowledge through real-time web search, financial stock market and crypto data access, AI-powered content recommendations from premium publishers, and structured outputs with sub-300ms response times, enabling AI systems to respond to current events and trends.
Search Finance Web Scraping
2

Related MCP Servers

viajante
Travel & Transportation
felipebasurto
A
license
B
quality
A
maintenance
Enables AI assistants to search flights and hotels, compare travel dates, explore destinations, and look up airport codes via a local MCP server, with results including prices and links.
Updated 7 hours ago (2026-10-10 17:29 UTC)
16
455 PyPI
4
MIT
mcp-hsl
Travel & Transportation Location Services
devusvulgaris
A
license
A
quality
B
maintenance
An MCP server exposing Greater Helsinki public transport data from Digitransit, enabling LLM hosts to answer live transit queries, plan journeys, and fetch stop departures via natural language.
Updated 2 months ago (2026-08-14 12:32 UTC)
3
7 npm
MIT
SearchAPI MCP Server
Search Location Services Travel & Transportation
iflow-mcp
A
license
Not graded
quality
D
maintenance
MCP server that provides standardized access to Google Maps, Flights, Hotels, and other search services, enabling AI assistants to perform various searches.
Updated a year ago (2025-11-12 04:18 UTC)
MIT
Agentic Travel Recommendations
Travel & Transportation
Varma904
F
license
Not graded
quality
C
maintenance
MCP server for agentic travel recommendations, exposing tools to retrieve member profiles and personalized travel recommendations with partner-specific rules and policies.
Updated 2 months ago (2026-08-17 17:24 UTC)
-

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?