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

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.

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.

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.

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

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:

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.

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

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.

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

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.

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”

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

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.

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