MCP — the common protocol for attaching tools

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

The arithmetic before a standard

Three shapes passed over MCP in one line — "a protocol for talking to an outside program". This chapter is why that protocol was needed: there was a time when the way you attached them differed by product.

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

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.

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

Model Context Protocol. It put a common specification in between.

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.

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.

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.

Check yourself

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

2. What did MCP not standardise?

3. Why does attaching via MCP make switching easier?

What an MCP server actually provides → What an MCP server gives you