What MCP means for hotels: AI assistant access in plain words
MCP gives AI assistants a standard way to connect to hotel systems. This guide explains what the protocol does, what it does not, and how to judge any AI connection offered to your hotel.
Contents
Key takeaways
- MCP gives an AI assistant a standard way to see what a hotel system offers and to ask it to act; it grants no permission by itself.
- The specification states that the protocol cannot enforce its own safety principles, so consent, access limits and logging must be built into the hotel system and the assistant.
- Least privilege is the working rule: an assistant that only needs to check availability should not hold permission to change a rate or read a guest's bill.
- Every connection can be judged with four questions: which actions are on the menu, who granted access, what limits apply, and what gets recorded.
- A foreign hotel software provider announced a connection for AI agents in September 2025 and a domestic one in October 2026; AI Otel does not claim to be first.
MCP, the Model Context Protocol, is an open standard that lets an AI assistant read a hotel system's menu of data and actions and ask it to act. The protocol only opens the doorway: what the assistant may see, what it may change and what must wait for a person are decided inside the hotel's own system.
A traveler asks an AI assistant to find a quiet double room for three nights with a late arrival. The assistant can reply in a second, but it cannot see one rate or hold one room until the hotel's system gives it a way in. MCP is one answer to that problem, and it is easy to mistake for the whole of it. After reading this, you will be able to explain what the protocol does and does not do, and to judge any AI connection offered to your hotel with four plain questions.
What does an AI assistant need from a hotel system before it can help a traveler?
It needs two things: a way to read what the hotel offers, and a way to ask the hotel to act. Neither happens on its own.
The traveler's request arrives in ordinary language: a quiet double, late arrival, breakfast included. The hotel system holds the answer as structured data: room types, rates, restrictions, availability, cancellation rules and policies. Something has to translate between the two, and that something has to know what it may not do. Which actions are open to the assistant, which need a person, and which are closed are part of the answer, not an afterthought.
Without a shared standard, every pairing of an assistant and a hotel system needs its own private integration, built, tested and maintained separately. Each one is also a new place where access can drift: a permission added for a demo, a limit loosened during a busy season, nobody quite sure who approved what.
Türkiye's data protection authority has described the shape of this in general terms. In its example, an AI agent asked to organize a business trip plans the trip from a calendar, email and travel policy, uses booking platforms to find transport and accommodation, presents the plan for approval, and books after approval. Note the order: find, present, approve, book. The approval step is not decoration, and it is the part a hotel has the most control over.
One more point before any protocol. A hotel that has never defined its actions in a list cannot hand that list to anyone, machine or person. That definition work comes first, and it is the same work whether the caller is an assistant or a new receptionist. We return to it in why each hotel action should be defined once.
MCP in one paragraph: a menu an assistant can read
The Model Context Protocol is an open standard that lets an AI application connect to an outside service and see what that service offers, in a shape the application can read. That is the whole of it, and the details follow from it.
The Model Context Protocol specification (protocol version 2026-07-28, 28 July 2026) defines three roles. The host is the AI application a person uses. The client is the connector inside it. The server is the service on the other side, in this case the hotel's system or something standing in front of it. One host can hold several clients, which is why one assistant can talk to many services.
A server can offer three kinds of thing: resources (context and data), prompts (templated messages and workflows) and tools (functions the AI model can run). In plain words: resources are what the assistant may read, tools are what it may ask to do, and prompts are prepared ways of asking.
The menu metaphor is useful and it has a limit. Reading a menu does not put you in the kitchen. The restaurant decides what is printed, what is available tonight, and what happens when an order arrives. The protocol is open, but openness is about who may implement it, not about who may use your inventory.
Key pointMCP in one paragraph
MCP is an open standard that describes how an AI application asks an outside service what it offers and what it can do. It defines the shape of the question and the shape of the answer. It does not decide which rooms, rates or guest records are on the menu, and it does not decide who is allowed to order.
Is the protocol the lock, or only the doorway?
Only the doorway. MCP describes how an assistant asks; it does not decide what the answer may be, or what happens after.
The specification says this itself. Its security principles state that users must explicitly consent to and understand all data access and operations and keep control over what data is shared and what actions are taken, and that the AI application must obtain the user's explicit consent before invoking any tool. Because the protocol cannot enforce these principles, implementers should build consent and authorization flows into their applications (Model Context Protocol project, specification 2026-07-28, Security and Trust & Safety).
So the real controls sit in two places. The hotel's system decides what it exposes, to whom, under which limits and with what record. The assistant decides what it shows the person and when it stops to ask. A useful test for any supplier: if you removed the protocol tomorrow, would your limits still exist? If the answer is no, the limits were never yours.
What the doorway does buy is shape. One kind of connection instead of many means the hotel can review access once, in one vocabulary, rather than per integration. This is also why the definition of each action matters more than the transport. An action that is not defined once, with its limits, cannot be granted carefully to anyone.
What may an AI assistant see, and what may it change?
Only what the hotel's system exposes to that connection, and only within the permissions granted to it. Reading and changing are separate decisions and should be granted separately.
The specification's working rule is least privilege: clients should request only the permissions, called scopes, that the task needs, and servers must accept only access tokens issued for them. Authorization is optional in the protocol; when a web connection uses it, it builds on OAuth 2.1, the common standard for giving an application limited access on a person's behalf (Model Context Protocol project, specification 2026-07-28, Authorization).
Sort the menu by risk, not by convenience. Seeing availability is not the same as holding a room, and holding a room is not the same as confirming a booking. A hold that expires and returns the room to inventory is a different promise from a confirmed reservation, and the hotel's system should say which one happened. Guest data is the sharp edge: a bill carries personal data, so personal data duties follow the data, not the interface it arrived through. Confirm your own position with a lawyer.
Grant per property and per rate plan where you can. A group with six hotels should not have to accept that one connection reaches all six.
| What the assistant asks for | What it should hold | Who decides | What to check |
|---|---|---|---|
| See availability and rates | Read-only, inventory and rates | Revenue manager | Does the read include cost data |
| Hold a room | Time-limited hold that expires | Owner of inventory rules | What happens when it expires |
| Confirm a booking | Write access, one property | GM or distribution manager | Is the request stored with it |
| Read a guest's bill | Closed by default | Owner of guest data | Is guest consent covered |
| Change a rate | Closed by default | Revenue manager only | Can it be undone, by whom |
| Message a guest | Closed by default | Front office manager | A sent message cannot be recalled |
Who allowed this connection, and how is it switched off?
Someone at the hotel grants it, with a named owner and a written scope, and it can be revoked without rebuilding anything.
Consent belongs to the hotel, not to the assistant. The specification requires the person to understand what data is shared and what actions are taken, and to keep control of both. In practice that means naming one owner: a single person who holds the list of live connections, what each may do, when it was last reviewed and who asked for it.
Ask to see the switch before you sign. Revoking an access token should end access at once, not at the next contract renewal. Ask what happens to data already exchanged when the connection ends, and whether it is deleted, retained or exported.
Türkiye's data protection authority treats agentic AI as a data protection question, not only a software question (Kişisel Verileri Koruma Kurumu, "Etken Yapay Zekâ (Agentic AI)", 12 March 2026). The authority also notes there is no single agreed definition of agentic AI, which is a fair warning against treating any supplier's vocabulary as settled.
Watch outA connection nobody owns is a connection nobody can switch off
If you cannot name the person at the hotel who approved a connection, the actions it may take and the switch that ends it, you do not control that connection yet. Fix that before you discuss features.
What gets recorded, and when does a person decide?
Every tool call should leave a trace, and sensitive actions should wait for a person. The specification asks for both.
The tools section of the specification says that, for trust, safety and security, there should always be a human in the loop with the ability to deny tool invocations. It also asks applications to show which tools are exposed to the model, to signal clearly when a tool is used, and to ask the user to confirm operations. On the service side, servers must validate inputs, apply access controls and rate-limit tool calls, and client applications should log tool usage for audit purposes (Model Context Protocol project, specification 2026-07-28, Tools).
Rate limits are commercial, not technical. A retry loop against a booking action is inventory risk, and the limit should be set by the hotel, not by the assistant. A good record answers five things: who asked, what was asked, what the system returned, who approved it, and whether it can be undone. Design the undo before the do. A change that can be reversed is a different risk from a message already sent to a guest, which cannot be recalled.
ChecklistFour questions to ask of any AI connection, in this order
- Which actions are on the menu, and which are closed?
- Who at the hotel granted access, and who owns it now?
- What limits apply: which property, which rate plans, how many calls, what expires?
- What gets recorded, and where can I read it?
Add a fifth for the contract: how is it switched off, and what happens to data already exchanged?
Where hotel software stands today
Connections for AI assistants are being announced, but they are new and uneven, and each one should be read as a set of permissions rather than a feature.
In October 2025 a plan was announced to let third-party apps work inside a major AI assistant, built on MCP (Skift, 6 October 2025). It was announced as a plan, not as a finished service. A foreign hotel software provider announced a connection for AI agents in September 2025, and a domestic one in October 2026. AI Otel does not claim to be first, and the announcements say nothing about how each connection is limited. For the wider picture, see what has actually been announced about AI assistants booking hotels.
The practical difference between announcements is rarely the protocol. It is whether the hotel can see the action list, set the limits and read the record. Ask for a demonstration on a test property before anything touches real inventory, and run it with the person who will own the connection afterwards.
On our side: AI Otel Core is built and runs in a public demo environment on a fictional hotel. Every hotel action is defined once and served to the hotel team, partners and the AI assistants people already use, each through their own door. It is built and running in a public demo environment on a fictional hotel, ahead of launch, and we do not claim to be first.
What to do next
The protocol is the doorway; the limits are yours, and they live in your own system. The next step is one question to one supplier this month: show me the list of actions an AI assistant can reach in your system, and show me the switch that turns each one off. If either answer is vague, you have learned something useful before any inventory was at risk. To prepare the ground first, work through the AI booking readiness checklist. If you want to see the demo environment described above, request a briefing.
Frequently asked questions
Is MCP something Booking.com or an OTA invented?
No. MCP is an open standard for connecting an AI application to outside data and tools; an OTA is one kind of service that could sit on the other side, and a hotel's own system is another. The standard says nothing about who the service belongs to.
Does my hotel need MCP now?
No. Nothing in the protocol changes what a hotel must do first: define its actions, decide who may take each one, set limits and keep records. A hotel that has done that work can evaluate any connection quickly; a hotel that has not will be sold the same feature twice.
Is MCP secure?
The specification sets principles and states that it cannot enforce them itself. Security comes from the implementation: explicit consent before a tool runs, least privilege in the permissions requested, input checks and rate limits on the service, and logging on the assistant side. Ask each supplier to show all four.
What is the difference between an AI agent and an AI assistant?
There is no single agreed definition, and Türkiye's data protection authority says so in its February 2026 document, using "etken yapay zekâ" for agentic AI and "yapay zekâ aracısı" for an AI agent. In practice, the useful distinction is how much a system does without a person: more independence means more need for limits and records.
Will an AI assistant replace my front desk?
No. The specification asks for a human in the loop with the ability to deny an action, and sensitive steps such as confirming a booking or reading a guest's bill are exactly where a person should stay. The realistic change is fewer routine lookups and more review of exceptions.