Nowistay

View saved version →

---
name: nowistay-calendar-revenue
description: Review and safely update Nowistay calendar availability, nightly rates, minimum or maximum stays, stop-sell rules, and arrival or departure restrictions. Use for pricing changes, bulk date-range updates, weekday rules, availability checks, and revenue-management tasks.
---

# Nowistay Calendar and Revenue

Read the current state before changing it, and change only fields the user requested.

## Review

1. Resolve the target properties once with `list_properties`.
2. Call `get_calendar_ari` for each target property and exact date range.
3. Summarize current availability, rates, and stay rules. Keep property currencies separate and preserve local dates.

Do not infer that a date is available from the absence of a booking alone. Use calendar availability as the source of truth.

## Update

1. Translate the request into an exact property, date range, optional weekdays, and only the fields to change.
2. Do not send availability, price, stay rules, or restrictions that the user did not ask to modify.
3. Use `update_calendar_ari_preview` once per property. For weekday updates, use 0=Monday through 6=Sunday and never send an empty `days_of_week` list.
4. Summarize the staged changes by property, dates, weekdays, rate, and rules.
5. If the user asked only for a proposal or preview, stop. If the user explicitly asked to apply the change, continue through the platform confirmation with the matching `update_calendar_ari_confirm` token.

For portfolio-wide updates, collect one approval token per property and confirm each token exactly once. Never rebuild the update payload during confirmation.

## Guardrails

- Do not silently convert currencies or copy one property's absolute rate to properties using another currency.
- Do not close dates, set stop-sell, or change arrival/departure restrictions unless explicitly requested.
- When the request is ambiguous between a percentage change and an absolute rate, ask one focused clarification before staging.
- Report partial failures per property without repeating successful updates.

Referenced files: 1

View saved version →

---
name: nowistay-daily-brief
description: Prepare a concise cross-property operations brief from Nowistay bookings, missions, and conversations. Use for daily briefs, today's arrivals or departures, upcoming guests, urgent work, operational handovers, and questions such as "what needs attention today?".
---

# Nowistay Daily Brief

Build the brief with the fewest complete MCP calls.

## Workflow

1. Resolve property names and IDs once with `list_properties`. For all properties, omit `search`; paginate only when the response says more properties exist.
2. Resolve relative dates in each property's timezone. Use `get_property` only when the timezone is needed and not already available.
3. Fetch bookings in one portfolio-wide request whenever possible. For multi-property or broad date ranges, use `list_bookings` with `response_format=table`, `limit=500`, and `include_details=false`. Follow `resultMetadata.nextOffset` until `hasMore=false`.
4. Fetch missions with `list_missions`. Use compact results for a small focused request; use `response_format=table` and `limit=500` for a portfolio-wide brief.
5. Fetch conversations only when the user explicitly asks about messages or unresolved guest communication. Do not read conversations merely to enrich a general brief.
6. Retrieve full booking, mission, report, or conversation details only for items that need explanation or action.

## Brief format

Present only useful operating information, ordered by urgency:

- urgent incidents or failed missions;
- arrivals and departures with property, guest, time, and readiness risks;
- unassigned, overdue, or blocked missions;
- guest conversations that need a host decision;
- a short next-actions list.

Use property names in the response. Identify a guest only when the user requested guest-level information or when the identity is necessary to act on a specific arrival, departure, or conversation; otherwise identify the stay by property and dates. Never include guest email, phone, postal address, private notes, or message content in a general brief. Keep internal IDs out of the prose unless the user asks for them or they are needed to disambiguate records. If a broad query is paginated, finish every page before claiming the brief is complete.

## Efficiency rules

- Do not call `list_bookings` once per property when omitting `property_ids` returns the whole eligible portfolio.
- Do not use full-detail list responses for broad requests.
- Do not call `get_booking` or `get_mission` for every row.
- Do not describe complete server results as truncated merely because the UI displays a shortened preview; trust `resultMetadata.hasMore` and pagination fields.

Referenced files: 1

View saved version →

---
name: nowistay-direct-bookings
description: Create or update direct Nowistay bookings with availability checks, minimum required guest details, pricing, status, operational notes, and optional payment links. Use for manual reservations, direct booking quotes, payment-request bookings, date changes, guest-count changes, and booking corrections.
---

# Nowistay Direct Bookings

Use the booking workflow that matches the user's intent and avoid duplicate lookups.

## Create a booking

1. Resolve the property once with `list_properties`.
2. Check the exact stay dates with `get_calendar_ari` before staging the booking.
3. Reuse details the user already supplied. Do not search the guest base by default. Use `list_guests` only when the user explicitly asks to reuse an existing guest record, and search with information the user already provided.
4. Collect only missing required values: property, arrival, departure, and guest email. Explain that email is required to create and service a direct booking. Ask for optional phone, pricing, guest count, or notes only when the user wants or needs them for this booking.
5. Call `create_booking_preview` with the complete intended booking.
6. Show a compact summary: property, dates, guest, occupancy, price, currency, status, and whether payment will be requested.
7. If the user asked only to prepare the booking, stop. If the user explicitly asked to create it, continue through platform confirmation with `create_booking_confirm` and only the approval token.

When `request_payment=true`, provide a positive amount. Explain that the booking is created as pending, does not hold inventory while unpaid, and auto-confirms after successful payment. Do not promise that a payment link was sent until the confirm result says so.

Never request or accept payment-card data, bank credentials, government identifiers, medical or biometric data, account passwords, access tokens, or unrelated personal information. Keep free-text notes short and strictly operational.

## Update a booking

1. Find the booking with `list_bookings` and read it with `get_booking`.
2. Update only direct bookings created in Nowistay. If the booking came from an OTA, explain that it cannot be edited through this workflow.
3. Check calendar availability before changing dates.
4. If a payment request already exists, do not attempt to change dates or pricing.
5. Stage with `update_booking_preview`, summarize the exact differences, then use `update_booking_confirm` only after the requested confirmation.

Do not retrieve guest contact details or private booking notes unless the user explicitly asks for that information and it is necessary for the requested booking operation.

Never reconstruct a confirm payload. Confirm tools receive only the one-time approval token returned by their matching preview.

Referenced files: 1

View saved version →

---
name: nowistay-guest-messaging
description: Find guest conversations, read recent messages, summarize context, draft replies, and send messages through Nowistay. Use for "show the last messages", "reply to this guest", booking-based conversation lookup, follow-up replies, and multilingual guest communication.
---

# Nowistay Guest Messaging

Keep the conversation natural and hide implementation details from the host.

## Find and read

1. Resolve a guest or booking with `list_guests`, `list_bookings`, or `get_booking` using information already supplied by the user. Prefer a booking reference, property plus stay dates, or name. Do not ask for email or phone merely to disambiguate when operational context can identify the stay.
2. Use `list_threads` with `booking_id` when a booking is known; otherwise narrow by property.
3. Use `get_thread_messages` once with the exact requested message count. Preserve chronology when presenting the exchange.
4. For a follow-up such as "tell them...", reuse the guest and conversation already established in the current task unless it became ambiguous.

Say "I did not find a conversation" when none exists. Do not mention missing thread IDs, channel IDs, database records, or other private implementation details. Do not retrieve or expose a guest's email, phone, postal address, private notes, or unrelated booking data unless the host explicitly asks for the specific information and it is needed for the requested operation.

## Draft and send

1. Base the reply on the actual conversation, booking, and property context. Do not invent policies, promises, prices, or availability.
2. Match the guest's language and the host's requested tone. Keep the reply ready to send, without technical commentary.
3. Use `send_guest_message_preview` with either `thread_id` or `booking_id`, never both. If no conversation exists but a booking is known, use `booking_id`; Nowistay can prepare the appropriate conversation through its existing flow.
4. Show the recipient in conversational terms and the exact message.
5. If the user asked only for a draft, stop before the preview or after staging as appropriate. If the user explicitly asked to send, continue through platform confirmation with `send_guest_message_confirm` and only the approval token.

Do not recommend switching to personal email or phone merely because no conversation was found. First use the booking-based Nowistay send flow when available.

Never copy sensitive or guest-specific message content into a welcome guide, property knowledge base, mission, or booking note unless the user explicitly requests that exact transfer and the content is appropriate for the destination.

Referenced files: 1

View saved version →

---
name: nowistay-guest-records
description: Review and maintain privacy-minimized Nowistay guest records. Use when a host asks to find a returning guest, review a guest's stay history, or add a guest to the customer base. Do not use merely because another booking or messaging workflow mentions a guest.
---

# Nowistay Guest Records

Use the minimum personal data needed for the host's explicit request.

## Find and review

1. Use `list_guests` with a known name, a contact value already supplied by the user, or a property filter. Do not ask for email or phone merely to search.
2. Present the privacy-minimized list result. Do not imply that contact details are missing; they are intentionally omitted by default.
3. Use `get_guest` with `include_contact_details=false` for booking totals and recent stays.
4. Set `include_contact_details=true` only when the user explicitly asks for that guest's email or phone for a legitimate rental operation.

Never expose postal addresses, private notes, owner identifiers, or implementation fields. Keep internal guest IDs out of conversational responses unless needed to disambiguate records.

## Add a guest

1. Search by the supplied name first. If an existing record may be the same person, ask the user to disambiguate instead of creating a likely duplicate.
2. Collect only the fields the user wants to store. A name alone is sufficient; email, phone, and language are optional.
3. Never request payment-card or bank data, government identifiers, medical or biometric data, postal addresses, account passwords, access tokens, private notes, or unrelated personal information.
4. Call `create_guest_preview`. If it returns `duplicate=true`, use the existing privacy-minimized guest record and do not create another one.
5. Summarize exactly which fields will be stored. If the user asked only for a proposal, stop at the preview. If the user explicitly asked to add the guest, continue through platform confirmation with `create_guest_confirm` and only the approval token.

There is no guest update or delete tool in this workflow. Do not simulate those actions with booking tools.

Referenced files: 1

View saved version →

---
name: nowistay-portfolio-reporting
description: Build privacy-minimized Nowistay financial and operational reports across many properties. Use for CSV or spreadsheet exports, revenue and fee totals, OTA commissions, cleaning costs, team-member billing, workload reports, owner statements, and booking-to-mission reconciliation.
---

# Nowistay Portfolio Reporting

Favor complete table-shaped extraction over repeated detailed calls.

## Collect data

1. Confirm the requested date range, portfolio scope, grouping dimensions, and output format. Infer obvious values from the prompt instead of asking unnecessary questions.
2. Resolve properties once with `list_properties`. Omit `property_ids` from later list calls when the user wants every eligible property.
3. Call `list_bookings` with `response_format=table`, `include_details=false`, `limit=500`, and `offset=0`.
4. Append each page's `rows` under the returned `columns`. Continue with `resultMetadata.nextOffset` while `resultMetadata.hasMore=true`.
5. Call `list_missions` in the same table mode only when the report needs cleaning, operations, assignments, workload, or team-member data.
6. Join booking and mission rows with `bookingId` when combining finances and operations. Use property IDs only as a secondary key.

Never restart the extraction property by property unless the user explicitly requests separate queries or the server requires it. Never use `get_booking`, `get_mission`, or `include_details=true` for a bulk export.

## Minimize personal data

- Select and retain only the source columns needed for the requested report.
- Exclude guest names, contact details, reservation references, message content, private notes, and mission descriptions from financial, owner, billing, and workload reports unless the user explicitly requests a specific field and it is necessary for that report.
- Do not call tools with contact-detail or private-note include flags for aggregate reporting.
- Team-member names may be included when the user requests assignment, workload, or billing by team member. Do not include their contact details.

## Calculate and verify

- Keep currencies separate. Never sum EUR and USD into one total.
- Keep cancelled or unavailable bookings separate from active revenue unless the user defines another rule.
- Preserve source columns in the detailed sheet and add calculated summary sheets or tables.
- Support grouping by property, team member, mission type, booking channel, status, month, or currency.
- Reconcile row counts against pagination metadata before reporting completion.
- State filters, exclusions, currency handling, and any missing source values in the result.

## Deliver

For a requested CSV or spreadsheet, create the file from the complete concatenated rows. Include a readable summary plus a privacy-minimized detail sheet containing only the columns needed to audit the totals. If the user only asks a question, return the totals directly without creating a file.

Do not claim data is truncated when `hasMore=false` and all pages were collected. A shortened tool card is a display behavior, not evidence that the structured result is incomplete.

Referenced files: 1

View saved version →

---
name: nowistay-property-knowledge
description: Maintain the private Nowistay AI co-host knowledge base for each property. Use to list, search, add, correct, or copy reusable property questions and answers such as policies, equipment details, access guidance, and local recommendations.
---

# Nowistay Property Knowledge

Manage private Q&A knowledge separately from the public welcome guide.

Store reusable property facts, not guest records. Do not add guest names, contact details, booking references, message transcripts, private notes, payment data, government identifiers, medical or biometric data, account credentials, or other guest-specific information to the knowledge base.

## Read and find

1. Resolve source and target properties once with `list_properties`.
2. Use `list_property_knowledge_questions` with `limit=100`; paginate only when needed. Use `search` to avoid loading the full knowledge base for a focused question.
3. Use `get_property_knowledge_question` only when one exact record needs verification before an update.
4. Present questions and answers conversationally. Keep internal IDs out of the response unless needed for disambiguation.

## Add or update

1. Check for an existing equivalent question before creating a new one.
2. Use `create_property_knowledge_question_preview` for new Q&A and `update_property_knowledge_question_preview` for corrections.
3. Preserve `need_host` unless the user explicitly changes whether future answers require host intervention.
4. Summarize the exact question, answer, property, and host-review setting.

## Copy between properties

1. List the source Q&As first and resolve every target property.
2. Use `copy_property_knowledge_questions_preview` with selected `question_ids`, or omit them to copy all source Q&As.
3. Explain that copying is a safe merge: matching normalized questions are skipped and target knowledge is never deleted or replaced.
4. Use one multi-target copy rather than repeating one copy per property.

If the user asked only for a proposal, stop at the preview. If the user explicitly requested the write, continue through platform confirmation with the matching confirm tool and only the approval token. Do not expose vector-store or database implementation details.

Referenced files: 1

View saved version →

---
name: nowistay-team-operations
description: Plan and manage Nowistay cleaning, maintenance, urgency, and custom missions. Use for mission lists, team workloads, assignments, scheduling, completion status, mission reports, cleaning plans, and operational follow-up across one or many properties.
---

# Nowistay Team Operations

Use summaries for planning and retrieve full details only for the missions that need action.

## Review operations

1. Resolve properties once with `list_properties` when names are used.
2. Use `list_missions` with the smallest useful filters: property, booking, status, type, team member, or start date.
3. For portfolio-wide exports or workload analysis, use `response_format=table`, `include_details=false`, `limit=500`, and follow `resultMetadata.nextOffset` until `hasMore=false`.
4. Use `get_mission` for one selected mission and `get_mission_report` only when completion comments, checklist results, or photos are needed.

Do not retrieve every mission report for a list. Do not treat a shortened UI tool card as response truncation when pagination says the result is complete.

## Create or update

1. For creation, provide `mission_type` and either a property or booking. Resolve the property from the booking when possible.
2. Use an ISO 8601 `scheduled_at` with timezone. Do not guess a team member ID; if it cannot be resolved reliably from current data, ask the user or leave the mission unassigned.
3. Stage creation with `create_mission_preview` or changes with `update_mission_preview`.
4. Summarize property, booking context when needed, type, schedule, assignment, status, and notification behavior. Include a guest name only when the user requested it or the identity is necessary for the mission.
5. If the user explicitly asked to apply the action, continue through platform confirmation using the matching confirm tool and only its approval token. Otherwise stop at the preview.

Use `silent_update=true` only when the user explicitly wants to avoid normal team notifications. Report partial failures without repeating successful actions.

Keep mission titles, descriptions, and notes strictly operational. Do not add guest contact details, medical or biometric data, payment information, government identifiers, account credentials, or unrelated personal information.

Referenced files: 1

View saved version →

---
name: nowistay-welcome-guide
description: Create and edit structured Nowistay welcome guides while preserving headings, lists, images, videos, tables, separators, translations, and EditorJS formatting. Use for page creation, page updates, translations, reordering, image uploads, and guide-wide locale or intro changes.
---

# Nowistay Welcome Guide

Treat every page as structured content unless the full page proves it is paragraph-only.

Welcome guides contain reusable property information. Do not add guest-specific personal data, booking references, private messages, payment data, government identifiers, medical or biometric data, or account credentials.

## Find the page

1. Resolve the property once with `list_properties`.
2. Call `list_welcome_book_pages` once to get the page index, IDs, order, icons, and short previews.
3. Never edit from the list result. Its text is intentionally shortened and is not editable source.
4. Before every page update, call `get_welcome_book_page` for the target page and use its full `contents` and `editingGuidance`.

## Update a page safely

1. Copy the complete existing EditorJS document for every affected locale.
2. Change only the requested visible text or explicitly requested blocks.
3. Preserve block order, types, IDs, `data`, `tunes`, nested list item objects, inline HTML, media, tables, embeds, separators, and unknown fields.
4. Never flatten a structured page into plain text. Never stringify list item objects. Never paste escaped object representations into visible text.
5. Stage the full preserved structure with `update_welcome_book_page_preview`.

## Create a page

1. Use the `pageCreationGuidance.contentStructure.blockConstructionTemplates` returned by `list_welcome_book_pages`.
2. Build exact EditorJS content with `time`, `version`, and ordered `blocks` for each locale.
3. Choose `position=start`, `position=end`, or `position=after_page` with the correct reference page from the index.
4. Stage with `create_welcome_book_page_preview`.

## Add images

1. Call `upload_welcome_book_image` with the required property ID and either a direct public HTTPS `image_url` or exact-file `image_base64`.
2. Prefer the URL when both are available. Never invent, shorten, or repair base64.
3. Insert the returned `editorJsImageBlock` exactly into `content.blocks`. Never insert the URL or base64 directly as page text.

## Apply changes

Summarize the exact page, locales, placement, and changed blocks. If the user asked only for a preview, stop. If the user explicitly requested the change, continue through platform confirmation with the matching confirm tool and only the approval token. Do not reconstruct page content during confirmation.

Referenced files: 1