get_routes_from_country_b2b
ChatGPTGiven a country ISO code, returns available outbound routes from that country, including routeId, origin port code, destination port code, operator and return-route lookup guidance. Use this when port codes are unknown and you need to discover available routes and ports for quoting. For return journeys, do not assume the outbound routeId can be reused in reverse: use returnRouteLookupHint to find the reverse-direction routeId by calling get_routes_from_port with the destination port code from the outbound route, then select the route whose portTo.code matches the original departure port. For international return journeys, you may need to query both countries to obtain both outbound and inbound routes. This is a good starting point when you do not already know the relevant port code. User-facing narration: - Prefer plain language such as "route", "crossing", "direction", or "sailing". - Say "I’m looking up available routes from the departure country" rather than mentioning numeric identifiers. - Avoid mentioning routeId unless debugging, validating payloads, or the user explicitly asks for technical detail. - Treat routeId as an internal implementation field used for quoting, not default customer-facing wording.
get_routes_from_port
ChatGPTGiven a known origin port code, returns available outbound routes from that port, including routeId, origin port code, destination port code, operator and return-route lookup guidance. Use this when you already know the departure port and need the correct route for quoting. If you do not know the port code, call the get_routes_from_country_b2b tool to discover available routes and port codes for the origin country. For return journeys, do not assume the outbound routeId can be reused in reverse: use returnRouteLookupHint to find the reverse-direction routeId by calling get_routes_from_port with the destination port code from the outbound route, then select the route whose portTo.code matches the original departure port. User-facing narration: - Prefer plain language such as "route", "crossing", "direction", or "sailing". - Say "I’m looking up the outbound and return routes" rather than mentioning numeric identifiers. - Avoid mentioning routeId unless debugging, validating payloads, or the user explicitly asks for technical detail. - Treat routeId as an internal implementation field used for quoting, not default customer-facing wording.
quotes_get_quotes_request
ChatGPTRetrieve available ferry quotes for one-way or return journeys. Required inputs: - culture: Locale in the format ll-CC, for example "en-GB". Infer this from the language the customer is using, unless they explicitly request a different locale. - selectedCurrency: 3-letter ISO currency code, for example "GBP". Infer this from the customer's explicit preference first, then from customer location, language/market, and the port location of the journey. - legs: One or more journey legs to quote. Each leg requires: - isReturnLeg: true for the return leg, false for the outbound leg. - routeId: Internal route identifier for that sailing direction; return journeys require a different reverse-direction routeId. - departureDateTime: Target sailing date and time in YYYY-MM-DDTHH:MM:SS format. departureDateTime must be in the future. - vehicles: Vehicle type for the leg. Allowed values are "car", "bicycle", or "" for foot passengers. Case-sensitive. - passengers: Total number of passengers travelling on that leg. Notes: - culture and selectedCurrency are independent and should not be assumed to match. - Quotes may be returned within a time window around the requested departureDateTime, not only at the exact timestamp. - If results are empty, limited, or not suitable, offer to search 1-3 hours earlier or later on the same day. - When the user provides only a date and no time, choose a reasonable departureDateTime as a seed search and explain that nearby sailings may be returned. - For same-day searches where the user does not provide a time, choose the earliest clean seed time that is at least two hours ahead of the user’s current local time. Prefer exactly +2 hours when valid. Only add extra buffer if there is a specific reason, and state that reason. - Use any quoteSearchHint returned in the response to guide follow-up suggestions to the user. - Set returnAlternativeRoutes to false by default. Only set returnAlternativeRoutes to true if the initial direct-route results are empty, limited, or unsuitable, or if the user explicitly asks to see alternatives. - Set isOpenTicket to true only for open-return style journeys when supported. User-facing narration: - Prefer plain language such as "quote", "crossing", "route", "outbound", "return", or "sailing". - Say "I’m getting a quote for the outbound and return sailings" rather than mentioning internal identifiers. - Avoid mentioning routeId unless debugging, validating payloads, or the user explicitly asks for technical detail. - Surface customer-relevant details first: route, date, time, operator, passenger and vehicle mix, fare, ticket conditions, and check-in requirements. - Treat routeId as an internal implementation field used in the request payload, not default customer-facing wording.
