For a talk I’m giving next week to car dealers on how AI platforms can control different systems, I started putting together a demo using Vercel’s AI SDK. I started writing a few defined some prompts and tools for the demo to connect out to external services. However, what if the external services defined prompts and tools instead? That’s the pitch for MCPs.
What Are MCPs?
Model Context Protocols (MCPs) are an emerging way to standardize how AI systems interact with external tools, data sources, and services. Instead of writing bespoke integrations for every API, MCP aims to define a consistent interface that models can use to discover capabilities, read structured data, and perform actions.
In practice, an MCP server exposes tools and resources in a way that an AI model can understand and invoke. Rather than building custom glue code for each service, you expose functionality through MCP and let the model handle orchestration.
Web 2.0 and Mashups
To understand why this feels familiar, it’s worth going back to the Web 2.0 era. This was the age of platform APIs. Companies like Twitter, Flickr, Google Maps, and Facebook exposed REST APIs that let developers build on top of their platforms. The idea was that opening access would create ecosystems.
Developers built “mashups”. These were applications that combined multiple services into something new. As an aside, I was building these kinds of projects at the time. The first version of sixwordstories.com pulled photos from Flickr, let people write six-word stories inspired by them, and then posted those stories with the attributed photo to Twitter.
It was simple, composable, and entirely dependent on open APIs. You didn’t need permission to build something interesting. You just needed endpoints.
Where Web 2.0 Went Wrong
But all good things come to an end. The problem with Web 2.0 wasn’t technical, it was economical. As platforms matured, they realized their APIs weren’t just developer tools, their APIs were strategic assets. Open access meant that third-party apps could capture user relationships and platform value could leak out to possible competitors.
So the incentives changed. APIs became more restricted. Rate limits tightened. Access required approvals. Entire categories of apps were shut out. Twitter is the most obvious example, but it wasn’t alone.
The open ecosystem that enabled mashups slowly gave way to controlled platforms. The dream of “everything is an API” kind of died.
The Pattern Repeats
MCPs are arriving with a similar promise of seamless interoperability between systems, powered by a shared protocol. I don’t think MCP is going to be any different. The same incentives still exist. Companies still care about control.
If MCP becomes a primary way that AI systems access data and perform actions, it becomes a critical control point. That means the same pressures will apply: limit access, prioritize first-party experiences, and protect competitive advantages.
If you’re building a project that depends on MCP capabilities, it’s worth thinking carefully about what happens if that access changes. Because it might. The history of open APIs suggests that openness is often temporary, shaped by incentives that can shift over time. So it should not just be about what MCPs make possible in your project, it should be about what your project can still do without them.