What most people get wrong about MCP
If you've spent any time on Twitter lately, it is hard to miss the hype around MCP and how it will open up the world to agents/LLMs. If you have any doubts, just talk to investors, many of whom think there won't be any APIs ten years from now. Based on experience as an engineer and Hacker News' lukewarm reception on MCP, I do have some doubts. Even more so since no one seems to talk about who is supposed to build and maintain all of these MCP servers.
Of course, Stripe, GitHub and other hot tech companies are first in line to jump on the bandwagon and let agents do billing (which, in the case of Stripe, might be a good idea given that their API has slowly morphed from being best in class to whatever this is).
But I would bet a lot of money that by the time SAP comes up with an official MCP server for their R/3, general superintelligence will have taken over the world already (and hopefully shut down all businesses still relying on R/3). So what? Well, if we're serious about enterprise AI, agentic workflows, and getting rid of all the scribes of this world, we need to be able to interact with the systems of records that underpin these processes.
These data sources are not OpenAPI-speced, GraphQL-enabled, or AI-first. They are complex, difficult to access, and contain the data that runs the world.
LLMs are terrible at figuring out how to navigate old SOAP APIs or mainframe interfaces. They hallucinate parameters, mess up authentication flows, and can't handle the bizarre edge cases these systems accumulated over decades. An MCP server could abstract all that away... if someone builds it.
The original software vendors? Unlikely. They're busy maintaining their existing products. Many are struggling just to keep the lights on with their current engineering teams.
The community? For popular systems, this might work, but what about that custom ERP your company built in 2003? Or that healthcare scheduling system that only 12 hospitals use? The long tail is very long, and the community can't cover it all. And I don't see a single MCP server that's handling SOAP, because quite frankly no one wants to deal with SOAP, particularly not the folks building MCP servers.
We've been experimenting with two approaches:
Using superglue to create a bridge between MCP and legacy systems. This is a work in progress, but it seems to be working quite well, and we'll release the MCP component soon.
Using LLMs to generate the MCP server from the legacy system's documentation. So far, this has been more difficult than expected (given variability in response data, custom fields, etc), but we're still exploring it. Testing is a nightmare.
The more I think about it, the more I'm convinced this is going to be a messy, multi-year transition. We're not going to wake up tomorrow in an MCP wonderland where everything just works. Instead, we'll see islands of automation forming around the systems that are easiest to integrate. The systems that actually run the world? They'll be the last to join the party.
This creates a bizarre reality where the most modern tech companies benefit first from these advancements, while the industries that need automation the most (healthcare, government, manufacturing) are left behind due to their legacy tech debt.
I suspect we'll see a new middleware industry emerge specifically around bridging MCP to legacy systems. It won't be sexy work, but it'll be valuable. We’re going for it. Companies that deeply understand both the old world of enterprise software and the new world of AI interfaces will be positioned to create massive value.
For now, I'm focusing on building reusable patterns that make it easier to wrap these systems. If we can't convince every legacy vendor to support MCP (and we can't), then we need to make it 10x easier for engineers to build these bridges themselves.
The real question is whether MCP will reach critical mass before something else comes along to replace it. The standards wars are just beginning, and I'm not convinced MCP will be the final word. But whatever wins, these legacy integration challenges aren't going away. And we’re building superglue to solve this.