OwnerRez MCP Server
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@OwnerRez MCP Server Who's checking in this weekend?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
OwnerRez MCP Server
A Model Context Protocol server that connects OwnerRez to Claude (Cowork / Claude Desktop) and any other MCP client. Ask about bookings, see who's checked in, message guests, record expenses, and manage webhooks — in natural language. Built with Python + FastMCP.
⚠️ Community project, not affiliated with OwnerRez.
Quickstart
New here? QUICKSTART.md gets you to a working connection in two commands.
The fastest path — no clone, no venv — using uv:
This same server works in any MCP client — Claude, Cursor, Windsurf, VS Code, Cline, Zed, and more. Add the standard block below to your client's MCP config (QUICKSTART.md lists each client's config file location and the few that use a different key):
{
"mcpServers": {
"ownerrez": {
"command": "uvx",
// Before a PyPI release, run straight from GitHub:
"args": ["--from", "git+https://github.com/buildwithmanag/ownerrez-mcp", "ownerrez-mcp"],
// After `pip`/PyPI publish this becomes simply: "args": ["ownerrez-mcp"],
"env": {
"OWNERREZ_USERNAME": "you@example.com",
"OWNERREZ_TOKEN": "your_personal_access_token"
}
}
}
}Restart your client and the OwnerRez tools appear. That's it.
Prefer to run from source? See Install from source.
Related MCP server: realtycalendar-mcp
What it can do
Tools
Tool | Purpose | Endpoint |
| Bookings changed since a time; filter by status / property / arrival window |
|
| Full detail for one booking |
|
| Who's checked in right now, per property | derived ✅ |
| Reference lookups |
|
| Financial reads |
|
| Messages in a thread (by |
|
| Reply to a guest (write) |
|
| List webhooks |
|
| Manage webhooks (write) |
|
| Inbound-message inbox, fed by the webhook receiver | local store ✅ |
Resources: ownerrez://properties, ownerrez://owners
Prompts: draft_checkin_message, draft_guest_reply
Verified against the live API — two OwnerRez limitations to know: there is no public expense-creation endpoint, and no endpoint that lists message threads. Inbound guest messages arrive via webhooks — subscribe to the
messagecategory withcreate_webhook_subscription, then use the event'sthreadIdwithlist_messages/send_message. Bookings and guests are bounded by a "since" time, not by stay dates.
Example prompts
"Who's checking in this weekend?"
"Who's currently staying at the Beach House?"
"Draft a check-in message for the guest arriving tomorrow at Cabin 3."
"Show me all payments on booking 84213."
"List the messages on thread 55123 and draft a reply."
Authentication
Pick whichever fits — the server prefers OAuth if both are set.
Personal Access Token (simplest for one account). OwnerRez → Settings → API
→ Personal Access Tokens. Set OWNERREZ_USERNAME + OWNERREZ_TOKEN.
OAuth (for multi-account / distribution). Create an OAuth app in OwnerRez,
set OWNERREZ_CLIENT_ID + OWNERREZ_CLIENT_SECRET, then run the built-in helper:
ownerrez-mcp authIt opens the authorize page, captures the redirect locally, and prints the
OWNERREZ_ACCESS_TOKEN to save.
Real inbound messages (webhook receiver)
OwnerRez has no endpoint to poll for open conversations — inbound guest messages
are delivered by webhooks. This package ships a small receiver that captures
them into a local store so list_open_messages becomes a real inbox.
# 1. Install the optional extra and run the receiver
pip install "ownerrez-mcp[webhook]"
ownerrez-mcp webhook # listens on 0.0.0.0:8000
# 2. Expose it on a public HTTPS URL (any tunnel works), e.g.
# ngrok http 8000 -> https://<something>.ngrok.appThen register that URL (via the MCP tool or any client):
create_webhook_subscription(url="https://<something>.ngrok.app/", category="message")Now incoming guest messages land in the store, and in your agent you can ask
"show my open messages" (list_open_messages), reply with send_message using
the message's thread_id, and mark_message_handled to clear it.
Config: OWNERREZ_STORE (db path, default ~/.ownerrez-mcp/messages.db),
OWNERREZ_WEBHOOK_HOST / OWNERREZ_WEBHOOK_PORT, and an optional
OWNERREZ_WEBHOOK_SECRET (sent as X-Webhook-Secret or ?secret=) to reject
unauthenticated posts. Always run behind HTTPS.
Safety: read-only mode
Set OWNERREZ_READ_ONLY=1 to hard-block every write tool (messaging, expenses,
webhook changes). Great for letting an assistant explore your data without any
risk of it messaging a guest or mutating records.
Verify against the live API
ownerrez-mcp probe # read-only checks (safe)
ownerrez-mcp probe --probe-writes # also tests the expense POST endpoint with
# an invalid body (creates nothing)The output tells you exactly which endpoints your token can reach and whether
expense creation is WRITABLE or NOT SUPPORTED.
Install from source
git clone https://github.com/buildwithmanag/ownerrez-mcp
cd ownerrez-mcp
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
cp .env.example .env # fill in your credentials
ownerrez-mcp probe # sanity-check connectivityPoint your MCP client at the venv's executable:
{
"mcpServers": {
"ownerrez": {
"command": "/path/to/ownerrez-mcp/.venv/bin/ownerrez-mcp",
"env": { "OWNERREZ_ACCESS_TOKEN": "..." }
}
}
}Configuration reference
Variable | Default | Purpose |
| — | OAuth access token (preferred) |
| — | Personal Access Token (Basic auth) |
|
| Block all write tools when truthy |
|
| Retries on 429/5xx |
|
| Request timeout (seconds) |
|
| API base URL |
| — | OAuth app creds (for |
Development
ruff check . # lint
pytest # testsSee CONTRIBUTING.md. Every tool returns a structured
{"ok": ...} envelope, follows OwnerRez v2 pagination, redacts secrets from
errors, and retries transient failures.
License
MIT — see LICENSE. API reference: https://api.ownerrez.com/help/v2
Available Tools
18 toolscreate_webhook_subscriptionA
Subscribe to OwnerRez events by registering an HTTPS callback URL.
Inputs: url (required), category (required). Returns: object
delete_webhook_subscriptionA
Remove a webhook subscription by its ID. Blocked in read-only mode.
Inputs: subscription_id (required). Returns: object
find_guestC
Search or list guests.
OwnerRez bounds this endpoint by created_since_utc.
Inputs: query, max_items, created_since_utc. Returns: object
get_bookingB
Get full details for a single booking by its OwnerRez ID.
Inputs: booking_id (required), include_guest. Returns: object
get_message_eventB
Get one stored message event (including its raw webhook payload) by id.
Inputs: event_id (required). Returns: object
list_bookingsA
List bookings.
OwnerRez bounds this endpoint by since_utc (bookings created or changed
since a UTC time), not by stay dates — so a time bound is always sent. Use
arrival_start / arrival_end to narrow to a stay window client-side.
Inputs: status, max_items, since_utc, arrival_end, +4 more. Returns: object
list_feesB
List booking fees, optionally for a single booking.
Inputs: max_items, booking_id. Returns: object
list_messagesA
List the messages in a conversation thread.
Inputs: thread_id (required), max_items, since_utc, include_drafts, +1 more. Returns: object
list_open_messagesA
List inbound guest messages captured by the webhook receiver that haven't been marked handled yet — your "open messages" inbox.
Each entry includes its store id, thread_id (use with send_message), guest, body, and when it arrived. Requires the webhook receiver to be running and subscribed (see create_webhook_subscription with category "message").
Inputs: limit. Returns: object
list_ownersB
List property owners (id, name, contact).
Inputs: max_items. Returns: object
list_paymentsA
List guest payments, optionally for a single booking.
Inputs: max_items, booking_id. Returns: object
list_propertiesC
List properties (id, name, address, timezone).
Inputs: max_items, active_only. Returns: object
list_quotesA
List quotes, optionally filtered to comma-separated property IDs.
Inputs: max_items, property_ids. Returns: object
list_refundsB
List guest refunds, optionally for a single booking.
Inputs: max_items, booking_id. Returns: object
list_webhook_subscriptionsB
List active webhook subscriptions on the account.
Inputs: max_items. Returns: object
mark_message_handledA
Mark a stored message as handled (or reopen it), removing it from the open list. Local bookkeeping only — does not call OwnerRez.
Inputs: event_id (required), handled. Returns: object
send_messageB
Send a message to a guest on an existing conversation thread.
Inputs: body (required), thread_id (required), attachment_url. Returns: object
who_is_stayingA
Show who is currently staying in each property (in-house guests).
Returns one row per active stay (arrival <= on_date < departure) with property, guest name, and dates. Defaults to today. Internally pulls active bookings changed in the last ~year and filters by stay date.
Inputs: on_date. Returns: object
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 18 tools
Each tool targets a distinct resource/action: webhook subscription lifecycle, booking reads, current-stay snapshot, property/owner/guest lookups, financial lists, and message inbox/thread operations. The only potentially close pair is list_messages vs list_open_messages, but they are clearly separated by conversation thread vs webhook inbox.
Most tools follow a verb_noun snake_case pattern (list_bookings, get_booking, create_webhook_subscription, delete_webhook_subscription). Minor deviations like who_is_staying and mark_message_handled break the strict noun-object pattern, and find_guest is singular while list_* tools are plural.
18 tools is on the high side but each maps to a meaningful OwnerRez domain area (bookings, properties, guests, messages, payments, webhooks). It feels slightly broad rather than bloated, and no obvious redundancy inflates the count.
The set covers read-side lookup and the webhook-driven message inbox workflow well, including create/delete subscriptions and send/mark-handled. However, it lacks write/update operations for core entities such as bookings, quotes, payments, and guests, and there is no property/guest detail retrieval beyond lists, so full lifecycle tasks would dead-end.
Maintenance
Related MCP Connectors
Manage OwnerRez properties, bookings, guests, quotes and inquiries.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Ask your AI about your Airbnb and VRBO listings, bookings, guest messages and reviews. Read-only.
Connect any AI agent to 1,000+ apps and 27,000+ actions through one remote MCP server (OAuth).
Related MCP Servers
- AlicenseBqualityCmaintenanceA read-only hospitality-focused MCP server that enables users to retrieve reservation details, listing briefs, and guest conversation contexts from Hostaway. It simplifies hospitality workflows by providing specialized tools for searching threads and viewing reservation data through natural language interfaces.649 npmMIT
- AlicenseNot gradedqualityFmaintenanceConnects AI agents to RealtyCalendar accounts, allowing users to query bookings, availability, and check-ins via natural language, with local-first privacy and read-only access.MIT
- FlicenseAqualityDmaintenanceEnables Claude to interact with your OwnerRez account via natural language, including booking inquiries, income summaries, property stats, and owner statements. Supports optional guest messaging with OAuth setup.211-
- AlicenseBqualityCmaintenanceMCP server that connects OwnerRez to Claude and other MCP clients, enabling natural language management of bookings, guest communication, property info, expenses, and webhooks.183MIT