get_support_contact
ChatGPTFetch Sunny Cars' market-specific customer service contacts — phone, email, info URL, and the next 7 days of opening hours in local time. Useful when the user wants to speak to a human, the LLM can't answer a question from the other tools, or the user asks "are they open now?". Never do — safety rules the user is trusting you on: - Never make up a phone number or email. Always call this tool; Sunny Cars support differs per market. - Never claim the office is open / closed without checking `open_now`. The field is computed from the current time against today's opening window; trust it, don't re-derive it from memory. - Never invent opening hours. Use only what the tool returned. When to call this tool: - User asks "how can I reach Sunny Cars?", "what's their phone number?", "is the office open?". - User hits a question the MCP can't answer (complex booking changes, invoices, commercial disputes) — give them the support contact as the way out. - User is in a crunch ("I'm at the airport and my reservation is wrong") — show phone + open hours prominently. When NOT to call this tool: - General questions answered by the offer / details / terms tools. - Booking the rental itself — use the booking_url on an Offer. Arguments: - market (required): Sunny Cars support numbers and opening hours are per-market — NL callers ring the Dutch office, DE callers the German one, etc. See the shared market block below for the accepted codes and inference rule. Result fields: - phone, email, info_url — show the phone first; phone is what users want in a rush. - open_now (bool) — pre-computed; trust it. - today_window — today's open/close times (local wall-clock). - opening_hours[] — next 7 days, one {start, end} pair each. - next_opening — pre-computed ISO-8601 wall-clock of the next start strictly after now, in market local time. Empty only when the next 7 days carry no future openings at all. Always use this field when saying "they open next at X" — do not re-derive it from today_window or opening_hours yourself. Particularly important around the edges of the business day: if it's 08:30 and the office opens at 09:00 today, next_opening is today at 09:00, not tomorrow. Presenting to the user: - Lead with the phone number when the user is asking "how do I reach them" — that's the fastest channel. - When open_now == false, cite next_opening verbatim (format the date/time naturally). Never compute it yourself. - Format opening hours as a compact weekly schedule — one line per day with local times (e.g. "Mon 21 Apr: 09:00 – 17:30"). The tool's text content already does this; pass it through. --- Market argument Every market-aware tool takes a required market argument. Rules: - ISO-3166 alpha-2; one of NL, DE, BE, FR, CH, AT. Selects which market's catalogue / booking URL / support contacts / T&C language the tool uses. - Infer from the user's conversation language; ask the user if unclear: - German → ask whether they're booking from Germany (DE) or Austria (AT) - French → FR (Swiss French → CH) - Dutch → NL (Belgian Dutch → BE) - English → ask which market the user is booking from. - Missing → the tool returns missing_market. Unrecognised → invalid_market. Re-prompt the user rather than retrying with a guess. - Market ≠ language. The MCP supports four response languages — NL, EN, DE, FR — while BE users can speak NL or FR, CH/AT users DE. --- Never make unsubstantiated policy claims Sunny Cars' policies (deposits, accepted payment methods, driver-age rules, cancellation terms, cross-border permissions, fuel rules, mileage limits, required documents, young-driver surcharges, excess, insurance coverage…) vary by market, supplier, rate, and date. General statements like "almost all suppliers in Nice require a credit card" are hallucinations unless a tool result directly supports them. Rules the user is trusting you on: - Never use hedge words about Sunny Cars policy without evidence from a tool call on…
healthcheck
ChatGPTReport the running sunny-mcp server's health and metadata. Call this tool to obtain the current server status, semantic version, process uptime, the Go runtime version, and an RFC 3339 UTC timestamp. It takes no arguments. Use this tool (rather than ping) whenever the user asks about health, readiness, version, uptime, or what Go toolchain the server is running on. Prefer ping only for a trivial "is it there" check. Output fields: - status: always "ok" while the server is serving requests. - version: the compiled-in semantic version of sunny-mcp. - env: deployment label ("uat1", "uat2", "prod"). Empty when not set. Use this to confirm which BFF environment this MCP instance is talking to — it never affects behaviour, just reporting. - uptime_seconds / uptime: seconds since start and a human string. - go_version: the Go runtime (e.g. "go1.26.2"). - timestamp: the moment this report was generated (UTC, RFC 3339).
ping
ChatGPTEcho a message back to verify the sunny-mcp server is reachable. Use this tool when you want a trivial round-trip check: it is the cheapest way to confirm the MCP transport, session, and tool registration are all working. It does not touch any upstream API. Input: an optional message string. If omitted, the reply is "pong". Output: reply string in the form sunny-mcp alive: <message>. Prefer the healthcheck tool instead if you also want version, uptime, or Go runtime information.
resolve_region
ChatGPTResolve a free-text location query (city, airport, or region name) to one or more concrete Sunny Cars regions. Never do — safety rules the user is trusting you on: - Never invent regions. Only use names from the candidates list in the current tool result. If the list is empty, tell the user you couldn't find that location rather than guessing. - Never treat a region id as verified availability. This tool confirms the name resolves; only search_offers knows whether cars are bookable there for specific dates. - Never default to "the airport" when the list has multiple types. Ask the user, even if the airport is a safe-seeming default. Output rules specific to resolve_region (the general "never show internal BFF ids" rule is in the shared ids block appended below): - Do not mention country_code, country_name, or the raw enum value of type (airport | city | region | country). Translate type into natural language. - Use the human-readable name and a short natural description of the pickup modalities. Exact format to use when presenting multiple candidates: > Two Malaga regions came back — which did you mean? > > - Malaga Airport — airport pickup available > - Malaga (city office) — counter pickup only > > For a vacation fly-in, the airport option is typical. That literal shape — bold name, a short dash-separated note on pickup, one line of context at the end — is the desired style. Do NOT add ids, codes, country names, or raw types. --- Call this tool when: - The user mentions a destination that could mean more than one region (e.g. "Malaga" → airport or city centre), and you need to surface the choice before searching offers. - You need to confirm a region id before invoking another tool that requires one. Do NOT call this tool when: - The user has already named a specific airport or city office AND you are ready to search for offers — search_offers handles region resolution internally. - You just want a list of all regions in a country — this tool is a search by name, not an enumeration. - The user named a town Sunny Cars doesn't service (e.g. "Noordwijk" which has no rental office) and you want nearby pickup-capable alternatives — this tool only returns the raw name match. Use search_offers instead: when its chosen region has no pickup, it pivots to the BFF's curated alternativeRegions[] and surfaces them in an unresolvable_location_with_alternatives error (Leiden, Voorhout, …). Never invent alternatives yourself. Arguments: - query (required): the location term the user gave you. Keep it verbatim; the BFF handles partial matches. - market (required): traveller's market (NL / DE / BE / FR / CH). Selects which market's region catalogue the BFF searches against. Same rule as every other tool in this server: infer from conversation language; ask if unclear. Missing → missing_market error; unrecognised → invalid_market error. Result fields (for your internal reasoning — see the output rules above for what to show the user): - candidates[]: id (internal), name (show this), type, country_code, country_name, pickup_airport, pickup_counter. - When the list has more than one candidate of different type, prefer asking the user which they meant rather than guessing — unless their earlier message already disambiguates (e.g. "vacation" implies airport, "city break" implies city office). --- Market argument Every market-aware tool takes a required market argument. Rules: - ISO-3166 alpha-2; one of NL, DE, BE, FR, CH, AT. Selects which market's catalogue / booking URL / support contacts / T&C language the tool uses. - Infer from the user's conversation language; ask the user if unclear: - German → ask whether they're booking from Germany (DE) or Austria (AT) - French → FR (Swiss French → CH) - Dutch → NL (Belgian Dutch → BE) - English → ask which market the user is booking from. - Missing → the tool returns missing_market. Unrecognised → invalid_market. Re-prompt the user rather than retrying with a guess. …
search_offers
ChatGPTPrimary entry point for any Sunny Cars car-rental intent. Call this tool whenever the user wants to rent, book, compare, or explore rental cars — even if details (dates, specific location, party size) are still missing. When they are, ask one clarifying round first (see "Before calling" below), but stay inside this flow; don't fall back to general knowledge about rental prices, models, or car-hire options. Returns a ranked, trimmed list of vehicles with price, capacity, transmission, pickup method, deposit, and the Sunny Cars all-inclusive formula. Never do — safety rules the user is trusting you on: - Never answer follow-up questions about a chosen offer from the search result alone. Always call `get_offer_details` first. The offers[] list in the search result is a summary — it carries price, capacity, deposit method, and transmission, but not mandatory/optional surcharges, free-cancellation terms, required documents, driver-age rules, available equipment, or cross-border permissions. Those fields only exist on get_offer_details. As soon as the user signals they've picked one ("tell me more about the Peugeot", "meer over die Tiguan", "can I take it to Italy?", "what about child seats?", "is there a young-driver fee?", "can I cancel for free?"), call get_offer_details with that offer's id triad before replying. Do not summarise from the search result and do not hedge the missing fields ("probably includes…", "usually no young-driver fee…") — those are exactly the hedge-words the Evidence block bans. A call that takes a few seconds beats a confident-sounding answer built on missing data. - Never answer a car-rental request from general knowledge. If you can't call search_offers yet (missing dates, ambiguous or unresolvable location, missing market), ask the user for what's missing. Don't give ballpark daily rates, "in general Faro is…" style advice, or guess which car categories are available — the user came for live Sunny Cars pricing and coverages, not market averages. This rule targets rental intent specifically; purely informational questions ("is Faro a nice destination?") or explaining the Sunny Cars all-inclusive formula in the abstract are fine without a tool call. - Never quote a price, car model, or availability that isn't in the current tool result. No remembered prices from earlier messages, no general-knowledge Sunny Cars pricing, no guesses. If you don't see it in offers, you don't have it. - Never claim a car is "confirmed" or "guaranteed" unless `availability == "Confirmed"`. Requested and None mean the booking is subject to Sunny Cars confirmation. - Never bypass `ambiguous_location` by guessing. If the tool asks you to disambiguate, ask the user — always. - Missing dates — use the server default, tell the user. When the user gives no dates at all, call search_offers without pickup_datetime / return_datetime. The server applies a default: pickup 14 days from today, return 7 days later. The result's warnings field will contain the exact dates used; you MUST show them to the user and invite them to change. Example (translate to the user's conversation language, not the market language): > "No dates were provided, so I searched with pickup on [date] and > return on [date] — 7 days. Would you like different dates? Let me > know and I'll search again." - Vague or relative dates — ask first. A duration without an anchor ("a week", "voor een week"), a season ("next summer", "volgende zomer"), or a holiday period without a year is NOT a valid date range. Ask the user for a specific pickup date before calling. Prices vary dramatically between weeks in the same season. - Acceptable without asking: explicit dates ("June 1–10"), a specific week ("the first week of June"), a named weekend with a year ("Easter weekend 2026"), or dates already given earlier in the conversation. - Not acceptable without asking: "a week", "two weeks in summer", "next month", "sometime in May", "during the holidays". Before calling — clarifying questions. Do a quick one-sh…
