get_route_info
ChatGPTDescribe what one ferry crossing carries — its vehicle types, the sizes it offers, its pet limit and what it asks of a party — without pricing anything. Call this when the buyer is asking what a named crossing takes rather than what a journey costs: whether their car, their van or their dog can travel, what counts as a standard car there, how many pets they can bring, or how old a passenger has to be to be priced as an adult. It needs no date, no party and no vehicle — only the crossing. search_routes must be called first, every time. routeId is AFerry's own identifier and search_routes is the only thing that produces one, so a crossing is reached by calling search_routes for it and passing back the routeId it returned. Never build one from port names, never reuse one the buyer typed, and never guess one from a crossing described earlier in the conversation. Give the same locale the search_routes call used, because a routeId is written in the language it was found under and asking under another is answered as a crossing AFerry does not sell. The three tools run in that order for a crossing nobody has checked yet: search_routes for the routeId, this to learn what the crossing carries, then search_ferries once the buyer has confirmed. A crossing already checked in this conversation does not need checking again — go straight to search_ferries for it. Every length and height here is in centimetres, both the crossing's own sizes and the extra sizes. Convert them for the buyer where their own units are clearer — a 470 cm standard car is about 15 feet 5 — and never put a bare number to them. vehicles lists the types the crossing sells, in the order its own selector shows them. Put each one's name to the buyer, with its note where that helps them place their vehicle, and keep code to yourself — it is what a later search_ferries call is made with. Where a type has needsDimensions true the crossing wants a length and a height for it, so ask the buyer for theirs before searching; where it is false it does not. An empty vehicles list is a complete answer, not a fault: paired with carriesFootPassengers it says the crossing carries foot passengers only. Tell the buyer that plainly rather than reading it as a crossing with nothing known about it. vehicleDimensions belongs to the crossing rather than to any one type, and is what settles whether a buyer's own vehicle counts as a standard car: compare their length and height against standardLength and standardHeight, and against the largest lengths and heights offered to see whether the crossing can carry it at all. extraDimensions covers only what a vehicle carries on its roof or back, on top of the vehicle's own size. Either may be absent, which means the crossing quotes none — say so rather than guessing a size. maxPets is how many cats and dogs together this crossing carries on one booking, and 0 means none. It covers this crossing alone, so read a return leg's limit by asking about that crossing. onSale false means the crossing is not open to booking at all — say so rather than searching it. lastSailingDate is the last date it is known to sail, and its absence means AFerry holds no sailings for it, which is not the same as it having stopped selling. The other three states want something different said, and none of them should carry this tool's workings — no status codes, no URLs, no internal names: - failed carries a reason about what was asked for, including a crossing AFerry does not sell. Give it in your own plain words and offer what the buyer could change. - timeout means the lookup was accepted but hadn't finished in time. Offer to try again; nothing was learned about the crossing. - unavailable means it couldn't be run at all. Say only that you can't check AFerry at the moment and that it's nothing to do with what they asked. Where retryable is true, offer to try again in a moment; where it is false, point them at https://www.aferry.com/. Never fill the gap any of these leaves with what you know about the crossing from anywhere else, and never quote a sailing, a time or a pric…
search_ferries
ChatGPTSearch AFerry for one-way or return ferry sailings on any crossing AFerry sells, returning matching sailings plus a deep link to the AFerry search results page where the buyer can pick and book one. Call this whenever a buyer asks to find or book a ferry crossing, wherever in the world it is. Origin and destination are free text and are resolved to a route by AFerry, so there is no port code to look up — pass on whatever the buyer named. If AFerry doesn't sell the crossing they asked for, the result comes back failed saying so, which is the answer to give them; don't rule a crossing out yourself before searching. Check the crossing before searching it for the first time. A crossing carries only so many passengers and pets, and not every one takes a car or a buyer on foot, so before the first search of a route settle what it carries: call search_routes for the crossing to get its routeId, then get_route_info with that routeId. Do this once per route — hold what it told you for the rest of the conversation and reuse it for every later search of that same crossing, and do it again in full the moment the buyer moves to a route you have not checked, including the return leg of a return journey where that is a different crossing. What comes back settles three things before you put the confirmation summary to the buyer: - How they are travelling. A buyer on foot needs carriesFootPassengers true; a buyer with a car needs a vehicle of code "Car" in vehicles. Only a standard car is searchable here whatever else the crossing sells, so a crossing listing any car type is enough for a car. - The party. Where maxPassengers is present, the passengers on a leg cannot exceed it. It is absent where the crossing states no limit. - The pets. The cats and dogs on a leg cannot exceed maxPets, and maxPets 0 means the crossing carries none. Where the crossing cannot take what the buyer asked for, tell them what it does take and what they would need to change — "that crossing takes at most 9 passengers on one booking, so we would need to drop one or split the party" — and settle it with them rather than searching anyway. Searching regardless does not get a better answer: a party over the limit comes back as a fault rather than as a reason the buyer can act on. Apply common sense to what the buyer has given you before calling. Origin and destination should each name a single port or city that a ferry sails between. If either doesn't — a country or a region rather than a port, one place where the journey needs two, several places at once, or nothing recognisable as a place — ask the buyer which ports they mean rather than guessing or passing it straight through. That is a different question from whether AFerry sells the crossing: two plausible port names always go through to the search, and the search itself answers that. A standard car can travel with the buyer, and no dimensions are needed for one. A cat or a dog can travel too. These are not supported yet, so don't call this for them: any pet other than a cat or a dog, and any vehicle other than a standard car — a van, motorhome, minibus, bicycle, motorcycle, trailer or caravan, or freight. Before the first call for a new search, stop and confirm the resolved request details with the buyer in a single summary message, then wait for them to confirm before calling — do not silently assume or default origin or destination. The date may be defaulted (e.g. today) if the buyer didn't specify it, as long as the confirmation summary states what will be used. Cover origin, destination, whether it is one-way or a return, the date and time of departure (and of the return, for a return), the party travelling broken down by type, how they are travelling, the market being searched, the currency that will be used, and that alternative routes will be included. Give the market as its language and country in words followed by the locale in brackets — "French (fr-fr)", "British English (en-gb)", "Swiss German (de-ch)" — so a buyer who was searched for the wrong one can see it and say so. E.g. "Searching one-way sa…
search_routes
ChatGPTList the ferry crossings AFerry sells at a port, without pricing anything. Answers "where can I sail to from here?" and "does AFerry sail between these two places?". Call this when the buyer wants to know where they can go rather than what a journey costs — they have named one place and no destination, they are choosing between destinations, or they want to check AFerry sails a pair of ports before committing to dates and a party. It needs nothing but a port name: no date, no passengers, no vehicle. Use search_ferries instead as soon as the buyer wants sailings, times or prices for a journey they have settled on. Call this before searching a crossing for the first time as well, whatever the buyer asked. search_ferries has to know what a crossing carries before it confirms a search with the buyer, and the routeId this returns is the only way to ask get_route_info: search_routes, then get_route_info, then search_ferries. Once a route has been checked that way, later searches of that same crossing go straight to search_ferries. Give primaryPort alone to get every crossing touching that port, in both directions. Give secondaryPort as well to narrow it to the crossings between the two. The two ports are not an outbound and a return — crossings running the other way round come back either way — so do not use this to check a return journey. Ports are free text and are resolved by AFerry, so pass on whatever the buyer named rather than looking a code up or checking a list first. Apply the same common sense search_ferries does: a country or a region is not a port, so ask the buyer which port they mean rather than passing a whole country through. Each crossing names its origin and destination ports, and their countries where AFerry holds them. Use the countries to settle a port name the buyer may have meant in more than one place — "Portsmouth" in England and in the United States — by putting the matching ports back to them before going further, rather than picking one yourself. The crossings come back most relevant first, so present them in the order given. A crossing rarely names the operator sailing it, so say nothing about who sails one unless seller is present on that crossing. Never show routeId to the buyer; it is there so a later question about the same crossing names the same one. A completed lookup can carry no crossings at all. That means AFerry sells nothing at the ports asked about — which is the answer, not a fault. Say so plainly and offer what would most likely help: a nearby port, or the other end of the journey they have in mind. The other three states want something different said, and none of them should carry this tool's workings — no status codes, no URLs, no internal names: - failed carries a reason about what was asked for. Give it in your own plain words and offer what the buyer could change. - timeout means the lookup was accepted but hadn't finished in time. Offer to try again; nothing was learned about whether the crossings exist. - unavailable means it couldn't be run at all. Say only that you can't check AFerry at the moment and that it's nothing to do with what they asked. Where retryable is true, offer to try again in a moment; where it is false, point them at https://www.aferry.com/. Never fill the gap any of these leaves with crossings from anywhere else, and never price a crossing from this tool — it returns no sailings, times or prices. Write to the buyer in plain language and keep this tool's field names out of it.
