MCP Server

The Host Tools MCP server gives AI assistants access to your account over the Model Context Protocol: Claude, Cursor, and anything else that supports MCP with OAuth 2.0. It covers much of what the REST API documented here does, as tools an assistant calls during a conversation instead of endpoints your code calls. The two don't match exactly. Analytics is only available over MCP, and webhooks, owner import, and creating or deleting listing groups are only available over the REST API.

The server URL is:

https://app.hosttools.com/mcp

That is the only value a client needs. It discovers the authorization server, the registration endpoint, and the token endpoint from there.

Which one should I use?

Both use the same account model and the same OAuth provider, so a partner can ship both against one integration.

Authorization

MCP clients authorize with the same OAuth 2.0 endpoints documented in this reference. A compliant client runs this flow on its own:

1. GET /.well-known/oauth-protected-resource/mcp finds which authorization server secures /mcp (RFC 9728).
2. GET /.well-known/oauth-authorization-server discovers the authorize, token, registration, and revocation endpoints (RFC 8414).
3. POST /oauth/register registers the client dynamically (RFC 7591). Public clients get no client_secret.
4. GET /oauth/authorize, the user consents, then POST /oauth/token completes the authorization code flow with PKCE (S256).

Access tokens last 1 hour and refresh tokens 30 days, and clients refresh in the background. Revoke with POST /oauth/token/revoke.

/mcp accepts bearer tokens only. The legacy authToken and apiKey headers do not work there.

Two account conditions are checked on every request, not only at authorization: the subscription must be in good standing, and the token must belong to the account owner. A sub-user's token gets 401 invalid_token, so team members connect an assistant to their own account rather than to the account they were invited to.

Access

An assistant you connect to your own account registers with every scope unless it asks for fewer, so it can use every tool on this page.

Scopes only limit partner apps registered with a narrower set. Calling a tool outside that set returns an insufficient_scope error that names the scope it needs, and the tool stays in the assistant's list. The REST API checks the same scopes.

Tools

Read (18): list_listings, get_listing, get_listing_content_options, get_calendar, get_reservations, get_reservation, get_quote, get_message_thread, get_message_rules, get_pricing_rules, get_reviews, list_accounts, get_account, get_user, list_help_articles, get_help_article, collect_date_range, list_errors

list_errors returns the problems Host Tools is reporting for the user right now (a disconnected account, a refused price or minimum-nights change, a failed scheduled message, and so on), the same list as GET /api/getErrors and the type: "error" webhook. Each error is only returned when the granted scopes cover its data, for example accounts:read for account.disconnected.

Analytics (23): get_headline_kpis, get_occupancy_stats, get_revenue_stats, get_adr_stats, get_revpar_stats, get_timeseries_stats, get_pace_stats, get_listing_breakdown_stats, get_channel_performance, get_booking_pattern_stats, get_cancellation_stats, get_reservation_status_stats, get_gap_analysis, get_turnover_stats, get_check_ins_check_outs, get_upcoming_reservations, get_pricing_stats, get_review_stats, get_review_analytics, get_response_time_stats, get_response_time_breakdown, list_listing_groups, get_metric_definitions

Write (15): send_message, set_prices, set_availability, create_reservation, update_reservation, cancel_reservation, accept_booking_request, decline_booking_request, preapprove_inquiry, send_special_offer, update_listing, manage_listing_photos, create_message_rule, pause_message_rule, create_pricing_rule

accept_booking_request works on Airbnb requests to book (status pending) only for now. decline_booking_request works on Airbnb requests to book (status pending) and on Booking.com requests to book (status inquiry, with one of Booking.com's upper-case reasons).

preapprove_inquiry works on Airbnb, Booking.com and VRBO inquiries (status inquiry). On Booking.com it approves the guest's request to book. On VRBO it needs a message to the guest, which goes with the pre-approval; Airbnb and Booking.com take no message. VRBO support is new and not yet tried on a live account.

send_special_offer works on Airbnb and VRBO inquiries. Booking.com has no special offers. A message can only go with a VRBO offer.

Each tool documents its own parameters over the protocol, so an assistant discovers them with tools/list. There is no separate parameter reference to keep in sync.

Resources and prompts

resources/list returns exactly two entries, hosttools://user and hosttools://listings. Three more are templates the assistant fills in on demand (a single listing, a listing's calendar for a date range, and a single reservation), so they are not enumerable. Two entries is the correct result and does not indicate a partial connection.

Three prompts ship with the server: daily_briefing, guest_response, and pricing_review.

Transport and limits

POST /mcp carries JSON-RPC 2.0 and returns a JSON body. Every request is served on its own, with no session held between requests, so any instance can serve any request and an mcp-session-id header is ignored rather than rejected.

GET /mcp currently returns 405. The server sends nothing on its own initiative today, so there is no stream for a client to attach to, and compliant clients fall back to request/response. DELETE /mcp returns 204 so a client's teardown succeeds.

Requests are limited to 300 per minute, keyed on the access token. Going over returns 429 with a JSON-RPC error.

Connecting as a user

Hosts who want to connect their own assistant should follow How do I use the Host Tools MCP server?. It gives the same server URL without the protocol detail.