# MCP — why a standard was needed

> **What you will learn**
> What the absence of a standard actually cost, and exactly what MCP
> standardised.

## The arithmetic before a standard

[Tool use](/guide/ai-tool-use) showed the structure of attaching tools to a
model. But **the way you attached them differed by product.**

Say you attach three tools (Slack, GitHub, an internal database) to three
agents.

```mermaid
graph TD
  A1["Agent A"] --> S1["Slack integration for A"]
  A1 --> G1["GitHub integration for A"]
  A1 --> D1["Internal DB integration for A"]
  A2["Agent B"] --> S2["Slack integration for B"]
  A2 --> G2["GitHub integration for B"]
  A2 --> D2["Internal DB integration for B"]
```

That is **3 × 3 = 9** integrations. One more tool adds three; one more agent
adds as many as you have tools.

| Tools × agents | Integrations to build |
|---|---|
| 3 × 3 | 9 |
| 5 × 4 | 20 |
| 10 × 5 | **50** |

That was the real cost. And **maintaining** them was worse than building them —
change the Slack API and you fix it in three places.

## What MCP did

**M**odel **C**ontext **P**rotocol. It put a common specification in between.

```mermaid
graph TD
  A1["Agent A"] --> M["MCP"]
  A2["Agent B"] --> M
  A3["Agent C"] --> M
  M --> S["Slack server"]
  M --> G["GitHub server"]
  M --> D["Internal DB server"]
```

Now the arithmetic changes.

```
Tool side:   build it once (as an MCP server)
Agent side:  implement it once (as an MCP client)
Connecting:  just plug in
```

**3 × 3 = 9** becomes **3 + 3 = 6**, and the gap widens with scale. 10 × 5 = 50
becomes 10 + 5 = 15.

## The analogy

Think of USB.

- **Before USB**: a dedicated port per printer, a dedicated port per mouse.
  Change computers and you might have to change every peripheral.
- **After USB**: one specification, so anything plugs in anywhere. Printer makers
  only need to support USB; so do computer makers.

MCP is **the USB between AI and tools.**

## What it standardised

Precisely three things.

| What it defines | Content |
|---|---|
| **How to introduce** | how a server announces its list of tools |
| **How to call** | the request format for invoking a tool |
| **How to reply** | the format for returning a result |

**It did not standardise what a tool does.** Each server decides that. The same
way USB defines "how you connect" but not "what a printer prints."

## What changes in practice

### 1. You reuse what others built

Slack, GitHub, Google Drive and the like often already have MCP servers. You do
not have to build them.

### 2. Build once, use everywhere

Build one MCP server for your internal system and several agents use it. Switch
to a different AI product later and the server carries over unchanged.

### 3. Switching gets easier

Attach tools directly to a specific AI product and you are tied to it. Attach
via MCP and you can **leave the tools alone and change the AI side.**

> In practice this matters more than expected. AI products change quickly;
> internal system integrations, once built, stay in use for a long time.

## Common misconceptions

### "Does MCP connect to anything?"

It means the connection method is standard — **not that every system already has
an MCP server.** Internal systems generally have to be built. The gain is that
once built, they are reusable.

### "It's a standard, so is it safe?"

The standard is about **the connection method**, not about safety. Attaching an
MCP server means allowing the agent to do everything that server can do. That is
covered separately in [tools are permissions](/guide/mcp-security).

---

## Check yourself

**1. Attaching 5 tools to 4 agents — how many integrations before and after the
standard?**

<details>
<summary>Answer</summary>

Before, **5 × 4 = 20**; with MCP, **5 + 4 = 9**. You implement once on the tool
side and once on the agent side.
</details>

**2. What did MCP not standardise?**

<details>
<summary>Answer</summary>

**What a tool does.** It defines only the introduce, call, and reply formats;
each server decides its own functionality. The same way USB defines the
connection but not what a printer prints.
</details>

**3. Why does attaching via MCP make switching easier?**

<details>
<summary>Answer</summary>

**Because the tool integration and the AI product are decoupled.** Attach
directly to a product and you are tied to it; attach via MCP and you leave the
tools alone while changing the AI side. AI products change fast and internal
integrations last, so this is a big practical difference.
</details>

---

What an MCP server actually provides →
[What an MCP server provides](/guide/mcp-capabilities)