What MCP Actually Solves: From N x M Integrations to N + M

The question behind the hype

A team that ships MCP support (a server with 16 tools, plus a client that connects to other MCP servers) will sooner or later hear the sharpest objection from inside its own walls: if MCP just calls APIs and returns data, why bother? REST APIs already exist.

It's a fair question, and most explanations of MCP stumble because they start with the protocol rather than the problem. So start with the problem.

What problem MCP exists for

Picture a manager typing a question into an AI assistant: which purchase requests are sitting in my approval queue? The procurement system has the answer, and probably a REST API in front of it. So what's still missing? There are four common routes, each with a catch:

1. Copy the records into the chat window. It works once, by hand, and the copy starts aging immediately.
2. Embed a chatbot in the procurement app itself. That's nicer, but the AI is now confined to that app and the integration is yours to maintain forever.
3. Paste in the API documentation and trust the model to choose the right endpoint. It can work, though it breaks easily.
4. Write a dedicated integration for each assistant in use across the company.

The last route turns messy quickly. A company with 10 internal systems and 5 assistants may need up to 10 × 5 = 50 separate integrations, every one with its own auth code, oddities and maintenance. MCP was designed to remove exactly this multiplication.

From N × M to N + M

Rather than wiring every AI client to every system, each system describes its capabilities once through a standard protocol, and each AI client implements that protocol once. Without MCP, every pairing needs its own integration:

Without MCP: every pair needs its own integration

System A ──── AI Client 1
System A ──── AI Client 2
System B ──── AI Client 1
System B ──── AI Client 2N × M integrations

With MCP, each side is built once:

With MCP: build once on each side

System A ──┐             ┌── AI Client 1
System B ──┼──── MCP ────┼── AI Client 2
System C ──┘             └── AI Client 3N + M implementations

For ten systems and five assistants, the count falls from 50 to 15 implementations. In a single line: MCP lets an assistant find out what a system offers and invoke it, using one shared convention.

Three ideas make that click.

1. No AI lives inside the MCP server

This is probably the most common misunderstanding. People imagine a chain like this:

User → AI → MCP Server → API → AI → Answer

with a second model reasoning on the far side. Nothing like that exists. The server is plain, conventional code that never calls an LLM. What happens in practice is closer to this:

User
 ↓
LLM            decides which tool it needs
 ↓
MCP Client     sends the call
 ↓
MCP Server     executes it
 ↓
Your API / business logic
 ↓
Structured data
 ↓
LLM            interprets the result
 ↓
Answer

The server is the hands, and the model is the brain.

2. "We already have REST APIs"

True, and the API was never what was missing. Take a procurement app with this endpoint:

GET /api/v1/rtps?view=inbox&page=0

A person reads the docs and understands that. A model has to work out, while it's running, what the endpoint stands for, when it applies and what parameters to send, and no one has written the glue that tells it.

What MCP adds is discovery. A client can ask a server what it can do and receive a list of capabilities:

list_my_approvals
get_purchase_request
search_suppliers
get_purchase_order
create_rfq

Every entry carries a description and an input schema. The first tool reaches the model looking about like this:

{
  "name": "list_my_approvals",
  "description": "List purchase requests waiting for the current user's approval.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "page": { "type": "integer", "description": "Zero-based page number" }
    }
  }
}

Set GET /api/v1/rtps?view=inbox&page=0 next to list_my_approvals. The URL names a route, while the tool name states a capability in words a model can reason about. That's the gap MCP fills.

(Servers may also offer resources and reusable prompts, but tools are the usual starting point and the topic here.)

3. Composition is the interesting part

Here MCP becomes more than a wrapper around an API. Connect three servers to one assistant:

• A monitoring server with get_system_health and get_recent_incidents
• A knowledge server offering get_document, search_documents and find_certificate
• A procurement server whose tools are get_purchase_order, get_purchase_request and list_my_approvals

Then put a compound question to the assistant: list the pending purchase requests and flag any that lack supporting certificates. The model calls the procurement tools, queries the knowledge server for each request's certificates, joins the results and replies once. None of the servers is aware of the others, and that's fine.

So the model itself does the integrating. Compare that with a single oversized chatbot hard-wired to every backend. Here, a new system arrives as one more server and the assistant stays untouched.

The model as the integration layer

Traditional integration looks like this:

System A
   ↕
Integration Layer
   ↕
System B

With agentic AI, the picture becomes:

               AI Model
             /    |    \
            /     |     \
     MCP Server  MCP Server  MCP Server
          |          |          |
      Procurement  Knowledge  Monitoring

The model decides which capability it needs, which is fundamentally unlike building one integration layer that understands every system.

The LSP parallel

Developers have met this shape before in the Language Server Protocol. Earlier, every editor wrote its own autocomplete, go-to-definition and error highlighting for every language, the same N × M tangle. Under LSP a language provides those features once, as a language server, and any editor that speaks the protocol gets them. MCP borrows from LSP openly.

Hardly anyone asks why Java would need LSP given that it has a compiler. The compiler was never the target. Likewise your API states what the system can do, while MCP states how an AI client learns about and calls those abilities.

So the comparison isn't REST against MCP. It's REST underneath, with MCP on top for AI interoperability.

What MCP leaves unsolved

The hype tends to skip this part.

A model doesn't get any smarter through MCP. Tool descriptions act as prompts, so a sloppy description yields sloppy calls.

Security isn't handled for you either. Publishing search_suppliers carries little risk, since it only looks things up, but publishing approve_purchase_order hands over a financial control. Plan for authentication, authorization, least privilege, audit logs and an explicit confirmation before any state change.

Remember too that whatever a tool returns lands directly in the model's context. A fetched document may include instructions meant to bend the next tool call, so handle tool output as untrusted input. MCP opens the door to capabilities and says nothing about whether walking through is safe.

Do you need MCP at all?

Whether you have an API is the wrong test. The better one is whether a model picks which capability to call, from an AI client outside your control.

When the answer is no, skip MCP; plain API calls or the function calling in your framework are simpler. When it's yes, interoperability is your problem, and you can tackle it with custom plugins, proprietary protocols and per-client integrations, or by adopting a standard. The decision comes down to that.

What a 16-tool server shows

Once a server with 16 tools exists, the interesting result isn't that the team's own AI can call its own API, since that was possible before. It's that a different AI client can discover the system's capabilities without anyone building an integration for that client.

That is the payoff. The API holds what can be done; MCP is how an assistant learns what's possible and carries it out. With that distinction in mind, MCP reads less like a buzzword and more like plumbing.