AFerry

Describe 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 price from this tool — it returns none. Write to the buyer in plain language and keep this tool's field names out of it.

get_route_info

List 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.

search_routes

Search 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 sailings from Marseille to Tunis on 1 September 2026, departing around 9am, for 1 adult and 1 child aged 8 with a standard car and no pets. Market French (fr-fr), prices in EUR, alternative routes included — shall I go ahead?" Work locale out yourself rather than asking the buyer which market they want. It decides the language the sailings come back in, the currency they are priced in, and which country's site the deep link opens. Start from the language the conversation is being held in — held in French, search fr-FR; held in German, de-DE — and where that leaves the country open, settle it on everything else you already have: the regional wording and spelling the buyer uses, the ports and places they have named, the currency or the date format they wrote, anything they have said about where they live or set off from. Only where it is still genuinely open after all of that, pick the market that language's speakers are most likely to be in and go — the confirmation summary is what gives the buyer the chance to move it, so never hold the search up over it. AFerry doesn't sell in every market, and a locale it doesn't sell in is resolved to the nearest one it does, so pass on whatever you settled on rather than second-guessing it. Leave locale off only where the conversation gives no language signal at all, which searches the UK. A time of departure is required as well as a date. The search returns the sailings around the instant it is given, so a time nobody settled can return a different day's sailings than the buyer had in mind. Where the buyer named a time, use theirs. Where they didn't, use 9am and say so in the confirmation summary, so they can move it before anything is searched — never leave the time unmentioned. The same applies to the return leg of a return journey. Ask the buyer whether they want a one-way or a return before searching, rather than assuming a one-way, and say which of the two the confirmation summary is for. A return is searched by setting inboundDate; leave it off for a one-way. For a return, ask the buyer whether the return details are the same as the outbound — coming back to where they set off from, the same party, travelling the same way. If they say the details are the same, set only inboundDate and leave every other inbound field off: the return then travels the outbound's route reversed, with the outbound's own party and vehicle. If they say something differs, ask them for the return's own details and set the inbound fields that differ (inboundOrigin, inboundDestination, inboundPassengers, inboundTravellingBy), leaving the rest off to take the outbound's value. State whatever differs in the confirmation summary — that is the buyer's chance to correct it. The return must depart later than the outbound; a return at or before it comes back failed saying so. Ask how the buyer is travelling — on foot or with a car — and set travellingBy to what they say. It is required, and unlike the date and the party it cannot be defaulted: a car is priced into every sailing returned, so guessing either way prices a crossing the buyer can't book or hides the one they can. Settle it before the confirmation summary. Not every route carries both, and a car asked for on a foot-passenger-only crossing (or the reverse) comes back failed saying so — relay that as the answer rather than retrying it the other way round, unless the buyer says they'd travel differently. On a return, each leg is checked against its own route, so a return can fail on the return leg alone. The party has to be settled by type, not as a head count. Every passenger entry carries its own category, and operators price each one differently, so "4 passengers" or "a family of five" is not something you can turn into a search. Ask for the breakdown: how many adults, how many children and infants and the age of each, and whether a cat or a dog is travelling. Ask it that way round — how many of each type — rather than "how many passengers", which invites the same bare number back. A buyer who has named no party at all can be taken as one adult travelling alone, stated in the confirmation summary like everything else. Cats and dogs are the only animals AFerry carries, one entry per animal, category "Cat" or "Dog", with no age. Tell the buyer anything else isn't supported rather than searching without it. How many pets a crossing carries varies by route, and some carry none; over the limit the search comes back failed naming the limit, which is the answer to relay. Every child and infant needs an age in whole years as at the departure date, and the call is rejected without one. Operators price by the age given, so ask the buyer for each child's age instead of guessing or defaulting it, and settle that before the confirmation summary rather than searching without it. Where a return carries its own party, give each child's age as at the return date — a child whose birthday falls between the legs is a year older coming back. For a later call refining the same search, use judgement instead of always re-confirming: if only one detail changed and the change is unambiguous (e.g. the buyer asked to try a different date), call directly without re-prompting. If the request is vague, ambiguous, or changes multiple details at once, confirm again first. Always share deepLink with the buyer in the same reply as the results, without waiting to be asked for it. It opens the search results page listing every sailing returned here — not a booking page for one specific sailing — so the buyer picks and books their preferred sailing from there. Every sailing returned for a return search is one outbound leg paired with one return leg, priced together. Present the outbound legs and the return legs as two separate lists rather than one merged row, keep each option's pairing intact, and give the option's single price — never a price per leg, and never half of one. Do not ask the buyer to choose a currency or an alternative-route setting up front — the confirmation summary above only states what will be used. Omit both currency and excludeAlternativeRoutes on that first call: - The response's currency field states which currency the prices are in — the searched market's own default unless the call gave an explicit preference. Tell the buyer, don't assume they already know. If they want a different one, call again with an explicit currency. - Alternative-route sailings (a different operator or route than the most direct one) are searched alongside the route asked for. Where the results are a mix, each sailing reports isAlternativeRoute, so say which is which when presenting them. Only if the buyer asks to leave them out, call again with excludeAlternativeRoutes set to true. Each sailing's price is in minor currency units (e.g. pence for GBP, cents for EUR/USD) — divide by 100 for the major-unit amount. The search returns the sailings around the instant it was given, so some of them can depart on the day before or the day after the one asked for. Read each sailing's own departureDateTime rather than assuming it falls on the requested date, and where one doesn't, say which day it sails — a buyer told only the time will take it for the day they asked for. Where every sailing returned is on another day, lead with that rather than burying it. Give every date and time to the buyer in the natural written form of the language the conversation is being held in, never as the ISO string the schema carries. Choose the wording the way a person writing in that language would — "Wednesday 9 September 2026, 08:00" for a British English conversation, "mercredi 9 septembre 2026 à 08h00" for a French one — including the day of the week, which is how buyers think about a crossing. This covers what you say back as well as what you read out: the date and time you are searching for in the confirmation summary, and each sailing's departure and arrival in the results. A completed search can still carry no sailings at all. That means AFerry sells the crossing but had nothing matching what was asked for around that time — not that the crossing does not exist, and not that anything went wrong. Say so plainly, and offer what would most likely turn something up: another date, a wider time of day, travelling on foot rather than by car, or a nearby port. Share deepLink even then, since the results page is where the buyer can move the search themselves. Not every call comes back with sailings, and each of the other three states wants something different said. Whichever it is, keep the workings out of it — no status codes, no URLs, no route codes, no internal system names, nothing from this schema — and never imply the buyer did something wrong when they didn't: - failed carries a reason about what was asked for, and only ever that — AFerry doesn't sell that crossing, the route carries no pets or fewer than the party has, the route doesn't take cars or doesn't take foot passengers, the return departs before the outbound. It is the answer: give it in your own plain words, and offer what the buyer could change, such as another date, travelling on foot, or a nearby port. Nothing needs weighing up first; a search that failed for any other reason never reaches you as failed. - timeout means the search was accepted but hadn't finished in time. Tell the buyer it's taking longer than usual and offer to run it again — a second attempt often lands. Don't take it as the crossing not existing or having no sailings; nothing was learned either way. - unavailable means the search couldn't be run at all. Say only that you can't search AFerry at the moment and that it's nothing to do with what they asked for. Where retryable is true, offer to try again in a moment. Where it is false, stop repeating the same search — point them at https://www.aferry.com/ to search there, and offer to pick it up again later. Never fill the gap any of these leaves with sailings, prices, times or availability from anywhere else, and never present a search as having succeeded when it hasn't. Write to the buyer in plain language and keep this tool's workings out of it: never name a field, value or status from this schema. Say "on a different route than the one you asked for", not "isAlternativeRoute: true"; "here's the AFerry search page", not "deepLink". They are booking a ferry, not reading an API response.

search_ferries