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 75 days
Last Tested: 2026-10-31 06:02
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored 2026-10-27 11:45 across 6 tools

Disambiguation4/5

The tools mostly target distinct resources: ports, direct connections, disruptions, trip search, and trip details. The only real overlap is the deprecated search_trips, which duplicates search_ferry_trips, though its description clearly steers agents away from it.

Naming Consistency4/5

Most tools follow a get_/search_ verb_noun pattern in snake_case, which is predictable. trip_details is a noun phrase without a verb and get_direct_connections_for_ports is unusually long, but overall the convention is readable and consistent.

Tool Count5/5

Six tools is a well-scoped surface for a ferry search server: one for ports, one for route discovery, one for disruption lookup, two for trip search (one deprecated but still useful for compatibility), and one for detailed sailing and vessel info.

Completeness5/5

The surface covers the core ferry travel workflow: finding ports, discovering direct routes, searching one-way, round-trip, and multi-leg itineraries, checking disruptions, and inspecting detailed trip and vessel amenities. No obvious operational gaps remain for the stated domain.

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.

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

Output Schema

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

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 openWorldHint=false, so the safety profile is covered. The description adds useful scope by stating results are limited to direct routes with no layovers or transfers, but it does not add other behavioral details such as auth needs, rate limits, or result shape.

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 efficient sentence with the core scope front-loaded. Every phrase contributes to clarifying direct routes, destination ports, and the no-transfer constraint.

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 simple read-only lookup with one fully described parameter, rich annotations, and an output schema, the description is largely complete. It clearly states the direct-route constraint, though it could clarify whether multiple matching origin ports are considered.

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%, and the single portLocation parameter is already documented as a location name or search term. The description reinforces that it is the origin port but adds no additional syntax, format, or matching behavior beyond the schema.

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 gives a specific verb+resource: finding direct ferry routes and reachable destination ports from an origin port, explicitly excluding layovers and transfers. It is clear and specific, but it does not name or directly contrast with sibling tools such as search_ferry_trips or 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 Guidelines3/5

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

Usage is implied by the phrase 'without layovers or transfers,' which signals this tool is for direct connections only. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives for trips involving transfers or disruptions.

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.

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

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

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description still adds value by defining what counts as a 'disruption' (delays, weather alerts, strikes), which bounds the result set. It doesn't say what happens when no disruptions exist or how far in the past/future dates are accepted.

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?

A single sentence with no filler; the resource and its scope appear before the filtering qualifier, so it is properly front-loaded.

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?

With an output schema present, return shape need not be described, and annotations carry the read-only/open-world profile. For a two-parameter filtered lookup, the description plus schema leaves no operational gap an agent would trip on.

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 fully documented in-schema (ISO alpha-2 country code, YYYY-MM-DD date). The description only restates that both filters exist, adding no semantics such as whether country refers to the port's country or the operator's.

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?

Specific verb ('Find') plus a precise resource ('ferry travel disruptions') with the scope enumerated (delays, weather alerts, strikes). None of the siblings (get_ports, search_ferry_trips, trip_details, connections) overlaps with disruption lookup, so an agent can route here unambiguously.

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 phrase 'for a given date and country' implies the lookup context but the description never states when to call this versus a trip search, nor any prerequisite (e.g. check disruptions before booking/after a delay notice). Usage is inferable but not stated.

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

get_portsGet PortsC

Read-only

Inspect

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

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`ports`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

readOnlyHint and openWorldHint already establish the safety profile, and an output schema exists to describe the return shape. The description adds only a taxonomy of result fields, which the output schema covers, and it omits the meaningful behavior: this is an unfiltered full-catalog fetch with no input criteria.

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 short sentence, front-loaded with the verb and resource. It drifts into a comma-separated synonym dump ('ferry ports, harbors, maritime terminals'), which is slightly wasteful but not confusing.

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?

With no params, an output schema, and read-only annotations, the definition is close to sufficient. The remaining gap is scope disclosure: an agent cannot tell from the text whether this is a filtered search or a full listing, which affects how it plans a port-ID lookup.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. What is missing is only the implication that the call returns everything rather than a search result.

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

Purpose3/5

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

The verb is 'Find' and the resource is enumerated as ferry ports, harbors, maritime terminals, IDs, codes and locations, so the domain is clear. But it reads as a keyword list rather than a statement of what the call actually returns (an unfiltered port catalog), and it offers no differentiation from siblings like get_direct_connections_for_ports.

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?

There is no guidance on when to call this versus search_trips, search_ferry_trips, or get_direct_connections_for_ports, and no statement that it takes no arguments and can be used as a reference lookup to resolve port IDs before other calls. The agent must infer all of this.

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.

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

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.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, yet the description still adds real behavioral context: availability flags are reported per segment, options are returned per leg and never cross-filtered, and connection feasibility is NOT validated server-side. That last point is a genuine gotcha disclosure an agent could not infer from the schema. No return format or pagination detail is given, but an output schema exists.

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-loaded with the core definition, then a compact bullet list for the three query shapes, then constraints, then the caveat about connection validity — a sensible ordering. Slightly redundant: the round-trip reversal example is repeated in the array schema description, costing a little space.

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?

For a single-parameter, read-only search with an output schema present, the description covers input shape, leg-chaining rules, output structure at a high level, and the one non-obvious limitation (connections not pre-validated). 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%, so the baseline is 3, but the description adds meaning the schema does not fully carry: location values are human-readable names or search terms rather than port codes, and consecutive legs must leave a real connection buffer. Those are semantic constraints on how to populate the single `legs` parameter, not restatements.

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?

Opens with a specific verb+resource and a precise scope: 'Search ferry trips as an ordered chain of 1 to 5 legs'. The leg-chain framing (round trip = reversed leg 2, island-hopping = up to 5 legs) distinguishes it from a flat search, though it never names sibling search_trips or get_direct_connections_for_ports explicitly, so the differentiation is inferential.

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?

It lays out exactly which shapes of query this tool handles (one-way, round trip, multi-leg chain) and explicitly rules out an alternative: 'no need to call get_ports first'. It also states the hard preconditions — legs must chain end-to-start and be in chronological order — so the agent knows when a query is invalid before calling.

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.

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

Name	Required	Description
`foundDirectItinerariesForTrip`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-lookup behavior are covered without description help. The description usefully adds the deprecation lifecycle status, but says nothing about result limits, pagination, or ordering, and nothing beyond the schema's implicit one-way scope.

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 with no filler, and the deprecation plus alternative lead the text so an agent sees the routing signal first. Every clause earns its place.

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 and annotations covering the read-only/open-world profile, the description need not explain return values, and the deprecation context is the key addition. It stops just short of noting result volume or whether the search is exhaustive, a minor gap for an open-world search tool.

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 all three parameters (departureLocation, arrivalLocation, date) are already fully documented with format examples and the 'not a port code' constraint. The description adds only the 'one-way' framing and does not extend parameter meaning beyond the schema; 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?

The description uses a specific verb and resource ('Get a list of available one-way ferry trips between two ports on a specific date') and explicitly contrasts itself with the sibling search_ferry_trips (which adds round-trip, multi-leg, and per-segment availability). An agent can distinguish the two without reading either schema.

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 opening sentence states the tool is deprecated and names the preferred alternative along with exactly what the alternative offers that this one does not, giving an explicit routing decision. When-not guidance and the alternative are both present and front-loaded.

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.

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

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.6/5.0

Behavior5/5

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

With readOnlyHint/openWorldHint already covering safety, the description adds substantial behavior beyond annotations: it throws on malformed or no-longer-bookable tripIds, and it warns that vessel.hasDetails=false with null fields means data is unavailable rather than absent amenities. That null-semantics warning is exactly the kind of context annotations cannot convey.

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-loaded with purpose, scope, and return shape before the long question list. The enumerable question phrasing (wifi, pets, cabins, IMO/MMSI, etc.) is verbose but earns its place by mapping to likely user queries; it is on the edge of bloat but not wasted.

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?

An output schema exists, yet the description still outlines the return surface (times, ports, company, vessel specs, amenities, photos, accommodation tiers). Combined with the error and null-handling notes, an agent has everything needed to call and interpret this tool.

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%, so the baseline is 3, but the description adds real meaning by pinning the value to legs[].options[].id from search_ferry_trips and warning not to fabricate it. That reinforces provenance beyond the schema's own wording.

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?

Starts with a specific verb+resource ('Get full details for a single sailing leg') and explicitly scopes it to an id drawn from search_ferry_trips. An agent can distinguish this detail-lookup tool from the discovery sibling without opening either schema.

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?

Gives concrete usage contexts (vessel amenity/accessibility/capacity questions) and a recovery path: if tripId is stale or malformed, re-run search_ferry_trips for a fresh id. Lacks explicit when-not-to-use vs. the other siblings, but the search-vs-detail split is clear.

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.

6 tool updatesOct 27, 2026

Changedget_direct_connections_for_ports3 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changedget_disruptions3 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changedget_ports1 field changed

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changedsearch_ferry_trips7 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / legs / items / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / legs / items / properties / departureDate / pattern

Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

added

Output schema / properties / legs / items / properties / options / items / properties / segments / items / properties / arrivalDateTime / pattern

Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"

added

Output schema / properties / legs / items / properties / options / items / properties / segments / items / properties / departureDateTime / pattern

Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"

Changedsearch_trips5 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

added

Output schema / properties / foundDirectItinerariesForTrip / items / properties / segments / items / properties / arrivalDateTime / pattern

Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"

added

Output schema / properties / foundDirectItinerariesForTrip / items / properties / segments / items / properties / departureDateTime / pattern

Added value: +"^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$"

Changedtrip_details3 fields changed

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

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
https://flight-mcp.com/mcp
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
https://api.furgonetka.pl/mcp
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
https://claw-link.dev/api/mcp
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
https://mcp.dappier.com/mcp

Related MCP Servers

viajante
Travel & Transportation
felipebasurto
A
license
B
quality
B
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 4 days ago (2026-10-27 15:05 UTC)
22
444 PyPI
40
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 3 months ago (2026-08-14 12:32 UTC)
3
8 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
A
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)
ISC

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?