Becky_dev

Posted on Sep 23

MCP Is Becoming the Transaction Layer for AI Agents

A few months ago, I thought the interesting part of AI agents was reasoning.

Now I think the more interesting question is:

What can an agent actually do?

An AI agent can plan a trip.

It can compare hotels.

It can understand a user's preferences.

It can even explain why one hotel might be better than another.

But none of that means the trip is actually booked.

There is a big difference between an AI that can talk about an action and an AI that can execute the action.

And this is where I think MCP is becoming much more interesting.

Not just as a protocol for connecting AI models to tools, but as a potential transaction layer for AI agents.

From AI That Answers to AI That Acts

The first wave of AI assistants was mostly about generating information.

Ask:

"Where should I stay in Tokyo?"

And the model gives you a list.

Ask:

"What's a good five-star hotel near Shibuya?"

And it gives you recommendations.

That's already useful.

But imagine the next version.

You say:

"I'm going to Tokyo next Friday for three nights. I don't like crowded areas, I usually wake up late, and I'd rather spend more on dinner than on a fancy hotel. Find me somewhere convenient but quiet, under $250 a night, and book it if the cancellation policy is flexible."

Now the AI has to do much more than generate text.

It needs to:

Understand the user's preferences.
Search real inventory.
Filter hotels.
Compare prices.
Read cancellation policies.
Verify availability.
Potentially confirm the final price.
Create a booking.
Return a confirmation.

This is no longer a chatbot problem.

It's an execution problem.

And that's exactly the part of the AI stack that I find interesting as a developer.

MCP Is Moving Closer to Infrastructure

The recent evolution of MCP makes this even more interesting.

The July 28, 2026 MCP specification introduced a stateless protocol core, removing the old session handshake and Mcp-Session-Id requirement. Requests can now be routed independently, which makes ordinary HTTP load balancing and horizontal scaling much easier.

For developers, this may sound like an implementation detail.

I don't think it is.

It changes how I think about MCP servers.

A small MCP server can start as:

"Here are a few tools my agent can call."

But as more agents depend on those tools, the MCP server starts looking much more like infrastructure.

You need:

authentication
routing
scalability
observability
permissions
reliable tool execution
real-time data
error handling
transaction management

At that point, MCP isn't just a convenient interface.

It becomes part of the execution layer.

The Travel Industry Is Already Showing This

Travel is a particularly good example because almost every useful travel decision eventually becomes a transaction.

Searching for a hotel is easy.

Actually booking the hotel is much harder.

You need live inventory, live pricing, cancellation rules, payment, confirmation and sometimes post-booking servicing.

That's why I'm paying more attention to what is happening in travel MCPs.

Sabre recently said its MCP server is already being used by nearly 80 customers in pilots or production, with capabilities spanning shopping, booking and servicing.

That's a meaningful shift.

We're moving from:

"AI can search travel content."

to:

"AI can interact with travel infrastructure."

And that distinction matters.

Because the value of an AI travel agent isn't really in telling me that Tokyo has 5,000 hotels.

The value is in taking my intent and turning it into a real reservation.

I Think This Changes How We Build AI Agents

If you are building an AI agent today, it's tempting to focus almost entirely on the model.

Which model should I use?

How good is the reasoning?

Should I use a multi-agent architecture?

Should I add memory?

Should I use a bigger context window?

Those questions matter.

But eventually, your agent has to touch the real world.

That's where tools become critical.

Think about a simple architecture:

User
  ↓
AI Agent
  ↓
Reasoning / Planning
  ↓
MCP
  ↓
Travel / Payment / Search / Booking Tools
  ↓
Real-world transaction

The model decides what should happen.

The tools make it actually happen.

This is why I increasingly think of MCP as something closer to an agent's hands than its brain.

The model provides intelligence.

MCP provides access.

The underlying service provides the actual capability.

A Hotel MCP Is a Simple Example

Let's take hotel booking as an example.

A developer doesn't necessarily need to build a complete hotel distribution system from scratch.

Instead, an MCP server can expose tools such as:

{
  "mcpServers": {
    "RollingGo-Hotel": {
      "url": "https://mcp.rollinggo.ai/mcp",
      "type": "streamable-http",
      "headers": {
        "Authorization": "Bearer YOUR_API_KEY"
      }
    }
  }
}

Then the agent can call something like:

searchHotels

instead of the developer building a completely custom integration between the LLM and hotel APIs.

The RollingGo Hotel MCP currently exposes hotel search, hotel detail and search-tag tools through its API-key integration, while its OAuth flow provides additional transaction-oriented capabilities for deeper enterprise integrations.

That's the interesting part for me.

The developer isn't really building a "hotel chatbot."

They're giving an agent access to hotel infrastructure.

The Difference Between Information and Execution

Here's the mental model I use:

Information layer

The agent knows:

"The hotel has a swimming pool."

Decision layer

The agent understands:

"The user prefers hotels with pools because they are traveling with children."

Execution layer

The agent can actually:

"Check whether the hotel has rooms available for those dates and book one."

The third layer is where things become economically interesting.

Because execution creates transactions.

And transactions create revenue.

This is also why travel companies are increasingly experimenting with MCP and AI-native distribution.

SiteMinder, for example, has been connecting hotel inventory to AI booking channels through MCP, while other travel infrastructure companies are working toward similar agent-accessible booking experiences.

The direction is becoming clearer:

AI is becoming a new interface for travel commerce.

But There Is a Problem

Giving an AI agent access to tools is powerful.

It is also dangerous if the tools are poorly designed.

A search tool is relatively low risk.

A booking tool is different.

A payment tool is even more sensitive.

The agent needs to know:

What is read-only?
What creates a transaction?
What requires confirmation?
What can be automatically executed?
What permissions does the user have?
What happens if the price changes?
What happens if the booking fails halfway through?

This is why I don't think "just connect your API to MCP" is enough for production agents.

Tool design becomes part of product design.

A tool isn't just an API endpoint anymore.

It is an action that an AI may decide to take on behalf of a human.

The New Developer Question

For traditional software, we ask:

"What API does this product have?"

For AI-native products, I think we'll increasingly ask:

"What actions can an agent perform?"

That is a very different question.

Imagine two hotels.

Hotel A has a beautiful website, great SEO and a traditional booking engine.

Hotel B has a machine-readable inventory, clear policies, agent-accessible tools and real-time booking capabilities.

For a human browsing Google, both may look similar.

For an AI agent, they are completely different.

One is discoverable.

The other is executable.

And I think that distinction is going to matter more over time.

MCP May Become a New Distribution Layer

This is the part I'm most interested in.

Travel distribution has traditionally looked something like:

Hotel
 ↓
Supplier / GDS / OTA
 ↓
Website / App
 ↓
Human

The emerging agentic model looks more like:

Hotel / Travel Supply
 ↓
Travel Infrastructure
 ↓
MCP
 ↓
AI Agent
 ↓
User

The interface is no longer necessarily a website.

It might be ChatGPT.

It might be Claude.

It might be a travel agent someone built with an open-source framework.

It might be a personal AI assistant running locally.

That means distribution is potentially moving one layer closer to the agent itself.

And that creates a completely new developer ecosystem.

The Real Challenge Isn't MCP

Ironically, I don't think MCP itself is the hardest part anymore.

The protocol is becoming increasingly standardized.

The harder question is:

What should we expose through it?

A bad MCP server can expose 100 tools and still be almost useless.

A good MCP server might expose five carefully designed tools that an agent can reliably understand and execute.

For travel, I would rather have:

searchHotels
getHotelDetail
confirmPrice
createBooking
getBooking

than dozens of fragmented endpoints that force the agent to understand complicated internal business logic.

The abstraction should be designed around agent actions, not just legacy API structures.

That's a subtle but important difference.

We're Building for a Different Kind of User

Traditional software assumes the user clicks buttons.

Agentic software assumes the user expresses intent.

That's why APIs designed for humans and APIs designed for agents shouldn't necessarily look identical.

A human can understand:

"Click here → select room → choose cancellation policy → enter guest details → pay."

An agent needs structured capabilities and predictable responses.

It needs to know:

"What can I do?"

"What arguments do I need?"

"What will happen if I call this?"

"Is this action reversible?"

"Does this require confirmation?"

That's why I think MCP server design will eventually become its own engineering discipline.

Not just API engineering.

Not just prompt engineering.

Something in between.

My Takeaway as a Developer

When I started looking at Hotel MCPs, I mostly thought about connectivity.

How quickly can I connect an agent to hotel inventory?

Now I think the bigger question is:

What happens when millions of agents can access the same kind of real-world capability?

Search will become agent-native.

Travel planning will become agent-native.

Booking will become agent-native.

Payments will become increasingly agent-native.

And eventually, the user's interface may become almost invisible.

You won't open a hotel website.

You won't compare 20 tabs.

You may simply tell your agent what you want.

The agent will reason about it.

MCP will connect it to the tools.

And the underlying infrastructure will execute the transaction.

That's the future I find more interesting than another chatbot demo.

Because the real breakthrough isn't when AI gives you a better answer.

It's when AI can do something useful in the real world — reliably, securely and with your permission.

And for developers building that future, MCP might be one of the most important pieces of infrastructure to understand.

Try It Yourself

If you're building an AI travel agent, the easiest way to understand this shift is not to read another article.

Build something.

Connect an MCP server.

Give your agent access to live hotel data.

Then ask it something simple:

"Find me a hotel in Tokyo for three nights, compare the options based on my preferences, and tell me what you would book."

That's when MCP stops being a protocol diagram.

It becomes a product.

And that's when AI agents start getting interesting.

GitHub: RollingGo Hotel MCP

Protocol: MCP

Use case: AI Agent + Real-time Hotel Search + Booking Infrastructure

References

MCP 2026-07-28 Specification — stateless protocol core and infrastructure changes.
Google Cloud — MCP stateless architecture and routing.
Sabre — MCP adoption across travel shopping, booking and servicing.
RollingGo Hotel MCP — open-source hotel MCP implementation and developer setup.
SiteMinder — connecting hotel inventory to AI booking channels through MCP.

DEV Community