MCP

MCP — Model Context Protocol — is the protocol that emerged to let AI agents and assistants call tools and APIs, and it’s the technology I’ve had the most pointed and complicated reaction to in recent years. MCP gives an AI assistant a standardized way to discover and invoke capabilities — an MCP server exposes tools that an agent can call, which in practice usually means wrapping existing APIs so that AI assistants can use them. The promise is real: as agents become significant API consumers, they need a way to find and call capabilities, and MCP provides one. But I’ve been one of the more skeptical voices about MCP, not because the problem it solves isn’t real, but because of how it solves it and the business and political dynamics around its rapid, hype-driven adoption. My view of MCP is that it’s a valid tactical response to a real need, wrapped in a lot of noise that obscures what’s actually happening.

My core technical critique is that MCP doesn’t respect the web the way it should, and I made that argument pointedly in 2025. I wrote about MCP under the framing of controlling the protocol, and my concern was that MCP reinvents things HTTP and OpenAPI already do well — it doesn’t fully leverage HTTP’s semantics, its early versions notably lacked proper authentication, and it doesn’t carry the semantic richness that a well-designed OpenAPI definition provides. From the perspective of someone who’s spent fifteen years arguing that we should use the web properly, MCP looked like another case of building a new protocol layer that ignores the hard-won lessons of HTTP. The missing authentication in early MCP especially troubled me — I wrote that no-auth on initial MCP wasn’t a bug, it was a feature, in the sense that frictionless, unauthenticated access to enterprise resources was exactly what made MCP spread fast and exactly what should have raised alarm. The technical shortcuts that made MCP easy to adopt are also the ones that make it risky.

The “it’s all APIs, nothing has changed” framing is my deepest and most consistent position on MCP, and it’s the lens I’d most want people to use. I wrote in 2026 that agents are just APIs, nothing has changed — and MCP is the clearest illustration. An MCP server is, almost always, a wrapper around existing APIs. The agent calling through MCP is still ultimately making API calls; the capability being exposed is still an API capability; the authentication, rate limiting, governance, and reliability concerns are still API concerns. MCP is a new envelope, not a new substance. When I position MCP alongside HTTP APIs, GraphQL, and event-driven patterns, as I did in 2025, I’m making the case that MCP is additive — another interface pattern in the diverse toolbox — rather than a revolution that replaces everything that came before. The agent is the newest kind of consumer, MCP is the newest kind of interface for that consumer, and underneath it all is the same API economy that has always existed. Nothing fundamental has changed; the consumer changed.

The business and political critique is where I’ve been sharpest, because the MCP hype obscures real concerns. I wrote in 2025 that adopting MCP is a bad idea, citing the database-exposure risks, the complexity, the costs, and the resource consumption of the AI systems behind it — and that the business realities of API automation, the access, the pricing, the terms of service, get ignored in the MCP excitement. I wrote about the noise versus the voice — that MCP and the AI specification frenzy are largely noise that distracts from the actual business alignment work (APIOps cycles, Arazzo workflows, overlays) that delivers value. There’s a power-grab dimension too: MCP, like every specification before it, is partly a play for control of the AI-to-API interface layer, and the company that owns the dominant protocol owns a strategic position. My skepticism wasn’t Luddism; it was the recognition that the hype around MCP served investor narratives and vendor positioning as much as it served genuine technical need.

And yet I’ve come to a more empathetic and pragmatic place, which is the honest evolution of my view. I wrote in 2025 that conversations with enterprise product and engineering teams gave me more empathy about this moment — because enterprises genuinely want to build on their existing API investments to meet the AI moment, and MCP is a tactical way to do that. I acknowledged that MCP is a valid tactical response: it’s simpler than the alternatives, it gets the job done, and it lets organizations expose their existing APIs to agents without a massive new investment. The MCP server for Microcks mocking and testing that I supported in 2026 is an example of MCP doing real, useful work — bringing API testing capabilities to agents in a sandbox. My position matured from pure skepticism to a more nuanced view: MCP is technically imperfect and surrounded by hype, but it’s a reasonable pragmatic bridge for organizations that need to make their APIs available to agents now, as long as you understand it for what it is.

The work I’ve actually done with MCP reflects this pragmatism, and it’s where my real position lives. I built OpenAPI extensions to generate MCP servers, because if you have a good OpenAPI definition, you should be able to generate the MCP interface from it — keeping OpenAPI as the source of truth and treating MCP as a derived artifact. I catalogued every provider in my network shipping an MCP server, finding nearly 200 of them, because tracking the real adoption matters more than the hype. And I’ve worked on the harder, unsolved problems MCP creates — seeing MCP, the challenge of discovering, documenting, and governing MCP servers across an enterprise, which is the same discovery and governance problem I’ve worked on for APIs all along, now applied to the MCP layer. This is the through-line: MCP doesn’t escape any of the fundamental challenges of APIs. It still needs discovery, still needs governance, still needs authentication, still needs to be generated from a source of truth, still needs to be reliable. The agent era’s MCP servers have all the same problems and all the same solutions as the APIs underneath them, because they are the APIs underneath them. My considered view of MCP is that it’s a real, useful, tactically valid technology that should be generated from OpenAPI, governed like any API, and understood without the hype — a new interface for a new consumer, sitting on top of the same API economy that’s been here all along, solving a genuine problem in an imperfect way that the industry will refine over time, the way it has refined every protocol before it.

Guidance

API Learnings

APIs

API Governance

API Solutions

API Discovery

API Building Blocks

API Evangelist LLC

References

Guidance Details

Explore more

Discover APIs