How to Make Your Tours Bookable by AI Agents: An MCP Primer for Travel Suppliers

At 9:12 on a Tuesday night, a traveler in Minneapolis types into an assistant: find us a small-group sunrise hike near Santa Fe this Saturday, two adults, under four hours, and we’d love to bring the dog.

The assistant does not open your homepage and admire the photography. It looks for something it can call: a list of departures, a price, a policy, a way to hold two seats. If it finds that for your competitor and not for you, the recommendation is settled before anyone reads a word of your copy.

That is the world the large distributors are building for. Skift reported in May 2026 that Expedia Group is preparing to launch a B2B Model Context Protocol (MCP) server so partners’ AI agents can connect directly to its inventory, from a B2B business that already processes 21 billion API calls a day. lastminute.com has opened an MCP flight server to AI models. Phocuswright’s 2026 research found that 61% of travel businesses surveyed are experimenting with or scaling agentic AI.

None of this is bad news for an independent tour supplier, but it does set a deadline. If agents can reach your tours only through an intermediary, they will see you as one row in someone else’s catalog, with no packaging logic, no voice and a thinner margin. This primer covers the alternative, which is your own agent-facing interface, and the decisions that matter more than the protocol itself.

What MCP is, in plain terms

The Model Context Protocol is an open protocol for connecting AI assistants to tools and data. A business runs an MCP server. An assistant, the client, connects to it, reads what the server offers, and lets the model decide when to use each capability. A server can offer three kinds of things:

• Tools: actions with typed inputs and outputs, such as “check availability for this departure and party.”
• Resources: readable context, such as your cancellation policy or meeting-point directions.
• Prompts: reusable templates for common tasks. Suppliers rarely need many of these.

A useful mental model is a front desk with a printed card listing what staff may do for a guest. The card is short, every item on it is precise, and some things are simply not on it. MCP doesn’t replace your reservation system or your website. Almost always it is a thin layer over the booking API you already have, plus the rules that decide what an outside agent may do.

So the hard work isn’t technical. It’s editorial: deciding what goes on the card.

The five tools a tour supplier needs

Most tour and activity businesses can cover a realistic agent journey with five tools. Two more are worth adding once holds go live.

Tool	Agent provides	You return	If you skip it
search_departures	Date range, party size, area, max duration, tags	Matching departures with start times and seats left	Agents scrape, or route through an intermediary
get_product	Product ID	Description, meeting point, inclusions, fitness level, age, pet and accessibility rules	Agents guess, and guesses become complaints
check_availability	Departure ID, party composition	Live seats, price by traveler type, hold window	Agents quote stale prices
create_quote	Departure, party, add-ons	Itemized total, taxes, policy version, quote expiry	No stable number for the traveler to agree to
create_hold	Quote ID, traveler contact	Hold ID, expiry time, confirmation step	The agent can recommend but never close
get_hold_status	Hold ID	Held, paid, expired or released	Agents re-ask and double-hold
release_hold	Hold ID	Confirmation of release	Seats stay locked until expiry

Write tool descriptions like instructions for a new hire

The model picks tools by reading their descriptions, so treat descriptions as operating instructions, not API reference. Compare two versions:

• Weak: “Returns availability.”
• Useful: “Returns live seats and per-person prices for one departure. Call this before quoting. Children under 8 may not join hikes rated strenuous; if the party includes one, the response says the departure is unavailable and why.”

The second version heads off a whole class of bad recommendations. If your staff answer the same question twenty times a month, the answer belongs in a description or a resource.

One request, six calls

Here is how the Minneapolis request plays out against a well-built server, using a hypothetical operator with three Saturday departures.

1. search_departures for Saturday, two adults, within 45 minutes of Santa Fe, under four hours. Three results: a 6:40 AM ridge sunrise hike (3.5 hours), a 7:15 AM canyon walk (2.5 hours) and a 9:00 AM history stroll (2 hours).
2. get_product on all three. The ridge hike is rated strenuous and doesn’t allow dogs. The history stroll allows dogs but isn’t an early departure. The canyon walk allows leashed dogs under 40 pounds.
3. The agent asks the traveler one question: “Would a 7:15 start work, and is your dog under 40 pounds?” The answer is yes to both.
4. check_availability on the canyon walk returns four seats left, $85 per adult, a $10 pet fee and a 20-minute hold window.
5. create_quote returns $180 before taxes, itemized, under cancellation policy cxl-2026-03 (full refund up to 48 hours out, and a full refund if the operator calls off the walk for weather), valid for 20 minutes.
6. create_hold holds two seats and hands the agent a confirmation step for the traveler.

The hold response is deliberately boring:

{
  "hold_id": "H-0417",
  "departure_id": "canyon-walk-2026-10-31-0715",
  "seats": 2,
  "total": { "amount": 180.00, "currency": "USD", "taxes_included": false },
  "policy_version": "cxl-2026-03",
  "expires_at": "2026-10-27T21:41:00-06:00",
  "next_step": "Traveler confirms and pays through the secure link sent by SMS and email"
}

Notice what did the work. It wasn’t the protocol. It was the content. The fitness rule, the pet weight limit and the policy version were all data the agent could read. Without them, the agent would have either recommended the ridge hike (wrong) or given up (a lost sale).

Policies are the product

To an agent, a policy that lives in a PDF effectively doesn’t exist. Publish each one as a structured resource with a version number:

• Cancellation and changes: windows, fees, how refunds are paid, and what counts as a weather cancellation.
• Eligibility: minimum ages, fitness in plain terms (“90 minutes of steady climbing at around 7,000 feet”), pets, and accessibility stated as facts rather than adjectives.
• Weather calls: who decides, by when (“we decide by 5:30 AM and text you”), and what the traveler gets.
• Inclusions and exclusions: what the price covers and what to bring.
• Group rules: maximum party size per booking, and whether minors need a guardian present.

Every quote should carry the policy version it was issued under. When a traveler disputes a fee three weeks later, “they accepted cxl-2026-03 at 9:21 PM through an agent” is a fact you can settle, not an argument.

Checkout: hold, don’t charge

The most important design decision is that agents do not capture payment in your first release. An agent places a short hold, and the traveler completes the purchase on your own checkout. Card handling, consent and the customer relationship all stay with you.

Four guardrails make holds safe:

1. Short expiries. Twenty minutes is plenty for a traveler to tap a link. Long holds invite inventory squatting.
2. Per-client caps. Limit any single agent client to, say, six held seats per departure and twenty across your catalog at any moment.
3. Attribution on everything. Give each connecting client its own credentials and stamp quotes and holds with its ID. You’ll see which agents convert, and you can switch one off without touching the rest.
4. Price integrity. The amount on the hold must match the amount at checkout. If anything can change it, such as currency conversion, the hold says so explicitly.

Delegated payment, where an agent pays within a limit the traveler has set, is coming. We cover those controls in agent-safe payments. It is a second step, not a first.

What to keep off the menu

Some capabilities look helpful and turn out to be dangerous:

• Supplier costs, net rates or margins, even “for context.”
• Guide names, personal phone numbers or schedules.
• Any other traveler’s booking data, including explanations like “two seats opened because a family cancelled.”
• Free-text “notes to operator” fields that can quietly override eligibility rules.
• Changes to, or cancellations of, a paid booking without the traveler confirming on your channel.
• Discount codes or price overrides an agent could apply to its own quotes.

A readiness checklist

Before any agent connects, you should be able to tick every item below. A longer version lives in our agent-ready checklist.

Inventory truth

• Availability comes from the live reservation system, not a nightly export.
• Every departure has a stable ID that survives edits and reschedules.
• Seat counts reflect guide ratios and vehicle capacity, not just the product maximum.

Content

• Each product has meeting-point coordinates, duration, fitness level and eligibility as fields, not prose.
• Pet, child and accessibility details are stated as facts (“two steps at the trailhead, no handrail”).

Policy and checkout

• Cancellation, weather and eligibility policies exist as versioned, machine-readable resources.
• Holds expire, per-client caps exist, and the hold total always equals the checkout total.

Operations

• A named role owns the agent channel, reviews its logs weekly and can revoke a client in minutes.

Start read-only, then earn the right to hold

The order you do things in matters more than speed.

Weeks 1–3: read-only. Expose search_departures, get_product and check_availability, and log every call. You’ll learn which questions agents ask that your content can’t answer. That log is the best content brief you will ever get.

Weeks 4–8: quotes and holds on one product line. Choose a line with simple pricing and plenty of availability. Watch three numbers: the share of quotes that become holds, the share of holds that become paid bookings, and how often travelers abandon checkout because something didn’t match what the agent told them.

After that: widen on purpose. Add products, add clients, and consider delegated payment only once hold-to-paid conversion is steady and disputes are close to zero.

That sequence is the backbone of most Agentic Commerce Readiness engagements we run, and it’s the order in which Nova’s Agent Gateway switches on catalog, policies, holds and attribution. Businesses that run many short departures each day tend to see results first. Our page for experiences and activities describes that pattern.

The first thing to do on Monday

Open your inbox and pull the last fifty questions travelers sent before booking. Sort them into four piles: availability, eligibility, logistics and policy. Agents will need answers to every question in those piles. Each one you can answer with a field instead of a sentence is a booking an agent can close without phoning you.