AI agent integration (MCP)

The Distribution Partner API exposes a Model Context Protocol (MCP) server for AI agents. It wraps the /api/v1/* REST contract documented in the API reference and uses the same schemas, business logic, pricing, and usage rules. Each tool behaves like the corresponding REST call.

Transport & auth

The server is a remote MCP server reachable over streamable HTTP at:

https://ari.console.adrasis.com/mcp

An agent session uses the same authentication as a REST client: it carries the partner's OAuth 2.0 Bearer token (Authorization: Bearer <token>) obtained from the client-credentials flow. The authenticated partner account and scope claims are forwarded unchanged on every tool call. See Authentication for how to obtain the token.

Profile-scoped tools accept an optional MCP-only profile_public_id field. Omit it to use the account's stable Default profile; provide it to select another profile owned by the same account. The facade sends this value as the REST profile-selector header, never in the REST JSON body. A successful structured tool result includes the exact resolved profile_public_id beside the REST response.

Tool catalogue

Each tool maps to a REST operation and uses the same request and response schemas. See the API reference for its parameters.

Accommodation

Hotel fields use the Adrasis hotel id as a decimal string, including a property's public_id and search property_ids. Place fields use the Adrasis place id, and a country its ISO code, and are named for it: place_id, parent_place_id and place_ids. Other resources keep their opaque identifiers. See Hotel id and Place id.

The property metadata catalogue contains only published accommodation properties explicitly opened in the selected profile's Channel Portfolio. Enrollment, source market, destination rules, rates, inventory, and availability neither expand nor narrow list_properties or get_property; only the availability tools take traveler point of sale and decide sellability. Property-list continuations are POS-free cursors bound to the partner account, resolved profile, place, language, delta filter, and profile catalogue revision.

profile_public_id has different semantics on list_bookings: it is an optional account-wide reporting filter for the immutable profile that originated each booking. It does not select a catalogue for that read, and it can identify a profile disabled after the booking was created.

The single-property POST /properties/{property_public_id}/offers/search route is REST-only in this contract. It returns best_allocation and complete room_offers; there is no MCP detail tool. POST /prebook also accepts one to nine one-room proofs as selection_tokens; the MCP prebook tool takes one selection_token, so a room-by-room basket is prebooked over REST. search_property_availability never accepts max_offers, limit, or alternative breadth fields. Page size and opaque continuation belong only to search_place_availability; continue with page.next_cursor alone or with unchanged fields (a changed field is INVALID_CURSOR, an expired cursor is SEARCH_EXPIRED). The cursor preserves a server-resolved request_time, so a continuation may omit that field; an explicitly repeated value must match the first response. A sorted or filtered place search, or a near search, answers PLACE_TOO_BROAD when it exceeds 10,000 visible properties or 1,000 properties still requiring a price after unavailable ones are ruled out. Property-level filters can narrow that set; see Search a whole place.

Transfer, tour & flight

Every vertical operation follows the same search → prebook → book shape as accommodation, and each requires distribution:booking.

Packages

An atomic package is composed, revalidated and finalized through its own three tools; it is then read and cancelled with the get_booking, cancellation_quote and cancel tools listed above. Those last two accept an optional item_public_ids array to target individual package services instead of the whole booking.

Trip grouping

Read tools require distribution:read; booking and vertical tools require distribution:booking. A tool call without the required scope is rejected for insufficient scope. Grant only the scopes an agent needs.

A typical agent flow

1. list_countries → list_place_types → list_places: Resolve canonical geography and searchable place kinds.
2. list_properties / get_property: Build price-free context from the selected profile's Channel Portfolio without a point-of-sale input.
3. search_property_availability, or search_place_availability when walking a geography: request exact top-1 winners with explicit strict or flexible allocation intent; choose a returned allocation and keep its opaque selection_token server-side.
4. prebook: Pass that selection_token to re-price the sealed slots and mint a token. Read the match status and cancellation policy, then confirm with the user. Inventory remains unheld until book.
5. book: Finalize with guest and contact details and a unique idempotency_key.
6. get_booking: Poll until a terminal status if the booking came back pending.
7. list_bookings: Reconcile account-wide by the caller's exact agency_reference or a bounded date/delta window; add profile_public_id only to narrow reporting to one originating profile.
8. cancellation_quote → cancel: Preview the fee, then cancel if the user confirms.

Consuming the contract directly

An agent can also call the REST surface directly from the published contract:

• The published site serves an LLM-readable index of this portal as plain text at /llms.txt.
• The full machine-readable contract is rendered on the API reference page.