Part 13 — MCP: the universal adapter

Chapter 52 taught you to write a tool definition by hand, for one agent. That was the right place to start — but it doesn't scale past one team writing one agent. This part is what happens once many applications need many of the same tools: a shared protocol, so a tool gets written once and any compatible host can use it.

Chapter 56 — Why MCP exists (the N×M problem)

In one sentence

MCP (Model Context Protocol) is an open standard that lets any AI application connect to any tool or data source, so that integrations are written once instead of once per application.

The problem

You've built tools for your agent (Chapter 52). Now:

Your colleague wants the same GitHub tools in their app.
You want your agent to use someone else's Postgres tools.
Your company has five AI applications, each needing the same ten integrations.

Without a standard, that's N applications × M tools = N×M separate integrations, each written by hand.

   WITHOUT A STANDARD                  WITH MCP
   (every app writes every tool)       (write each side once)

   app A --+-- GitHub                  app A --+
   app A --+-- Slack                   app B --+-- [MCP] --+-- GitHub server
   app A --+-- Postgres                app C --+           +-- Slack server
   app B --+-- GitHub  (again!)                            +-- Postgres server
   app B --+-- Slack   (again!)
   app B --+-- Postgres (again!)       N + M integrations
   app C --+-- ... and again

   N x M integrations

The analogy

MCP is often described as "USB-C for AI applications", and it's a fair comparison: one connector standard, so any device works with any host, instead of a different cable for every combination.

A closer analogy for programmers: the Language Server Protocol (LSP). Before LSP, every editor implemented support for every language. After it, a language implements one server and works in every editor. MCP was explicitly inspired by LSP and does the same thing for AI applications and tools.

What it gives you

Benefit	In practice
Write a tool once	Your Postgres MCP server works in every MCP-compatible app
Use others' tools	Hundreds of open-source servers exist for common systems
Swap the model/app	Your integrations don't change
A security boundary	The server is a separate process with its own permissions
Standard discovery	The client asks "what can you do?" and gets a machine-readable answer

The context

MCP was introduced by Anthropic in November 2024 and moved into open governance. It has been adopted broadly across the industry: official SDKs, reference servers, AI applications, IDEs, and cloud platforms now support it.

The specification is versioned by date. The current revision at the time of writing is 2026-07-28, which made a significant change: the protocol core is now stateless, which we'll cover in Chapter 57.

Because MCP is evolving quickly, always check the spec version your SDK targets. The concepts below are stable; specific headers and options change.

When to use MCP vs plain function calling

   PLAIN FUNCTION CALLING (Chapter 52)
     the tool lives in YOUR codebase, used by YOUR app only
     -> simplest thing that works. Use this by default.

   MCP
     * the tool should be reusable across several applications
     * someone else already wrote the server you need
     * you want the tool to run as a separate, sandboxed process
     * you're building a product other people will connect tools to

Don't reach for MCP to call your own function in your own app. That's added machinery for no benefit.

Practice (10 min, no code)

List the integrations an AI assistant at your workplace would need (ticketing, docs, calendar, database, deployment...). Then:

How many applications might want each one?
Which of those probably already exist as open-source MCP servers? (Search the official MCP servers repository and registry.)
Which are specific enough to your company that you'd write them yourself?

Common confusions

"MCP is an Anthropic thing." It started there and is now an open, vendor-neutral standard used across the industry.
"MCP replaces function calling." No — MCP delivers tools to the model, which still uses ordinary tool calling to invoke them. It standardises the plumbing, not the mechanism.
"MCP makes my agent smarter." It makes integration easier. The reasoning is unchanged.

Check yourself

What is the N×M problem?
What earlier protocol inspired MCP, and what did it standardise?
Give two situations where MCP is the right choice over plain function calling.
Why does the spec version matter?