Many recent discussions argue that MCP (Model Context Protocol) is nothing more than an additional abstraction layer that introduces unnecessary overhead. Some even claim that AI should simply call APIs directly.

At first glance, this sounds reasonable.

If an AI model can already invoke REST APIs or SAP RFCs, why introduce another protocol?

The answer is simple:

MCP was never designed to make APIs faster. It was designed to make enterprise AI systems easier to build, maintain, and scale.

Imagine an AI-Powered Goods Receipt Process

Consider a warehouse operator receiving a supplier’s delivery note.

Instead of logging into an ERP system, they simply ask an AI assistant:

“Can you verify whether this shipment can be received?”

The AI performs OCR on the document, extracts:

Vendor
Purchase Order Number
Material Number
Quantity

Then it checks the ERP system and responds:

“The purchase order exists, the vendor matches, and the quantities are correct. This shipment can be received.”

The operator confirms:

“Proceed with the goods receipt.”

The AI completes the transaction automatically.

This sounds straightforward.

But an important architectural question remains:

How should the AI communicate with the ERP system?

The Simplest Approach: Let AI Call APIs Directly

A common suggestion is:

AI
 │
ERP API

Provide the API documentation to the LLM, define the request schema, and let the model invoke the API directly.

Technically, this works.

However, enterprise environments rarely consist of a single system.

A typical enterprise AI platform may need to interact with:

ERP
Workflow Systems
CRM
Knowledge Bases
LDAP
Databases
Git Repositories
Ticketing Systems

Each system exposes different:

Authentication methods
Request formats
JSON schemas
Error handling
Versioning strategies

As more systems are connected, prompts become increasingly complex, and maintenance quickly turns into a significant challenge.

The Real Problem Isn’t AI—It’s Enterprise Complexity

Large language models are surprisingly capable of understanding APIs.

The real challenge lies elsewhere.

Enterprise systems constantly evolve.

ERP upgrades
API version changes
New authentication mechanisms
System replacements
Additional business rules

If AI agents communicate directly with every backend API, every infrastructure change potentially requires prompt updates, regression testing, and redeployment.

The maintenance cost grows rapidly.

MCP Solves a Different Problem

Instead of exposing backend APIs directly, MCP introduces a layer of business-oriented tools.

Rather than asking AI to execute:

BAPI_PO_GETDETAIL

The AI simply calls:

validate_receipt()

Or instead of:

BAPI_GOODSMVT_CREATE

It invokes:

create_goods_receipt()

The AI never needs to know whether the backend uses:

SAP RFC
REST
SOAP
SQL
Message Queues

These implementation details remain entirely inside the MCP server.

This separation dramatically reduces coupling between AI agents and enterprise systems.

Doesn’t MCP Add Another Layer?

Yes.

And that criticism is technically correct.

MCP introduces:

Tool invocation
JSON wrapping
Tool discovery
Request parsing

These operations inevitably introduce a small amount of latency.

However, consider the complete execution path of a typical enterprise AI workflow:

OCR processing
LLM inference
Database queries
ERP transactions
Network communication

The additional overhead introduced by MCP is usually measured in milliseconds.

Meanwhile:

LLM inference often takes hundreds of milliseconds—or even several seconds.
SAP RFC calls commonly take 100–500 ms.
Database queries and external APIs contribute far more latency than MCP itself.

From an overall system perspective, MCP typically accounts for only a tiny fraction of the total response time.

The Bigger Performance Issue Isn’t MCP

In practice, the biggest performance problem often comes from poorly designed tools.

For example, an ERP function may return hundreds of fields.

Yet the AI may only need:

Vendor
Material
Quantity
Status

Everything else consumes unnecessary context tokens.

A well-designed MCP server should:

Filter irrelevant fields
Simplify responses
Apply business rules
Return only information the AI actually needs

In many cases, a properly designed MCP implementation reduces overall token usage, leading to better performance despite introducing another architectural layer.

MCP Is More Than an API Wrapper

One of the biggest misconceptions is viewing MCP as another API gateway.

If an MCP server simply exposes every backend API as an individual tool, it provides little value.

For example:

BAPI_PO_GETDETAIL()

BAPI_PO_CHANGE()

BAPI_GOODSMVT_CREATE()

This merely mirrors the ERP interface.

A better design exposes business capabilities instead:

validate_receipt()

approve_purchase_order()

cancel_receipt()

Behind the scenes, a single tool may execute:

Multiple SAP RFCs
SQL queries
Workflow validations
Business rule evaluations

The AI receives one clean business result without knowing anything about the underlying implementation.

Think of MCP as the Service Layer for Enterprise AI

Software architects have used service layers for decades.

Whether it’s:

SOA
Enterprise Service Bus (ESB)
Microservices
API Gateways

The purpose has never been raw performance.

The purpose has always been:

Better maintainability
Better governance
Better scalability
Better abstraction

MCP serves exactly the same role—but for AI systems.

My Recommendation

If you’re building a personal AI project with only a few APIs, calling them directly is perfectly reasonable.

However, once an organization begins integrating:

ERP
Workflow
Knowledge Bases
CRM
LDAP
Multiple AI Agents
Multiple LLMs

An MCP architecture becomes increasingly valuable.

The biggest expense in enterprise software isn’t an additional five milliseconds.

It’s maintaining complex integrations over the next five years.

Final Thoughts

Many discussions focus on one simple observation:

“MCP adds another layer, therefore it must be slower.”

From an enterprise architecture perspective, the more important observation is:

MCP adds another layer, therefore the entire AI platform becomes easier to maintain.

That’s a very different way of thinking.

MCP is not a performance optimization technology.

It is an architecture optimization technology.

It trades a negligible amount of runtime overhead for significantly better maintainability, governance, security, and long-term scalability.

And in enterprise software, those qualities are often far more valuable than saving a few milliseconds.