Adrasis runs a Model Context Protocol (MCP) server on top of its Distribution Partner API. An AI agent can search and book accommodation, transfers, tours, charter flights and packages with the same rules as a direct API integration, inside the partner account an inventory owner has set up.
The server wraps the REST contract of the Adrasis Distribution Partner API. Your agent calls tools instead of endpoints, and each tool behaves like the REST call behind it.
If you are comparing travel-related MCP servers, three questions decide most of it: where the supply comes from, who controls what an agent may do, and whether a booking is real. Here, the supply is what an agency or tour operator manages in the Adrasis Console. That inventory owner controls access through a partner account and its scopes. A successful book call creates the reservation and reduces inventory, exactly as a REST booking does.
Nothing is reinterpreted for agents. Tools use the same request and response schemas, business logic, pricing and usage rules as the REST contract, so an agent and a conventional integration work from one set of rules.
# Remote MCP server, streamable HTTP https://ari.console.adrasis.com/mcp # OAuth 2.0 access token Authorization: Bearer <access token>
An agent can also skip MCP and call the REST contract directly. The full machine-readable contract is published in the API reference.
The MCP server is for an AI agent that books from another company's supply through a partner account. The AI Operator runs the work inside your own organization.
Two parties are involved. The inventory owner is an agency or tour operator that keeps its contracts and prices in the Adrasis Console. The partner builds the agent: an OTA (online travel agency), a travel app, another agency or a technology partner that wants an AI travel agent for its own users. The owner creates a partner account, opens the properties the partner may book and issues credentials. From then on, the agent works only inside that account.
The Adrasis AI Operator is a different part of the Console. Your team sends it instructions from the chat panel in the Console, or over email, WhatsApp or SMS, and it prepares work on your own catalog, rates, contracts and distribution. Requests that only read data are answered at once. Anything that changes data is previewed and runs only after you confirm, and the AI Operator never reads another organization's data. See how the AI Operator works.
Every tool maps to one REST operation and uses its request and response schemas. Tools are grouped by product, and each one needs one of two scopes.
Reference data, property content, availability search and the full booking lifecycle for hotels, vacation rentals, villas and apartments.
| Tool | What it does | Scope |
|---|---|---|
search_property_availability |
Find the lowest-priced offer for each of up to 100 properties. | distribution:read |
search_place_availability |
Find the lowest-priced offers in a destination, up to 100 properties a page. | distribution:read |
list_countries |
List countries with IDs, ISO codes and localized names. | distribution:read |
list_place_types |
List the eight place types and which are searchable per country. | distribution:read |
list_places |
Find destinations by country, type, parent or name. | distribution:read |
list_properties |
List property content from the Channel Portfolio, without prices. | distribution:read |
get_property |
Read the full content of one property. | distribution:read |
prebook |
Re-price the chosen offer; return a prebook token, match status and cancellation policy. | distribution:booking |
book |
Confirm the reservation, with an idempotency key for safe retries. | distribution:booking |
get_booking |
Read one booking, or poll a pending one. | distribution:booking |
list_bookings |
Reconcile bookings by your reference, a date window or recent changes. | distribution:booking |
cancellation_quote |
Preview the cancellation fee without changing anything. | distribution:booking |
cancel |
Cancel the booking and apply its fee. Safe to repeat. | distribution:booking |
The single-property offer search, which lists up to twenty choices for one property, is available through REST only.
Each product follows the same search, prebook and book pattern as accommodation. Flights are charter flights, and a round trip is searched as two separate legs.
| Tool | What it does | Scope |
|---|---|---|
search_transfers |
Find transfer offers between two zones for a service date and party. | distribution:booking |
prebook_transfer |
Re-price a transfer offer and return a prebook token with its cancellation terms. | distribution:booking |
book_transfer |
Confirm the transfer, with an idempotency key. | distribution:booking |
search_tours |
Find offers for a tour on a departure date for a party. | distribution:booking |
prebook_tour |
Re-price a tour offer and return a prebook token with its cancellation terms. | distribution:booking |
book_tour |
Confirm the tour, with an idempotency key. | distribution:booking |
search_flights |
Find charter flight offers for a departure date and passenger mix. | distribution:booking |
prebook_flight |
Re-price a flight offer and return a prebook token with its cancellation terms. | distribution:booking |
book_flight |
Confirm the flight booking, with an idempotency key. | distribution:booking |
A package sells 2 to 5 services the agent has already selected, across at least two product types, at one inclusive price. Either every service confirms or none does. Once booked, a package is read and canceled with get_booking, cancellation_quote and cancel, and the last two can also target single services inside it.
| Tool | What it does | Scope |
|---|---|---|
search_packages |
Combine 2 to 5 selected services into one offer with one inclusive price. | distribution:booking |
prebook_package |
Re-check every service and return the match status, the compliance disclosure and a prebook token. | distribution:booking |
book_package |
Book the whole package at once: every service confirms, or none does. | distribution:booking |
A trip groups bookings that are already confirmed into one itinerary. Each booking keeps its own total, cancellation policy and lifecycle, so a trip is never a priced package.
| Tool | What it does | Scope |
|---|---|---|
create_trip |
Group confirmed bookings into one trip. Their prices stay separate. | distribution:booking |
get_trip |
Read a trip with its bookings and totals per currency. | distribution:booking |
add_trip_member |
Add an existing booking to a trip. | distribution:booking |
remove_trip_member |
Take a booking out of a trip without changing the booking. | distribution:booking |
cancel_trip |
Cancel every booking in the trip and report each outcome. | distribution:booking |
The documented flow has eight steps, from geography to cancellation. The agent stops for its user's confirmation twice: before it books and before it cancels.
list_countries, list_place_types and list_places to find the country, the place types that can be searched there and the destination itself, such as Antalya.list_properties and get_property. Neither takes a point of sale.search_property_availability for known properties, or search_place_availability to walk a destination. State the allocation intent: strict keeps every room exactly as requested, flexible lets the party be arranged across up to nine rooms. Keep the chosen offer's selection_token server-side.prebook, which re-prices the offer. Read the match status and the cancellation policy, then confirm both with the user.book with guest and contact details and a unique idempotency_key. A retry with the same key returns the original booking instead of creating a second one.get_booking until the status settles.list_bookings, using your own agency_reference or a bounded date or change window. The results carry no guest personal data.cancellation_quote, and call cancel only when the user confirms.Prebook does not hold inventory. Availability is checked again when book runs, so the last room can go to someone else between the two steps, and the agent then searches again. A prebook token is valid for 30 minutes and opens one booking only.
No payment runs through the server. The partner stays the merchant of record. Rates that need a payment step elsewhere, such as a card charge or a deposit schedule, cannot be booked this way.
With the same OAuth 2.0 client credentials a REST integration uses. An agent session authenticates exactly like a REST client.
The partner exchanges its client ID and client secret for an access token at https://ari.console.adrasis.com/api/v1/oauth/token. The token is valid for one hour, and no refresh token is issued: when it expires, the agent requests a new one with the same credentials. The documentation recommends keeping one token and renewing it shortly before it expires, rather than requesting one per call.
The token travels in the Authorization header of the MCP session. The partner account and the token's scopes are forwarded unchanged on every tool call, and a call to a tool whose scope the token lacks is rejected.
| Scope | What it covers |
|---|---|
distribution:read |
Reference data, property content and accommodation availability search. |
distribution:booking |
Accommodation prebook, book, booking reads, cancellation quotes and cancellation, plus every transfer, tour, flight, package and trip tool, including their search tools. |
Grant only what the agent needs. An agent that answers availability questions but must never book gets distribution:read alone. New credentials receive both scopes by default, so pick the minimum when you create one for an agent. A token can also be requested with a narrower scope than its credential holds. Error codes and the remaining details are in the authentication guide.
Only what the inventory owner has opened to it. For accommodation, that is the Channel Portfolio of one partner profile.
Property tools return published accommodation properties that are explicitly open in the selected profile's Channel Portfolio, and nothing else. Every partner account starts with a Default profile, which holds a snapshot of the properties published when the account was created. A property published later stays closed to the partner until the owner opens it. Closing a property takes it out of that profile's results without deleting it or closing it in other profiles.
When the same partner needs separate catalogs for different audiences, the owner adds more profiles to the account. Profile-scoped tools accept an optional profile_public_id: leave it out to use the Default profile, or send it to select another profile of the same account. Every successful result names the profile that was actually used. Credentials belong to the account, so one credential works with every profile.
list_properties and get_property show what is open in the portfolio, and they take no point of sale. Rates, inventory and destination rules neither widen nor narrow them. Whether a stay can be sold to a traveler is decided only by the availability tools, which take the traveler's point of sale as a country code.
list_bookings is the exception to profile selection. It reads bookings across the whole account, and profile_public_id there only narrows the report to bookings that one profile created.
The inventory owner sets the partner up in the Adrasis Console. Building, certification and live traffic all use the same host.
The owner opens Partner Network, then Partner Accounts, and creates one account for the relationship. A Default profile comes with it.
The owner opens the intended properties in each profile: one at a time, as a group, or from country and place filters.
A separately named credential for each environment, with the minimum scopes. The secret is shown once, so it goes straight into a secret manager.
Pilot credentials see a demonstration catalog. On promotion to live supply, the client ID, host and integration flow stay the same.
The demonstration catalog has rates and availability generated for testing, and test bookings neither affect real allotment nor create charges. Cancel every test booking anyway: an open test booking holds demonstration allotment, and repeated tests can start returning SOLD_OUT.
No fixed request ceiling is published. Request limits are agreed for each connection, so confirm them with your Adrasis contact before raising traffic. Adding credentials or profiles does not add allowance. The owner can rotate, disable or revoke a credential from the account's API Access tab, and a disabled or revoked credential stops working together with the tokens minted from it.
The owner's side is described in Partner Network and API credentials. If your team is building a travel agent and wants to become a partner, contact us.
Try the Console free to set up your own supply, or tell us about the agent you are building and the access it needs.