Talking to Oracle OPERA in plain English

1st May 2026

If you have ever worked anywhere near a hotel, you know Oracle OPERA. It is the property management system that runs a huge slice of the world's hospitality industry, including all 41 of our properties at Staycity Group. It is powerful, it is comprehensive, and it is also a textbook "old-style enterprise system": dense screens, deeply nested menus, two API generations layered on top of each other (the legacy OWS SOAP services and the modern OHIP REST APIs), and a learning curve that traditionally takes new analysts months to climb.

I have been spending evenings and weekends building something to change that. It is called opera-mcp, and it is a Model Context Protocol server that gives any LLM — Claude, ChatGPT, our internal agents — direct, safe, natural-language access to OPERA. The result has genuinely surprised me, and the team using it.

What it actually is

Under the hood, opera-mcp is a small Node.js monorepo that:

  • Indexes the 3,196 OHIP REST operations across 46 modules, plus 201 OWS SOAP operations across 12 services. That is the entire OPERA Cloud API surface, searchable.
  • Exposes a handful of MCP tools — ohip_execute, ows_execute, route_query, list_operations, find_equivalent, plus log-query tools — that an LLM can call directly.
  • Adds a discovery layer on top: synonym expansion, a 123-concept domain index, and a router that maps a fuzzy English question to the right API call ("guests arriving tomorrow" → the right OHIP reservation search with the right filters).
  • Enforces safety by default: read-only mode is on unless explicitly disabled, destructive operations require a two-step confirm with an expiring token, and every call is logged with a correlation ID into a local SQLite store.
  • Runs as a hosted MCP server on Azure behind Caddy, so anyone on the team can point Claude Desktop or Claude Code at it with a single API key and start asking questions.

The whole thing is roughly 800 tests, several thousand lines of TypeScript, and zero hand-written API clients — the OHIP layer is fully generated from the OpenAPI specs Oracle ships.

What this looks like day-to-day

The shift, once it lands in someone's workflow, is jarring in the best way. A few real examples from the last few weeks:

  • "How many room nights did our employees stay across the portfolio last quarter, by property?" Previously: pull a folio extract, dump it into Excel, manually filter on the staff rate codes, pivot. Roughly half a day of work for an analyst who knows where to look. Now: one prompt. Claude calls route_query, walks through reservations and folios via the MCP, and comes back with the table — and the SQL-equivalent reasoning, so we can sanity-check it.
  • "Find every reservation for John Smith across all our hotels and tell me which ones are still active." A cross-property profile + reservation lookup that used to require logging into each property individually. Now it is a single sentence.
  • "What changed on confirmation 38291 in the last 24 hours, and who changed it?" The MCP queries the OPERA audit log, dedups the noise, and explains what happened in English. The same answer used to require knowing which audit screen to open and how to read its abbreviations.
  • "Why did this rate plan stop showing up on Booking.com last Tuesday?" A diagnostic that used to bounce between three teams. The agent now pulls the rate availability, the channel mappings, and the recent OWS log entries, and points at the cause directly.
  • "Build me a Python script that pulls availability for the next 90 days for IEHI0012 and writes it to a CSV." The agent uses the MCP to discover the right operation, calls it once to confirm the shape of the response, and then writes a working script. End-to-end, a few minutes.

None of these are toy examples. They are tasks that used to live on someone's to-do list for days because the person who knew the screen path was busy.

Why an LLM-shaped interface is the right one for OPERA

I think the deeper lesson here is not specific to OPERA — it applies to every enterprise system of a certain age. Two things are simultaneously true:

  1. The data and capabilities are extraordinary. Decades of domain modelling, every operational nuance you can imagine, every regulatory edge case, all of it captured in the schema.
  2. The interface is a productivity tax. Forms designed in the early 2000s, terminology that only makes sense if you grew up in hospitality, dozens of mandatory fields where you only care about two.

The traditional answer was "build a custom UI on top of the API". That works, slowly, for the ten use cases you anticipate, and not at all for the hundred you don't. An MCP server inverts the problem. Instead of pre-building screens, you give the LLM the whole API surface plus enough metadata to reason about it, and the user describes what they want in their own words. The "interface" gets generated on the fly, every time, fitting the question that was actually asked.

The classic enterprise-software complaint — "the system can technically do that but no-one knows how" — quietly disappears.

On safety, because someone always asks

OPERA is not a system you want an over-eager LLM doing creative writing on. A few non-negotiables baked in from day one:

  • Read-only by default. POST/PUT/PATCH/DELETE calls are blocked at the HTTP-client level unless the operator explicitly turns them on for a session.
  • Two-step confirm for any write. The MCP returns a preview with a token; the agent has to come back with the token to actually execute. No "oops, I created 400 reservations" stories.
  • Per-session credentials and isolation. Each connected user gets their own session context with their own hotel scope; nothing leaks between them.
  • Full audit trail. Every call, request, response, and correlation ID is persisted locally so we can review what the agents did.
  • A single ring-fenced test hotel where automated tests are allowed to do anything they want.

These are not afterthoughts — they are why I am comfortable letting the team actually use this on production data.

The bigger picture

I keep coming back to a thought I shared at Stripe Sessions last week: the next wave of enterprise productivity is not going to come from yet another redesigned UI. It is going to come from putting our existing systems — the ones that already encode decades of business logic — behind LLM-shaped interfaces, and letting the agents do the menial wiring that humans currently do by hand.

For us at Staycity, OPERA is the first big one. F&B POS, channel manager, BI warehouse, and the rest of the stack are next. The pattern, once you have built it once, is the same: index the API surface, add a discovery layer, enforce safety at the gate, expose it as MCP, watch the team's "how do I…" questions turn into one-liners.

If you operate any large enterprise system and you are wondering whether this approach makes sense for you, the honest answer is: it almost certainly does, and the building is much less work than you expect. Happy to compare notes — drop me a line.