MCP vs APIs: The Real Story Behind the Controversy

Over the past few weeks, the MCP backlash hit critical mass. Some companies publicly moved away from MCP toward direct APIs. YC CEO Garry Tan called MCP a "context window eater" and said, bluntly, "MCP sucks honestly." Twitter threads. Hot takes. Tribal lines drawn.

But here's the thing about tribal warfare: it makes for terrible engineering decisions. While the discourse raged, MCP quietly crossed 8 million server downloads, 97 million monthly SDK downloads, and Gartner predicted 75% of API gateway vendors would add MCP features by end of 2026. Google, OpenAI, and Microsoft all integrated it into their flagship products.

Something doesn't add up. Either the entire industry is collectively delusional, or the critics are missing context.

The answer, as usual, is more nuanced than either side wants to admit. Let me walk through the specific criticisms, what they get right, and what they get wrong.

Myth #1: "MCP Eats Your Context Window"

Garry Tan's critique was specific: MCP "eats too much context window, and you have to toggle it on and off." The numbers behind this concern are real. Just two MCP tools can consume roughly 20% of a context window. Tool schemas, descriptions, and parameter definitions add up fast.

That sounds alarming until you look at where context windows actually are in 2026.

Claude operates at 200K+ tokens standard, with million-token contexts available on Opus. Gemini offers 2 million tokens. Twenty percent of two tools sounds devastating when you imagine a 4K token window from 2023. At 200K tokens, that's 40K tokens. Meaningful, but manageable. At a million tokens, it's noise.

More importantly, production deployments don't load every tool for every task. Selective tool loading is standard practice. You scope the available tools to the task at hand. An agent handling customer support doesn't need your deployment pipeline tools in its context. This is basic engineering hygiene, not a fundamental protocol flaw.

The strongest counterargument is empirical. Block has 4,000 of its 10,000 employees actively using MCP-powered agents across 15 job roles. Four thousand people. In production. Across diverse workflows. If context bloat was killing their efficiency, they would've stopped months ago. They didn't.

Context windows are also getting cheaper and larger every quarter. This is a shrinking problem, not a growing one. Optimizing for today's context limits while ignoring tomorrow's trajectory is a mistake I see engineers make repeatedly.

The honest concession: for cost-sensitive, high-volume production workloads where every token directly impacts your bill, yes, be deliberate about tool loading. Monitor your context usage. Prune aggressively. But that's optimization work, not a death sentence for the protocol. Every production system requires optimization. That's not news.

Myth #2: "Just Use APIs Directly"

The most common criticism I hear from experienced engineers goes something like this: modern LLMs already know how to call popular APIs. Why add an abstraction layer? Just define your endpoints, give the model the docs, and let it work.

This argument has the same energy as "just write assembly." Technically correct. Strategically wrong.

The core issue is the M-times-N problem. Without MCP, connecting M AI models to N tools requires M times N custom integrations. Each model needs bespoke code for each tool. Each update to either side risks breaking the integration. With MCP, you build one server per tool. Every MCP-compatible client (Claude, Gemini, ChatGPT, Cursor, VS Code, your internal tooling) connects to it immediately. Build once, run everywhere.

Google Cloud called this "USB-C for AI." That analogy is precise. Before USB-C, every device had its own charger, its own cable, its own connector. Technically, the old chargers worked fine. The standardization value wasn't in any single connection being better. It was in eliminating the combinatorial mess.

Then there's runtime discovery. MCP's tools/list endpoint lets agents discover available capabilities dynamically. An agent can inspect what tools exist, what parameters they accept, and what they return, all at runtime. With raw APIs, the developer must hardcode which endpoints to call and how to call them. For autonomous agents that need to reason about available tools and select the right one for the task, runtime discovery isn't a nice-to-have. It's transformative.

Seventy percent of large SaaS brands now offer remote MCP servers. Stripe, GitHub, Salesforce, Notion. They aren't building these for fun. They see the integration leverage.

One argument I see repeated is that MCP is "full circle": OpenAPI specs to MCP servers and back to API calls. This misunderstands the abstraction layer. OpenAPI describes endpoints for developers. MCP describes capabilities for AI agents. These are different audiences with different needs. An OpenAPI spec tells a developer "here's the HTTP method, path, and request body." An MCP tool description tells an agent "here's what this capability does, when to use it, and what it needs from you." It isn't circular. It's a higher-level abstraction purpose-built for how agents reason.

Myth #3: "MCP Security Is a Disaster"

This one requires more care because the critics have legitimate points.

Prompt injection attacks against MCP servers were documented in April 2025 research. Permission models were too loose. Authentication was poorly defined in the initial spec. I wrote about the broader agent security landscape earlier this year, and the concerns apply here too. These are real vulnerabilities, not theoretical hand-wraving.

But "the early spec had security gaps" isn't the same as "the protocol is fundamentally insecure."

Every major protocol went through this. OAuth had redirect vulnerabilities that took years to close. Early HTTPS implementations were routinely broken. APIs themselves, the supposed safe alternative, have had decades of auth failures, key leaks, SSRF attacks, and injection vulnerabilities. Security maturity is a process, not a launch-day checkbox.

MCP security has been evolving rapidly. Remote MCP servers do not run on the user's local machine, eliminating an entire class of attacks. LLM harnesses provide execution boundaries. Authentication primitives are now built into the protocol spec. And critically, the Linux Foundation now governs MCP as an "open, neutral, and community-driven" project, meaning security gets broad community scrutiny rather than depending on a single company's attention.

Healthcare organizations are deploying MCP in production. These are HIPAA-regulated environments where security failures have legal consequences. If the protocol were fundamentally broken, these deployments wouldn't exist.

The honest take: MCP security is immature but on a clear improvement trajectory. The concerns are a call to action for the ecosystem, not evidence of a fatal flaw. If you dismissed every protocol with early security issues, you'd still be using FTP.

Myth #4: "Companies Are Leaving, So MCP Must Be Dead"

A few companies have publicly moved away from MCP in favor of direct APIs. This is being cited as proof that the protocol is a dead end.

It isn't. It's proof that different products have different needs.

If you control your entire stack, own the toolset, and have a narrow, well-defined workflow, you don't need dynamic multi-tool discovery. A direct API is simpler, faster, and perfectly appropriate. Nobody is arguing otherwise.

But most teams don't live in that world. MCP shines in heterogeneous, multi-vendor environments where you do not control every tool and need agents to discover and orchestrate capabilities at runtime. Enterprise environments. Developer toolchains. Platforms integrating dozens of third-party services. A company choosing APIs for their closed system tells you nothing about MCP's value in open, multi-tool architectures.

Meanwhile, look at who is betting on MCP. Google added MCP support to Gemini in April 2025. OpenAI added it to ChatGPT and their API in March 2025. Microsoft integrated it into Copilot and Azure OpenAI. The three largest AI companies on the planet are building around MCP. The "MCP is dead" narrative requires ignoring all of them.

The real story isn't "MCP is dead." It's "MCP isn't for every use case." That's how technology works.

The Developer Experience Reality Check

I want to be honest about where MCP genuinely falls short today, because dismissing real gaps undermines credibility.

Documentation has historically focused on Claude Desktop and local development, not production deployment patterns. Standard error-handling conventions are still emerging. Server state management needs better tooling. Versioning and lifecycle management are immature compared to REST API ecosystems that have had fifteen years to develop these patterns.

These are real gaps. They cause real friction for teams trying to ship production systems.

But the picture isn't all gaps. Cross-platform portability works: build one MCP server, run it in Cursor, VS Code, Claude Desktop, cloud services. The protocol offers rich primitives beyond just tools: Resources for exposing files and data as context, Prompts for pre-packaged interactions with arguments, and Authentication for user-specific scoping. Critics who assume MCP servers only provide tools are working with an incomplete mental model of what the protocol actually offers.

The ecosystem is growing fast. Remote MCP servers have increased 4x since May 2025. This is the trajectory of a rapidly maturing protocol with growing pains, not a fundamentally flawed design heading toward irrelevance.

When APIs Actually Win

Here is where I part ways with the MCP maximalists. APIs are genuinely better for several workload patterns, and pretending otherwise helps nobody.

Predefined static workflows. When you know the exact sequence of operations and it will not change, APIs are simpler and more efficient. No schema negotiation. No discovery overhead. Just call the endpoint.

Bulk data operations. ETL pipelines, batch processing, analytics workloads. Direct API calls are more performant when you are moving large volumes of data through well-defined transformations.

Latency-critical systems. No protocol overhead, no tool schema exchange, direct HTTP requests. When milliseconds matter, removing layers is the right call.

Simple app-to-app communication. Microservices, webhooks, basic automation where no AI reasoning is involved. MCP adds complexity with zero benefit here.

Cost-controlled high-volume operations. When you are processing millions of requests and every token on the bill matters, the overhead of tool descriptions is a real cost you should avoid.

The pattern is clear. APIs win when the workflow is known, static, and optimized for throughput. MCP wins when agents need flexibility, runtime discovery, and multi-tool orchestration. These aren't competing paradigms. They're complementary tools for different problems.

The Bigger Picture

GraphQL did not kill REST. It complemented it. Teams use GraphQL for flexible client-driven queries and REST for simple CRUD operations. Both coexist because they solve different problems well.

MCP and APIs will follow the same pattern. The emerging architecture is straightforward: MCP for agent-facing interfaces where discovery, orchestration, and multi-tool reasoning matter. APIs for system-facing interfaces where performance, reliability, and deterministic behavior matter.

Gartner predicting 75% of API gateway vendors will add MCP features by end of 2026 tells you where the market sees this heading. Not replacement. Integration. The gateway vendors aren't ripping out REST support. They're adding MCP alongside it.

The Clear-Headed Take

The March 2026 backlash is healthy. It forces the ecosystem to be precise about what MCP is for and what it is not for. Uncritical hype helps nobody. Neither does tribal dismissal.

The critics are right about some things. Context overhead is real and requires thoughtful management. Security is immature and needs continued investment. Developer experience has gaps that cause production friction.

But they are wrong about the big picture. MCP solves a genuine problem: the M-times-N integration mess. It enables capabilities that raw APIs cannot provide, like runtime tool discovery and agent-native interfaces. And it is being adopted by every major AI platform, not abandoned by them.

The best architectures in 2026 will not be MCP purists or API maximalists. They will use each tool where it fits. Static workflows get APIs. Agent orchestration gets MCP. The workload determines the tool, not tribal allegiance.

Next time someone tells you MCP is dead, ask them: dead for what use case?