Careful... your API is showing
MCP is everywhere right now
MCP is everywhere right now. The protocol that lets agents talk to your systems. The thing that changes everything. So I went through the spec to see what it actually is, and the fanfare is wildly out of proportion to what it does. Standardisation is useful. But the hard problem in hospitality was never invocation.
MCP: The protocol everyone's talking about
If you've been paying any attention to agents this year, you'll have seen MCP everywhere. Model Context Protocol. The thing that "lets agents talk to your systems." LinkedIn is full of it. Every dev newsletter has covered it. The general vibe is that this changes everything.
So I went through the spec to see what it actually is.
MCP is a standardised way for a model to call tools. It defines how a model discovers what tools are available, what inputs they need, what outputs they return, and how to invoke them. Transport is HTTPS and JSON. The schema format is consistent. If you build an MCP server, any MCP-compatible client can call it.
That's genuinely useful. Before MCP, everyone was wiring up tool calling in slightly different ways. OpenAI had their function calling format, LangChain had theirs, every framework had its own approach. MCP gives you one way to do it. Standardisation is valuable.
But here's the thing: none of this is new.
Tool calling with models has been around for years. OpenAI functions shipped in 2023. LangChain tools before that. The capability to have a model call an external API, pass parameters, get results back, and continue the conversation has been possible for a long time.
And hotel APIs? They've existed for decades. Availability, rates, booking - all of it accessible programmatically for years. The technology to connect an agent to a booking system has been there. MCP didn't unlock that. It just standardised how you describe the connection.
Can you imagine anyone getting excited about announcing they've built an API? "We've just exposed our availability endpoint!" Nobody would care
And yet that's essentially what MCP is - a standardised way to describe and call APIs. The fanfare is wildly out of proportion to what it actually does. So why hasn't hospitality had good agent-accessible booking all this time?
It's not because we were waiting for a protocol. It's because nobody did the work. The hard problem was never "how do I call an API from a model." The hard problem is everything around it: which venues exist, what they offer, whether they're available, how to match them to what a guest actually wants, how to complete a transaction. Discovery, trust, orchestration.
MCP is a small cog in a much larger wheel. It standardises the invocation layer, which is helpful. But invocation was never the bottleneck.
The other thing to understand is what MCP makes a venue into. When you expose a hotel's booking system via MCP, you're turning it into a tool. Something to be called. Check availability, make booking, confirm payment. Functions.
That's fine for some use cases. But a venue isn't really a tool. It's a participant with its own identity, capabilities, policies, and preferences. The difference matters when you're thinking about how agents should work with venues rather than just call them.
This is where we've focused our attention. Not on the protocol layer, which MCP handles adequately, but on the layers above it. How does a venue declare what it is and what it can do? How does it become discoverable to agents that don't already know it exists? How does intent get matched to options? How does the whole interaction get orchestrated?
That's Echo and the Selfe SDK. The identity and orchestration layers that sit above protocols like MCP. We'll use MCP, or something compatible, for the tool invocation piece. But that's the plumbing. The interesting work is elsewhere.
MCP is useful. It's just not the revolution.