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 reaches the same data as the REST API documented here, but as tools an assistant calls during a conversation rather than endpoints you call from your own code.
The server URL is:
https://app.hosttools.com/mcpThat 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?
| REST API | MCP server | |
|---|---|---|
| You are building | an integration, a sync job, a partner product | an assistant workflow, an internal chat tool |
| Auth | authToken, apiKey, or OAuth Bearer | OAuth Bearer only |
| Shape | one endpoint per operation | 49 tools, 2 resources, 3 prompts |
| Called by | your code | an MCP client, on a user's behalf |
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:
GET /.well-known/oauth-protected-resource/mcpfinds which authorization server secures/mcp(RFC 9728).GET /.well-known/oauth-authorization-serverdiscovers the authorize, token, registration, and revocation endpoints (RFC 8414).POST /oauth/registerregisters the client dynamically (RFC 7591). Public clients get noclient_secret.GET /oauth/authorize, the user consents, thenPOST /oauth/tokencompletes 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.
Scopes
Scopes are granted at authorization and checked when a tool runs. Every tool stays visible to the assistant whatever was granted, and calling one outside the grant returns an insufficient_scope error instead of hiding the tool, so a partial grant produces a clear message rather than a short tool list.
| Scope | Grants |
|---|---|
listings:read / listings:write | Read and update listing details |
reservations:read / reservations:write | Read reservations, and create, update, or cancel them |
calendar:read / calendar:write | Read and update availability and prices |
messages:read / messages:write | Read message threads and send messages to guests |
messageRules:read / messageRules:write | Read and manage automated message rules |
pricing:read / pricing:write | Read and create pricing rules |
listingGroups:read / listingGroups:write | Read and manage listing groups and owner import links |
locks:read / locks:write | Read and manage smart lock settings |
reviews:read | Read guest reviews |
accounts:read | Read connected channel accounts |
user:read | Read the user's profile |
help:read | Read Host Tools help center articles |
webhooks:manage | Create and manage webhook subscriptions |
Tools
Read (16): list_listings, get_listing, 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
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 (10): send_message, set_prices, set_availability, create_reservation, update_reservation, cancel_reservation, update_listing, create_message_rule, pause_message_rule, create_pricing_rule
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.