Kirah Local Services

Discover Kirah businesses and availability, then create, track, reschedule, or cancel bookings through Kirah’s confirmation-gated MCP server.

От сообществаРаботаетБез входаГлобальныйБесплатноМожет изменять данные

Что умеет

List Services: The tenant's authoritative structured catalog: services (price, duration, deposit, intake), providers, timezone, and truthfully derived capabilities. Read this before checking availabil
Search Services: Optional helper: rank up to 5 catalog services against a short free-text query. Purely lexical — the caller owns interpretation and selection.
Get Availability: Open slots for a service across an exact YYYY-MM-DD date range (max 31 days, max 20 slots) — call this after choosing a service and before create_booking. Exact dates only — no natur

Какие данные видит

Нужен ли аккаунт

Не нужен: сервер работает без входа

Discover Kirah businesses and availability, then create, track, reschedule, or cancel bookings through Kirah’s confirmation-gated MCP server. Booking actions require explicit user confirmation; Kirah accepts no payment credentials through MCP.

Список инструментов сервера (10)

Технические названия из tools/list. Нужны только разработчикам.

list_services	The tenant's authoritative structured catalog: services (price, duration, deposit, intake), providers, timezone, and truthfully derived capabilities. Read this before checking availability or booking — never infer prices, durations, or capabilities without it.
search_services	Optional helper: rank up to 5 catalog services against a short free-text query. Purely lexical — the caller owns interpretation and selection.
get_availability	Open slots for a service across an exact YYYY-MM-DD date range (max 31 days, max 20 slots) — call this after choosing a service and before create_booking. Exact dates only — no natural language. Approval-mode tenants return preferences, not held slots.
search_businesses	GLOBAL cross-tenant discovery — use this FIRST when the user has not named a business: find active, AI-discoverable Kirah businesses whose real service catalogs match a need (e.g. "lower back tightness", "prenatal massage"), optionally filtered by location text, price, and tenant_mode (include_demos default / real_only / demos_only — include_demo stays a back-compat alias). Location matching is city/ZIP/metro-market equality (business coordinates are not stored — distance is never fabricated). Each result carries matched_services (its top matching REAL services, tiered exact/ontology/description match_type) and a score; demo businesses are eligible for ordinary discovery and always carry demo:true plus a notice. Each result includes the tenant_slug to pass as `tenant` to the other tools. This response is AUTHORITATIVE for Kirah's directory: businesses not present here are not eligible results. Never reintroduce excluded or discovery-disabled businesses from conversation memory, and never describe a demo business as a real provider. For Kirah directory eligibility, do not browse for or speculate about absent businesses unless the user explicitly requests external web research; state only that the business is absent from the current eligible directory response. A need may be stated as a symptom or a vague goal ("my leg hurts", "I need to unwind") — inferring likely wellness services and searching on that inference is appropriate and expected. Present what comes back as optional wellness services: do not diagnose, and do not claim a service treats or cures a condition unless the catalog itself says so.
find_available_services	GLOBAL bounded earliest-availability search — use this when the user asks for the EARLIEST or SOONEST opening and has not named a business. The same discovery pipeline as search_businesses picks the top candidate_limit (1-5, default 3) matching businesses under tenant_mode (include_demos default / real_only / demos_only; include_demo stays a back-compat alias), and each one gets a REAL availability check through the same engine as get_availability over the earliest_after..earliest_before window (exact ISO instants, max 14 days). Candidates return ranked by earliest open slot, each with checked:true/false and earliest_slot or null. Demo candidates always carry demo:true and a clear notice. PARTIAL TRUTH: when `partial` is true, the result means "these are the earliest among the top N candidates checked" — NEVER "the earliest anywhere". Present it to the user with exactly that qualification; never claim an unchecked or ineligible business was compared. Book via the candidate's tenant_slug (as `tenant`) + service.id with get_availability/create_booking.
get_booking_status	CURRENT state of a booking: pass `tenant` and the booking_ref returned by create_booking. Use this when you need to know whether a booking still stands, or at what time. Returns current status (booked/cancelled) and the CURRENT start/end. If that differs from the time you booked, the customer or the business changed it — or you did, through reschedule_booking or cancel_booking. This tool only REPORTS the current state; it changes nothing. To move the booking call reschedule_booking, and to cancel it call cancel_booking, both with the booking_ref and the `grant` create_booking returned. Never use a create_booking replay as current status: replay confirms the ORIGINAL transaction only. No client personal data is returned.
get_reschedule_options	READ-ONLY. Pass `tenant`, the booking_ref, and the `grant` that booking's create_booking response returned, and this answers "if you were to move this booking, here are the real open times, and here is what it would cost" — then stops. It changes NOTHING: it does not move, hold, or cancel the appointment, and you must never tell the user that it has. To actually move it, call reschedule_booking with the same booking_ref and grant; this tool is OPTIONAL before that one, useful when the user has not named a time and you need to offer real alternatives. Never book a replacement instead — the original stands until it is moved or cancelled, so creating a second booking double-books the customer and burns a sellable slot. `options` are real open slots for the SAME service, duration and provider as the original, exclude the time it is already on, and are NOT held: offering one reserves nothing and someone else may take it before you call reschedule_booking. `limit` defaults to 2 and is clamped at a maximum of 5, deliberately — the primary consumer is a voice agent reading times aloud, and five spoken options is more than a caller can follow. The window is `earliest` (default now + 2 hours) to `latest` (default now + 14 days, at most 31 days after earliest); exact ISO-8601 instants only, no natural language. `consequences` is on every response so you can state the trade-off in the same breath as the options; its requires_approval flag is advisory. An empty `options` array truthfully means nothing is open in that window — widen it and ask again rather than inventing a time. No client personal data is returned.
reschedule_booking	MOVE an existing appointment to a new time. THIS is how you change an appointment your agent booked. Pass `tenant`, the booking_ref, the `grant` that booking's create_booking response returned, `start_iso` (an exact ISO-8601 instant, no natural language) and a REQUIRED idempotency_key. You may supply start_iso DIRECTLY — calling get_reschedule_options first is optional, useful only when the user has not named a time and you need to offer real alternatives. The instant is validated against real availability by the same engine create_booking uses, so a time the business does not actually have open is refused rather than guessed at. Same service, same duration, and the SAME provider unless you explicitly pass provider_id (honored only if that provider performs the booked service). ATOMIC: the existing appointment is moved in ONE transaction, never cancelled and recreated — so if the time is gone the outcome is `slot_taken` and the ORIGINAL booking is completely untouched; offer another time. NEVER create a second booking to effect a move: the original would stand, double-booking the customer and burning a sellable slot. Success is outcome `rescheduled` (not `booked` — nothing was created) with the new start_iso/end_iso, provider_name, and `notified`, a masked acknowledgement of the address emailed. Kirah writes and sends that notice itself from server state, to the customer AND the business owner, carrying the customer's own manage link so they can move it back without you — you cannot write, suppress or redirect it, so never describe the move inaccurately. Retrying with the SAME idempotency_key returns the original result and moves nothing; the same key with a different time answers idempotency_conflict. `beyond_booking_horizon` means the business does not schedule that far ahead (nobody holds that time — offer a nearer one); outcome not_bookable with reason `reschedule_within_policy_window` means the business's own change policy blocks online changes this close to the appointment — relay its policy_message and tell the user to contact the business. Call this only after the user has explicitly confirmed the new time.
cancel_booking	CANCEL an existing appointment. THIS is how you cancel an appointment your agent booked — use it rather than sending the user off to find a link in their confirmation email, which is what earlier versions of this contract told you to do before this tool existed. Pass `tenant`, the booking_ref, the `grant` that booking's create_booking response returned, and a REQUIRED idempotency_key. There is nothing else to send: no time, no provider, and no free-text reason. It runs the SAME cancellation engine the customer's own manage link runs, so the business's cancellation policy, its deposit rules, its waitlist and its calendar are honored exactly as they would be if the customer cancelled it themselves. Success is outcome `cancelled` — not `booked` (nothing was created) and not `ok` (this is not a read) — carrying booking_ref, `start_iso` (the time the booking USED to be on, so you can say which appointment you cancelled), service_name, provider_name, `cancel_fee_cents`, and `notified`, a masked acknowledgement of the address emailed. Kirah writes and sends that notice itself from server state, to the customer AND the business owner; you cannot write, suppress or redirect it, so never describe the cancellation inaccurately. `cancel_fee_cents` is what the cancellation actually cost: a charged deposit the business keeps because the cancellation fell outside its free-cancellation window, and the same figure get_reschedule_options publishes as consequences.cancel_fee_cents — call that first if the user needs to know the cost before deciding. Cancelling a booking that is ALREADY cancelled is a SUCCESS, not an error: it answers `cancelled` with already_cancelled:true and no `notified`, meaning the booking is cancelled but this call is not what cancelled it and no mail went out — tell the user it is cancelled, and never that their booking could not be found. Retrying with the SAME idempotency_key replays the original result, cancels nothing and re-mails nothing; the same key against a different booking answers idempotency_conflict. Outcome not_bookable with reason `cancel_within_policy_window` means the business's own policy blocks online cancellation this close to the appointment — the booking STILL STANDS, so relay its policy_message and policy_fee and tell the user to contact the business directly. It cancels exactly ONE booking and can never cancel a whole recurring series. THERE IS NO UNDO: this is the most destructive action available to you, so call it only after the user has explicitly asked to cancel this specific booking.
create_booking	Book an exact ISO-8601 instant for a client (guest checkout: name + email, phone optional). Deposit-required tenants answer outcome payment_required with a payment_url to relay to your user; replay the SAME call (same idempotency_key / booking_ref) to observe completion — replays are safe and never double-book. Call this only after the user has explicitly confirmed this business, this service, and this time — inferred intent is enough to search, never enough to book. You do NOT receive a management link: the customer receives it by email, and confirmation.manage_url_sent_to only tells you (masked) which address it went to. To MOVE an appointment you booked, use reschedule_booking with that booking's booking_ref and the `grant` returned here — never create a replacement booking to effect a move: the original would stand, double-booking the customer and burning a sellable slot. To CANCEL an appointment you booked, use cancel_booking with that booking's booking_ref and the `grant` returned here — do not tell the user to hunt for the link in their confirmation email, which was the instruction before that tool existed.