Is MCP Just Another API Abstraction?

The Network Automation Forum’s AutoCon 4 event was in Austin, Texas, the week of November 17 to 21, and if you’ve never been, it’s one of those rare conferences where the conversations are honest. There’s very little posturing. People show up with war stories, half-finished ideas, and the kind of curiosity you only get when you’ve been burned by enough “next big things” to become suspicious of all of them.

That was exactly the mood I walked in with when I presented: “Is MCP just another API abstraction?”

Because if you’ve been around infrastructure long enough, you know how this goes. New protocol. New standard. New promise that this time integration will be clean, flexible, and future-proof. And then, six months later, you’ve got twenty half-supported implementations and another pile of glue code that becomes your problem to maintain.

So I came into MCP skeptical. I didn’t want another abstraction layer. I wanted to prove we could just keep using APIs the way we always have.

What surprised me is that the more I tried to avoid MCP, the more I kept finding the same thing:

MCP isn’t interesting because it wraps APIs. It’s interesting because it changes the integration math and the operational model for AI-driven infrastructure.

And if you’re about to bring agents into your environment, that matters.

Thesis: MCP Is Not “Better APIs,” It’s a New Integration Contract for Models

Let’s start with the simplest version of the debate.

The “API wrapper” argument

Most MCP servers you’ll see today look like wrappers. They map endpoints to tools. They expose a list of actions. They turn a REST API into a set of callable functions. That’s real, and it’s why many people dismiss MCP immediately.

The “something different” argument

MCP’s design assumptions aren’t “how do humans integrate systems?” They’re “how do models discover, reason about, and safely use tools?” It is a protocol shaped by the constraints of LLMs: context limits, tool ambiguity, non-determinism, and session continuity.

If you evaluate MCP using API-era expectations, it looks redundant.

If you evaluate it using AI-era constraints, it looks… inevitable.

The Real Problem: The N × M Integration Explosion

Here’s the shift that’s coming fast, whether we like it or not:

• You don’t have one “AI model.” You will have many.
• You don’t have one tool system. You have dozens, and they change constantly.
• You don’t have one integration point. You have an expanding mesh of models, tools, and environments.

In the old world:

• One app integrates with one API.
• Engineers write explicit calls.
• The contract is stable and deterministic.

In the AI world:

• Multiple models need to interact with multiple tools.
• Tool selection happens dynamically.
• The system is probabilistic.
• Your integration surface grows continuously.

That’s where the integration math bites you.

Without a standard, you get N × M: every model needs bespoke integration to every tool.

With MCP, the aim is to shrink that to N + M: models become MCP clients. Tools become MCP servers. The contract becomes shared.

This is the moment MCP stops being “just abstraction” and starts being infrastructure.

Why “Just Use OpenAPI” Doesn’t Solve It

A common response is: “Why do we need MCP at all? We already have OpenAPI.”

Fair question. I asked it too.

Here’s the problem: OpenAPI is a spec for describing APIs to developers. It’s not a protocol for managing how a model uses tools.

If you take an OpenAPI spec and dump it into an agent, you tend to run into two failure modes:

1. Tool overload

Instead of exposing a small set of curated capabilities, you expose every endpoint. That can be hundreds of tools.

Models don’t reason well when the action space is huge. They start guessing. They call the wrong thing. They waste tokens trying to narrow it down. And then you write more prompts to fix it.

2. “Endpoint thinking”

OpenAPI encourages thinking in endpoints:

• get this
• update that
• validate this
• post that

What you actually want for AI isn’t endpoint thinking. You want intent thinking:

• check compliance
• verify drift
• stage a change
• validate a golden config
• summarize risk
• propose remediation

The model shouldn’t have to assemble an outcome from ten raw endpoints if your automation platform already understands the domain logic.

MCP’s Core Shift: From Endpoint Exposure to Capability Exposure

This is the technical hinge.

The shallow version of MCP is this: “Let’s expose every endpoint as a tool.”

That’s why people say it’s just wrappers.

The deeper version is this: “Let’s expose meaningful operational capabilities, with enough context for a model to use safely.”

That means MCP becomes a semantic contract, not a mechanical one.

And this is where the MCP primitives matter, because MCP doesn’t just expose “tools.” It gives you a structured way to expose capabilities as:

• Tools (actions)
• Resources (read-only contextual data)
• Prompts (guided templates, rules, constraints, operational patterns)

That combination is a big deal.

Because in agent-driven systems, the problem isn’t “can I call the API?”

The problem is:

• Do I have enough context to make a safe decision?
• Do I know what this tool does?
• Do I know when not to use it?
• Do I know what success looks like?
• Do I have guardrails, constraints, and semantics?

MCP is built around the assumption that a model needs help answering those questions.

REST vs MCP Isn’t a Fight. It’s a Layering Change.

This is where most debates get stuck.

People ask: “Is MCP replacing REST?”

No. REST is foundational.

But REST was architected for a world where:

• the client is a deterministic program
• the human is responsible for correctness
• the API contract is explicit

MCP assumes:

• the client might be a model
• “correctness” is probabilistic unless you constrain it
• discovery + selection are first-class requirements
• sessions matter because tool use is iterative and conversational

REST is still what your systems run on. MCP is what your models use to interact with those systems. Different layer. Different contract. Different assumptions.

What I Mean When I Say “Session Matters”

This is one of the most underappreciated points, and it’s why MCP feels “bigger” than a wrapper.

Traditional API calls are stateless. You send a request, you get a response, and the system forgets you exist.

MCP’s interaction model expects something more continuous:

• the model discovers capabilities
• the model uses context (resources)
• the model selects tools
• the server can stream updates, logs, context back
• the model may refine, retry, and iterate in-session

That maps much more naturally to how agentic workflows actually behave.

If you’ve experimented with tool-driven agents, you know exactly what I mean: the interaction is never one clean call. It’s a loop:

• decide
• act
• observe
• refine
• act again

MCP is designed around that loop.

The Trap: MCP Servers That Just Recreate Your API Surface

Here’s the most practical part of the talk, and it’s where I want people to spend time if they’re building.

If your MCP server looks like:

• get devices
• get config
• update config
• validate config
• push config

You haven’t really built an MCP server. You’ve built a tool list.

And the model is now forced to become an integrator.

In infrastructure, that’s a dangerous role for something probabilistic.

A better approach is capability-level exposure:

• “check compliance for these devices against this policy”
• “compare running config to golden intent”
• “summarize drift and risk”
• “stage a change and generate rollout plan”

The point is to move the complexity back into deterministic automation, where it belongs. Models should reason about decisions and intent. They should not be stitching together raw API primitives.

What This Has to Do with Infrastructure Orchestration (& Why It’s Not Just AI Hype)

If you’re thinking, “okay, but this is still AI land,” I get it.

Here’s why it’s not hypothetical:

As soon as you introduce AI into operations, you create a demand for:

• more integrations
• faster tool onboarding
• standardized tool semantics
• consistent context delivery
• safe execution patterns
• governance

MCP doesn’t solve governance by itself. But it gives you a consistent interface to enforce governance around.

That’s the real point for infrastructure teams.

Because if MCP becomes the standard interface between models and tools, then the enforcement layer becomes viable:

• what tools are exposed
• to whom
• under what conditions
• with what guardrails
• with what audit trail

And this is where it starts to connect directly to orchestration platforms like Itential, because orchestration is already designed to:

• centralize execution
• enforce policy
• validate changes
• control lifecycle
• manage drift
• integrate across domains

MCP becomes another entry point to that same operational backbone. Not a replacement for automation platforms. A way to let models interact with them safely.

So, Is MCP Just Another API Abstraction?

If all you do is wrap endpoints, yes.

But that’s like calling Kubernetes “just a wrapper around Linux.” It’s technically true and completely missing the point.

MCP is better understood as:

• A standard interface for tool discovery and usage
• A way to separate intent and capability from raw endpoints
• A protocol shaped by model constraints, not developer convenience
• A mechanism to reduce integration sprawl in an AI-enabled ops world

And that’s why I stopped dismissing it.

Because even if you don’t love the idea of “yet another thing,” the trajectory is clear: AI is becoming an operator in your environment. And operators need tools.

The question is whether you want tool integration to be bespoke, brittle, and model-specific… or standardized, governable, and scalable.

That’s why MCP matters.

Learn More

To watch my full talk at AutoCon 4, check it out on-demand here or watch it below. Let’s keep the conversation going.