ferryhopper_search_ferry_trips
[ferryhopper] 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.
Input 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. |