OwnerRez MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OWNERREZ_EMAIL | Yes | Your OwnerRez account email address. | |
| OWNERREZ_TOKEN | Yes | Your OwnerRez Personal Access Token (starts with pt_). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ownerrez_list_propertiesA | List properties. Returns a compact view by default (id, name, active, beds/baths, guests, city, type); set full=true for every field. Use limit to cap results. |
| ownerrez_get_propertyA | Fetch a single property by id, including full detail (owner_id, check-in/out rules, capacity, address). |
| ownerrez_list_bookingsA | Search bookings. Requires property_ids OR since_utc. Compact view by default (id, property, guest, arrival, departure, status); full=true for every field. Use limit to cap. include_charges adds owner_amount/commission (implies full). |
| ownerrez_get_bookingA | Fetch a single booking by id. |
| ownerrez_get_scheduleA | The operational schedule for a date range across all properties (or one): who arrives, who departs, who stays through, and same-day turnovers. One call — no need to pass property ids. |
| ownerrez_list_ownersB | List all property owners (id, name, contact, last_owner_statement_id). |
| ownerrez_get_ownerA | Fetch a single owner by id. |
| ownerrez_list_owner_statementsA | List an owner's real OwnerRez statements (id, period, owner payout, paid/unpaid), newest first. Use the id with ownerrez_get_owner_statement. |
| ownerrez_get_owner_statementA | Return an owner statement. Prefers OwnerRez's official statement (by statement_id, or the latest / period-matching one for an owner_id); if none exists or the official source is unavailable, synthesizes one from booking charges (needs from+to). Set synthesize=true to force the estimate. |
| ownerrez_list_thread_messagesA | Fetch all messages on a single conversation thread. Requires a thread_id (OwnerRez has no global message list). NOTE: messaging is unavailable with a Personal Access Token (requires an OAuth app). |
| ownerrez_get_messageA | Fetch a single message by id. NOTE: messaging is unavailable with a Personal Access Token (requires an OAuth app). |
| ownerrez_send_messageA | Post a message to a guest thread. NOTE: unavailable with a Personal Access Token (requires an OAuth app). WARNING: in production this reaches the real guest. Without confirm=true it only previews and sends nothing. Use the guest's real name, not template codes. |
| ownerrez_get_availabilityA | Show what's booked/blocked for a property in a date range (OwnerRez has no calendar endpoint; availability is derived from bookings). Returns bookings overlapping [from, to]. |
| ownerrez_update_rateA | Set the nightly rate for specific dates on a property (spot rates). Without confirm=true it only previews. amount=null means 'use the seasonal default'. Optionally set min/max nights. |
| ownerrez_search_guestsA | Find guests by name or email (the q parameter). Compact results by default; full=true for every field. |
| ownerrez_get_guestA | Fetch a single guest by id (full contact record). |
| ownerrez_list_paymentsA | List payments (guest → you). Provide booking_id (for one booking) or since_utc (recent activity) — one is required to keep results bounded. |
| ownerrez_list_depositsA | List deposits (payouts grouping). Provide booking_id (for one booking) or since_utc (recent activity) — one is required to keep results bounded. |
| ownerrez_list_refundsA | List refunds. Provide booking_id (for one booking) or since_utc (recent activity) — one is required to keep results bounded. |
| ownerrez_list_inquiriesA | List pre-booking guest inquiries/leads: requested dates, party size, source channel, and the thread_ids used to read/reply via the messaging tools. Compact by default; full=true for every field. |
| ownerrez_get_inquiryA | Fetch a single inquiry by id (full detail, including thread_ids for messaging). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| weekly_turnover_briefing | Arrivals, departures, and same-day turnovers for a date range, flagged for cleaning. |
| monthly_owner_statement | Pull an owner's official statement (falls back to a synthesized estimate). |
| unanswered_inquiries | List recent leads and surface which ones look like they still need a reply. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 21 tools
Each tool targets a distinct resource and action: properties, bookings, guests, owners, statements, payments, deposits, refunds, inquiries, messages, availability, and rates. While some tools have similar list/get patterns, their resource names clearly differentiate them, and potential overlaps like get_schedule vs. get_availability are resolved by scope (all properties vs. one property).
All tools follow a consistent ownerrez_verb_noun pattern using snake_case: list for collections, get for single items, search for guests, send for messages, update for rates. No camelCase or irregular verbs are used, making the naming predictable and easy to navigate.
At 21 tools, the set is slightly heavier than the typical 3-15 well-scoped range but still reasonable for a property management domain covering many resource types. Each tool has a clear purpose, and the count is not excessive enough to feel bloated.
The server provides comprehensive read coverage (properties, bookings, guests, owners, statements, payments, deposits, refunds, inquiries) and a couple of write actions (send_message, update_rate). However, it lacks create, update, or delete operations for core entities like bookings, properties, and guests, which are notable gaps that could require workarounds.