# An open-source hotel PMS connector keeps AI booking changes off by default

By MarketScale Newsroom · Published 2026-10-18 · Hospitality on MarketScale
Canonical: https://www.marketscale.com/industries/hospitality/an-open-source-hotel-pms-connector-keeps-ai-booking-changes-off-by-default

> Miquel Gelabert Cifre's open-source MCP server gives AI assistants nine read tools on a hotel PMS and keeps reservation changes behind two locks.

## Key points

- A preview that changes nothing until someone says yes turns an eager AI assistant's guess about a reservation into a decision a person can veto.
- For hotel groups running more than one PMS, a translation layer built on hotel concepts keeps the assistant's tools the same while only the adapter underneath changes; the second adapter so far is read-only and lacks availability and KPIs.
- The switch that enables AI booking changes is a governance decision: which role holds it belongs in the deployment plan before any assistant gets write access.

The server has nine tools that read hotel data. It also has tools that can change a reservation, and those stay switched off unless someone turns them on deliberately. That's the core design of an open-source server Miquel Gelabert Cifre built to connect AI assistants to a hotel property management system, which he described in an Oct. 8 piece for Hotel-Online.

Gelabert Cifre works in operations at a company that makes CRM software for hotels. His background is in support and onboarding, and he says that work showed him what hotel data is like in practice, not the polished version in a sales demo.

His goal was to answer one narrow question: how can an AI assistant be allowed to communicate with a hotel's property management system without creating risk? What came out of it is a software project, and it is also a permission design. A hotel technology lead, or whoever signs the PMS contract, gets a concrete set of controls to look for in any AI integration a vendor pitches. He aims his lessons at developers and revenue managers too, saying most of them apply across all three roles.

The project is an MCP server, which is a small layer of software that sits between a PMS and an AI assistant. Its first adapter connects to a cloud PMS with an open, documented API. The protocol is young, but it is no longer niche. Anthropic released it as open source in November 2024, intending it to be a common standard that lets AI assistants reach external tools and data. Since then, the major AI assistant platforms have adopted it.

Block Field

That adoption is what makes a single hotel connector worth a look. A server written once could, in principle, be called by any assistant that speaks the protocol, rather than being tied to one chatbot vendor's integration.

## What nine read-only tools cover

The first version did nothing but read. Today the server's nine read tools are:

- Property list
- Arrivals for today
- Departures for today
- Search across reservations
- Full detail on one reservation
- Room-type availability
- Guest profile and past stays
- Occupancy KPIs
- Housekeeping status

Even that is enough for real front-office work. A front office manager can ask who's arriving today, or how many sea-view doubles are left for next weekend, and get an answer from live PMS data instead of a report someone exported on Monday. Nothing here needs permission to touch a booking.

The list also reaches past the front desk. Occupancy KPIs are revenue-meeting material, and housekeeping status is a rooms-division question, so one read layer serves several departments from the same live records.

Reading has a second job. Gelabert Cifre says it is where a team discovers how messy its data is, and he wants that discovery made before the software is allowed to change anything. For a property, that suggests the read-only phase doubles as a data audit, run against live records before any write path exists.

## Two locks before a booking changes

The project includes tools to create, modify and cancel a reservation. They're off by default and appear only if whoever runs the server sets an environment flag. Even with the flag on, each write call first returns a preview of what it would do, and nothing changes until the tool is called a second time with explicit confirmation. Gelabert Cifre still calls the write tools experimental, and he says he wouldn't let any agent touch production reservations without an equivalent check.

He says that second lock matters more than it sounds, because language models push hard to be helpful. Ask one, in loose terms, to sort out a guest's booking (his example is "sort out the Müller booking"), and it could conclude that the neatest fix is to cancel and rebook, which might be exactly the wrong result for that guest. With a preview that changes nothing until someone approves it, an eager assistant's guess becomes a decision a person can veto.

The design also hands the hotel a decision it can't pass to the model. Whoever controls the environment flag controls whether the assistant can write at all. So the question of who holds that switch, whether IT, a front office manager or the vendor, belongs in the deployment plan. A confirmation step also only protects the property if the person confirming actually reads the preview.

Block Field

## Hotel words instead of vendor endpoints

The obvious approach would be to copy the PMS API call by call. Gelabert Cifre rejected that early on. Vendor APIs are written for a developer who already understands the vendor's data model, and a language model does not. Instead he created a vendor-neutral set of hotel concepts (reservation, guest, property, availability, occupancy KPIs), with an adapter that converts each PMS into that format.

The payoff showed up when he added a second PMS: it took a new adapter, with no new tools. That second adapter is read-only, has been tested against a public demo environment, and doesn't yet cover availability or KPIs. For a management company running several PMS brands across a portfolio, this is the part worth studying. The assistant's vocabulary stays the same while the plumbing underneath changes.

Then there's the wording, which turns out to be the interface itself. With MCP, a model decides which tool to use based mostly on its name and a short description, so that text needs the same attention as a front desk script. A tool called get\_arrivals, described as returning reservations that check in on a given date with today as the default, gets called correctly. A tool with a vague name and a generic description gets called at the wrong moment or ignored entirely.

Another lesson was to have each tool explain its own output. For example, the occupancy tool reports occupancy, ADR and RevPAR. According to Hotel-Online's summary of the piece, the design also spells out dates, time zones, currencies and room details so that errors are less likely. For a group with properties in several time zones, that detail is not cosmetic. An arrivals list for "today" is only right if the assistant knows whose today it means.

## How this fits the unified-platform argument

The wider market numbers explain why a cautious design has an audience. Enthusiasm runs well ahead of results.

Block Field

The first pair of figures comes from a 2026 Canary Technologies study cited in a Cloudbeds buying guide. The second pair comes from BCG's 2025 global pan-industry analysis of AI adoption. BCG defines "future built" as having the most advanced AI capabilities and generating substantial value from them. It defines "AI-scaling" as having a strategy that is starting to produce real returns across multiple organizational activities. BCG found those AI-scaling firms using AI in marketing and revenue, in guest engagement through chatbots and digital concierges, and in property efficiency.

That gap between appetite and scaled results is where a narrow, low-risk starting point earns its place. Nine read tools won't reprice a hotel, but they let a team test an assistant against live data without betting a reservation on it.

The Cloudbeds guide raises a fair objection. Speaking at the Skift Data + AI Summit 2026, Cloudbeds CEO Adam Harris argued that most AI on the market today is probabilistic. These tools field questions, produce impressive demos and make educated guesses. In his view, the AI that really runs a hotel acts with certainty, and an AI capability bought this year could be obsolete by 2029 because it was built on the wrong foundation.

The guide also contends that unified platforms hold a structural advantage in AI when they share data across the PMS, revenue intelligence, channel manager and marketing, since each model then has all the context it needs. Judged that way, a question-answering layer placed over separate systems is the weaker setup.

Harris's diagnosis has two halves, though: operators fail, he argues, because they haven't clearly defined the problem and because they sit on fragmented data. Gelabert Cifre's project starts from the first half, one narrow question settled before any code. And the guide's split between probabilistic AI that answers and deterministic AI that acts is close to what the confirmation gate handles. The model can guess; the commit to the PMS happens only when a person says yes.

Still, both approaches agree on what has to come first. The Cloudbeds guide predicts that once AI booking agents arrive, clean distribution APIs and machine-readable supply will turn into competitive advantages. BCG's March 2026 report on AI-first hotels points the same way, picturing travelers who skip the research and simply tell an AI assistant, "Book me the perfect trip." Gelabert Cifre could only build his first adapter because his target PMS publishes an open, documented API.

Guest-facing vendors are ending up in a similar place. vGuest describes assistants linked to the hotel's PMS and CRM that pass the conversation, with full context, to a real team member when emotion, confusion or sensitivity shows up. The confirmation gate follows the same instinct: automate the routine work and bring in a person when the stakes go up.

## What a pilot should ask for

The second adapter's missing availability and KPI coverage is the next test. Closing that gap could show whether the translation layer holds up across vendors for more than basic lookups, which is the question a multi-brand portfolio would care about most.

For hotels considering a pilot, this suggests the PMS contract could matter as much as the choice of AI vendor, since the server's first adapter was built for a cloud PMS whose API is open and documented. Access belongs on the same checklist. Hotel-Online's summary says the server uses scoped, revocable credentials, so an assistant's reach can be limited to the job and withdrawn without tearing out the integration.

Put together, the posture is easy to describe in a vendor meeting. The assistant reads freely. When it writes, each change shows a preview and waits for explicit confirmation, which could feel a lot like working with a careful new hire.

## Sources

- [Read First, Write Later: What I Learned Connecting a Hotel PMS to AI Assistants](https://www.hotel-online.com/news/read-first-write-later-what-i-learned-connecting-a-hotel-pms-to-ai-assistants)
- [AI Hotel Management Software: Connected Data Over Features](https://www.cloudbeds.com/hotel-management-software-guide/ai/)
- [AI-First Hotels: Leaner, Faster, Smarter | BCG](https://www.bcg.com/publications/2026/ai-first-hotels-leaner-faster-smarter) (Boston Consulting Group)
- [Hotel Chatbot vs AI Guest Assistant: What Changed - vGuest](https://vguest.ai/blog/from-scripted-bots-to-smart-assistants-how-ai-is-rewriting-the-guest-conversation)

Tags: Model Context Protocol, hotel PMS, AI assistants, Anthropic, Linux Foundation, Cloudbeds, hospitality technology, hotel operations, IT governance, front office, open source, AI agents, revenue management

---
Source: MarketScale, https://www.marketscale.com/industries/hospitality/an-open-source-hotel-pms-connector-keeps-ai-booking-changes-off-by-default. Published for AI indexing and citation; cite the canonical URL. Site guide for agents: https://www.marketscale.com/llms.txt