230. MCP - It's Hot, But Will It Win?
There's a long history of "middleware" in our industry. Everyone wants it. There's always a hot one, but it rarely makes to the finish line and often disappoints.
If you don’t know MCP—Model Context Protocol—is the hot, new, open source software layer promising to make connecting LLMs and domain specific software a snap. It originates from Anthropic and promises to “simplify artificial intelligence (AI) integrations by providing a secure, consistent way to connect AI agents with external tools and data sources.“ Already a broad set of companies have announced and even delivered support for MCP including OpenAi, Microsoft, Confluent, Cloudflare, and Cursor to name just a few. The fanfare of these announcements makes many observers quick to anoint a winner. It isn’t that simple though. If it were then innovation would quickly grind to a halt. Here’s why.1
The docs are pretty straight forward and it is easy to see why everyone from developers to app providers to enterprise IT are excited by it. Essentially MCP is a way to broker requests between AI providers and consumers while integrating with local data. Using the MCP terminology, a Host might be a desktop tool that wants to access AI from within the tool (like an IDE). Clients maintain 1:1 connections with Servers which are programs that exposes specific capabilities through the API (think of a service). Along with that there can be Local Data and Remote Services which are as you’d expect. It all makes for this tidy picture:
At this early stage of AI every one wants “in” and wants to start building but at the same time everyone is afraid of lockin on the LLM side and everyone surfacing AI in their existing products is afraid of their value add getting sidelined by native LLM capabilities. Having an API that allows LLMs to claim integration with any existing product is a clear win for any LLM trying to build a developer platform. Having an API that allows any developer to plug in a different LLM is a clear win for those products not wishing to put all their chips behind any one vendor. Enterprise IT is excited because one big promise of AI, especially agentic AI, is that everything will connect to everything.
MCP is quite definitionally the classic middleware playbook. That it was introduced by one of the key leaders in the field is itself a classic aspect of the middleware playbook. The industry has a long history of middleware. Many might not recall or even know, but the initial Dept. of Justice antitrust case against Microsoft was all about middleware and at the time the browser itself was viewed as middleware, as was Java. That there was one case about two instances of middleware that were supposed to also replace each other shows the complexity of introducing middleware.
The term middleware appears 38 times in the Consent Decree from 2006 but this is the key definition:
and
The point of middleware is always the same— integrate things on one side with things on the other side. The promise is always that betting on the middleware allows a single party to avoid relying on any instance of one side of the equation while being able to take advantage of the full breadth of market capabilities on the other side. Middleware is supposed to make it such that the best product wins for every customer. The customer being in the middle of both sides of the middleware. It means no one provider (or service) can dominate by monopolizing all consumers (of services) while consumers are placed on level playing fields with all their competitors.
All cross-platform software is a form of middleware. The creators of cross-platform middleware promise to make their middleware run on all operating systems while all the vendors using the middleware layer are granted freedom from worry about the nitty gritty of different platforms.
My own personal experience has seen everything from C to object-oriented programming to application frameworks to SQL data connectivity to business intelligence to HTML to browsers themselves all come and go as middleware solutions. Everyone even today knows a browser isn’t one thing but many. Even more history, when Microsoft started as a company (50 years ago) its claim to the market was creating BASIC to run on all the microcomputers of the time and then build its first MS-DOS applications to do the same using a proprietary middleware toolset which we still actively used for Word and Excel across Windows and Mac when I was a new hire until Office for Windows 95 and eventually Mac Office 98.
That’s enough background but will circle back to this point in a moment as to why this is challenging.
Middleware never quite lives up to these promises in practice. MCP, if history is any guide, will go down one of two paths:
Everyone will use it.
Everyone but one key platform will use it
When (1) happens two things will be true. First, no one will effectively monetize it. Second, every vendor will also add unique aspects to how they consume (client) or produce (server) the interchange. This is internet networking, TCP/IP or HTTP. For (1), in practice the resulting feature is low level enough that all the interesting things will happen on top. Remaining at a low level can happen as something goes from "new and cool" to building out broader capabilities on top of the low level bits. You can think of the full HTTP stack as adding value all on top of the basic protocol.
When (2) happens that is because one platform is the leader along with our industry that has a long history of "everyone but.." APIs/protocols used by everyone but the leader. Usually by the time this leader "comes around" to being a first class citizen, it no longer matters as the industry has moved on to the next big thing as a center for innovation.
The reason this happens is because at the heart of the matter anything that everyone might want to be a producer/server will only retain its position if it has a user experience that is unique and monetizable. Eventually, one of those consumers will also become a competitor at being a server. Things then blow up.
Everyone that wants to be a consumer/client will be trying to consume *all* the other servers out there. They will, however, always be missing one important server, the leader who is busy trying to also become the consumer/user experience. Consumers who rely on everyone else being their server are in for a surprise when they see the lack of motivation to only be a server. Every enterprise customer, for example, will always be fighting to get one vendor to "open up". See how identity/security have evolved. There’s adverse selection in that the second and third-ranked producers and consumers often sign up eagerly for the middleware API in hopes of gaining distribution and/or traction.
On the whole, HTML followed this path. Everyone thought all the UI would just converge to standard HTML and consume XML from servers (or some variety of that). What happened though was that all the data people wanted to build their own user interface to maintain control of their data/server/service. And on top of that the definition of HTML took on many vendor specific implementations. No one directly monetized browsing (some even de-monetized it) while it took 15 years to get to implementations that reached 90% feature compatibility.
Why is this? The biggest challenge with middleware is that for it to be successful and not stifle innovation middleware needs to be the sum of all the capabilities that it chooses to integrate. Middleware always starts off simple because it always starts off in the earliest days of new platforms. The platform is just simple so it is easy to envision middleware. As mentioned that is when demand for middleware is the highest because uncertainty is the highest.
In 1989 no one was sure if Windows would work and if you were to pick up any computer industry press it was filled with evaluating new products based on which platforms they worked on. I spent the first 3 years of my career trying to make Windows, DOS, Mac, OS/2 apps all the same by building middleware. It was not difficult to write an abstraction layer for the 150 or so APIs that made up the core experience of each of those operating systems. I literally knew them, the error codes, the parameters, and more by memory. I still do. But that is a single point in time. Today iOS has 250,000 APIs. AI has infinite APIs. See this post for more on cross-platform.
I get it the excitement. The key realization I came to and talked about at the first Win32 Developer Conference when Windows 32-bit was announced was that to be great at working across all the platforms that were interesting, a toolset/framework needed to be a superset of all the capabilities of those platforms. To build a superset meant that building successful middleware required a development team the size of all the other development teams. I also knew how fast Windows had grown in just 3 years since Windows 3.0 and how many people were working on expanding it.
Now everyone always has their favorite example of when this works or how it worked for them. Games commonly get talked about as following a great model. Except games integrate poorly with every host they run on. Game runtimes in effect create a purpose-built OS for running games and offload a vast amount of work to game developers.
A cleaner example is database connectivity. In the world of structured data everyone wants to be free of Oracle in the enterprise. But there has never been a production API that could easily “choose” which database to use. This is wild when you think about it because SQL data is extremely well-defined. But in the real world, the performance characteristics for any non-trivial products using SQL vary depending on how Oracle or any other database might have been implemented. While the semantics might be the same, the implementation was different.
Anyone who has build cross-platform mobile applications knows how much Android and iOS have diverged, and they started from a huge and complex API that was already difficult to make cross-platform. And every web developer knows the ins and outs of browsers, even after Microsoft converged on Chromium. Meanwhile everyone from Oracle to Nvidia to Apple to Google wake up every day to make the job of making software work across these platforms with middleware even harder. It is literally the business strategy.
The other side of this is the consumer side, that is the side of the equation that wishes to present their product as integrating with all other products. This always seems benign enough. Who would not want to be able to pull data from every system into Slack or Notion or even Excel? Everyone would.
But there is a challenge with that in that the transformation from the user experience and data semantics of that tool to those generic tools that everyone uses all day is lossy. What does it mean to “use Excel to analyze Workday” or “use that applicant tracking system with Slack”? These integrations often make for good demos but the edges quickly show. Data can be viewed but not modified. The product can add new capabilities but the integration experience fails to show them off, even when that might be required. Very quickly what seems like an enormously customer-friendly solution if you’re Slack of Excel turns into a nightmare if you’re Workday, Salesforce, or something else. In fact much like the platform vendors who wake up making it harder for middleware to commoditize them, these application providers wake up every day trying to get people to stay in their tools and see all the capabilities.
This is why even when middleware works, the economics aren’t there. Or when it works, there’s always a set of key players—providers or consumers—that aren’t participating because they want to be “on top” and have the market power and customer base to do so. For every Oracle there’s a Microsoft SQL Server trying to be more open and win that way. And there’s always the open source alternative being used in large numbers but less so at massive scale (always the MySQL+Oracle strategy anyway).
All isn’t lost. The key reason that middleware can win and become the standard is when a company solves the middleware problem so well that it becomes the platform itself. In a sense it rises above being in the middle and becomes the actual platform. There are two examples which let me circle back to how I got the the (1) and (2) at the very start when it comes to how MCP can be a success.
It is possible for middleware to become the platform and win, but win hearts and minds but not the economics. Ultimately that is what happened with Google Chrome and browsers (at least for a “generation”). One can debate the economics and whether having that default search engine and cookie handling and so on had economics but there’s no debating there are no direct economics. The browser remains middleware. Unless you use a Chromebook, you run the browser as middleware on iOS, Android, Mac, Windows, and every other device. Google retains outsized influence on the direction browsers will go but also because it lacks full penetration across devices developers will be less likely to adopt new features. Winning isn’t so great sometimes.
It is possible for middleware to win and include everyone but one important vendor. That is what happened with identity and access management (“directory”). Okta became the market leader in a category that started off as middleware. They did so by solving the problem of integration even as the then leader, Microsoft with Active Directory (AD), refused to participate at every step. As it turns out Microsoft’s history at winning with AD played an important part of failing to recognize the importance of Okta to customers and the very need it solved.
Briefly, Microsoft “woke up” to the power of the directory when Erich Schmidt made a bet while he was CEO of Novell (before Google). Schmidt posited—based on doubt on his experience at Sun in the Unix era—that the PC networks will need a directory. Microsoft saw that and reacted by expanding AD into a competitive position. Because Novell was losing the server market, Microsoft’s AD was able to win by being part of the server market. Netscape then came along and pioneered an open source academic project, LDAP, in an effort to provide an Internet scale directory. While AD was woefully inadequate for the scale LDAP could manage, AD was adept at managing enterprise PCs (servers and printers too) and ended up winning again. The fact that Microsoft won both these battles with AD in a sense gave it the confidence to assume that everyone would write special code in their enterprise SaaS apps to integrate with AD. But that code was complex, Windows-centric, and kind of annoying to deal with because of how it was architected. Okta on the other hand subsumed that complexity and made it easy to do the one thing customers to do which was maintain one identity across all their enterprise products and keep it in sync with what they believed was the ground truth, AD. Ultimately Okta did this so well that it became the ground truth. So in an “everyone but Microsoft” strategy, the real winner was the company that did a massive amount of work to subsume what Microsoft seemed unwilling to do.
There are other examples and I’m sure people will always quibble or debate details. Having lived through the middleware world for so long, I admit to feeling the pattern rather quickly.
One final word about middleware APIs is unfortunately a weird way to end but an important point. Vendors pledging support for middleware might do so at the start with legitimate and sincere intentions. But over time the negatives of either being easily replaced or having their user experience and feature innovations ignored end up making the commitment to middleware look like a pretty poor investment.
Even well-placed intentions end up meeting market realities. Fear of commoditization, customer churn, or inability to innovate are powerful motivators away from middleware.
—Steven
This was originally a long tweet. It has been expanded and edited here.