· Kevin Swiber · 6 min read

🤝 MCP: The Ultimate API Consumer (Not the API Killer)

AI API MCP
On this page

APIs are the connective tissue of our digital world. They quietly power everything from your morning weather check to your evening streaming binge—invisible yet essential to our connected experiences. Now there’s a new protocol reshaping the landscape: Model Context Protocol (MCP). And as with any technological shift, misconceptions and hot takes are spreading faster than accurate information.

Debunking the doomsday predictions

Let’s be honest with ourselves. When we first see a new technology protocol, our self-serving bias kicks in. Those with API investments fear disruption; newcomers hype revolutionary change. Both miss the symbiotic relationship at play.

Some headlines suggest MCP could spell the end of APIs as we know them. These aren’t just wrong—they fundamentally misunderstand how MCP actually works. It’s like claiming highways will kill cars, rather than give them somewhere to drive.

What is MCP, really?

MCP (Model Context Protocol) creates a standardized way for AI assistants to interact with tools, services, and data sources. Think of it as a spiritual successor to LSP (Language Server Protocol), which transformed how IDEs work with programming languages.

Remember our 3-tier architecture discussions? MCP represents another evolution in that journey. Instead of terminal emulators connecting to mainframes, we now have AI assistants connecting to digital services.

graph LR
    subgraph "Application Host Process"
        H[Host] --> C1[Client 1]
        H --> C2[Client 2]
        H --> C3[Client 3]
    end

    subgraph "Local machine"
        C1 --> S1[Server 1<br>Files & Git]
        C2 --> S2[Server 2<br>Database]
        S1 <--> R1[("Local<br>Resource A")]
        S2 <--> R2[("Local<br>Resource B")]
    end

    subgraph "Internet"
        C3 --> S3[Server 3<br>External APIs]
        S3 <--> R3[("Remote<br>Resource C")]
    end

This diagram reveals the core insight: MCP is built to consume APIs, not replace them. The host (an AI assistant like Claude) communicates with clients, which in turn communicate with servers that access various resources. Beep boop.

It’s APIs all the way down

The relationship between MCP and APIs is symbiotic, not adversarial. MCP servers are essentially specialized API clients with a standardized interface—they’re not replacing APIs, they’re consuming them en masse.

Companies like Dylibso with their mcp.run platform are generating MCP servers directly from OpenAPI definitions. This is like taking existing API descriptions and magically creating MCP-compatible interfaces for AI assistants.

Sounds suspiciously like API promotion, not replacement, doesn’t it?

The security elephant in the room

Let’s hold on to our britches, because we’re getting to the good part: security concerns. They’re very real, but they’re not entirely new—they mirror issues we’ve seen with LSP servers, with one critical difference: blast radius.

While an LSP vulnerability might only impact your development team, MCP affects everyone using AI assistants. Imagine a bad actor hijacking the CEO’s AI assistant—suddenly they have access to sensitive communications, strategic planning, and more. That darn application server strikes again, but now it’s personal.

Most AI hosts ask you to approve every tool use, but there’s a problem: there’s not enough information for users to make truly informed decisions:

  • Is the tool accessing the network?
  • Which domains is it contacting?
  • What data is being sent or received?

The MCP community recognizes these challenges. Their roadmap prioritizes several security-focused initiatives:

  • Authentication & Authorization: Adding standardized auth capabilities
  • Service Discovery: Defining how clients can safely discover MCP servers
  • Stateless Operations: Exploring serverless environments

I foresee an emerging world of MCP server repositories combining social proof with automated security scans—a sort of “App Store” for MCP capabilities.

Update: Since writing this post, the MCP specification has added support for OAuth 2.1 in remote MCP server connections. See my follow-up post, “OpenAI Embraces MCP: The Protocol Era of AI Has Arrived”.

API Gateways: Still very much in the game

Far from making API gateways obsolete, MCP reinforces their importance. Remote MCP servers use transport protocols that gateways already support. Local MCP servers need to call APIs that sit behind those same gateways.

API gateways provide critical functionality that MCP needs:

  • Authentication and authorization
  • Rate limiting
  • Quota management
  • Traffic monitoring
  • Security policy enforcement

MCP doesn’t replace this infrastructure—it relies on it. If anything, the rise of MCP means more API traffic, not less. Whatever decisions we make, let’s make them deliberately.

The patterns emerging in the wild

I’m seeing two primary patterns for how MCP servers interact with APIs:

  1. Aggregator pattern: MCP servers bundling multiple API integrations, acting as centralized access points.
  2. Client facilitator pattern: Local servers connecting to centralized services for allow-listed APIs, establishing direct connections to remote API servers.

Both patterns involve calling APIs—lots of them. This is distributed systems in action, taking advantage of the network.

The new API-First frontier

Instead of worrying about MCP replacing APIs, we should be excited about the new design possibilities. MCP represents an evolution in how we interact with APIs, not their replacement.

We’re moving from thick clients and traditional API consumers to AI-mediated API access. This transition creates fascinating challenges for API producers:

  • How do we design APIs that are AI-friendly?
  • What documentation patterns work best for AI consumption?
  • How can we ensure our APIs work well with MCP-enabled tools?

The API ecosystem isn’t disappearing—it’s expanding into new territory. And as with any frontier, those who adapt quickly will thrive.

Design with intention

Success emerges from collaboration between multiple disciplines. With MCP, we should make our intentions explicit:

  1. APIs should be designed with AI consumers in mind
  2. Documentation should cater to both human and AI readers
  3. Patterns like materialized views may become more valuable for AI consumption
  4. Security concerns must be addressed proactively

Wrapping up

When someone tells you MCP will kill APIs, you can confidently respond: “Actually, it’s APIs all the way down.” MCP is good business for API management. It requires more APIs, not fewer.

The future isn’t about MCP versus APIs—it’s about how they work together to create more powerful, accessible experiences. As we know, transient technology, as it turns out, may never die.

What are your thoughts on MCP and its relationship with APIs? Reach out and let me know!

Looking for more insight into API strategy? Check out my other posts on API-First survival, API observability, and redefining the 3-tier architecture.

If you have more thoughts on the coming wave of technology, reach out to me on LinkedIn: https://linkedin.com/in/kevinswiber.