Topic 2: Why MCP exists
A.1 The problem Nare actually has
Nare runs a small sleep and memory lab with two colleagues, Priya and Tomas. She keeps her research notes as Markdown files in one folder: meeting notes, reading lists, half-formed ideas about naps and recall. She uses several AI applications during a normal week: a desktop chat assistant, an AI-enabled code editor for her analysis scripts, a command-line coding agent, and a small assistant the lab is building for itself (which is the host you will build in this course).
She wants every one of them to answer "what did we decide about the nap study?" from her notes. Without a shared protocol, each application needs its own custom integration with the notes folder. Then Tomas wants the same assistants to see the lab booking calendar, and Priya wants the reference manager. Every new pairing of "AI application" and "data or tool system" is another piece of glue code, written against a different plugin API, with different auth and different bugs.
That is the whole motivation for the Model Context Protocol (MCP): an open protocol, first published by Anthropic in November 2024 and donated to the Linux Foundation's Agentic AI Foundation in December 2025, that standardises how AI applications connect to external tools and data. You write the notes integration once, as an MCP server, and every application that speaks MCP (an MCP host) can use it.
A.2 The N applications times M tools arithmetic
Let N be the number of AI applications and M the number of tool systems they should reach. Without a shared protocol, every application needs its own adapter for every tool system: N x M adapters. With a shared protocol, each application implements the client side once and each tool system implements the server side once: N + M implementations.
| Setting | N (hosts) | M (tool systems) | Bespoke adapters, N x M | MCP implementations, N + M | Saving |
|---|---|---|---|---|---|
| Nare's lab | 4 | 6 | 24 | 10 | 14 fewer, 58 percent |
| A mid-sized team | 10 | 50 | 500 | 60 | 440 fewer, 88 percent |
| A large company | 30 | 400 | 12,000 | 430 | 11,570 fewer, 96 percent |
Nare's six tool systems are the notes folder, the lab calendar, the reference manager, the EEG data store, email, and the participant spreadsheet. With 4 hosts that is 24 integrations to write, test, and keep working as each host's plugin API changes. With MCP it is 4 clients (which the host vendors already wrote) plus 6 servers, and in practice Nare writes only the servers nobody has published yet.
The saving grows with scale because multiplication grows faster than addition. The Module Lab at the end prints this table from code, so you can plug in your own numbers.
Two honest caveats. First, the saving is in integration code, not in thinking: each server still needs good tool descriptions, auth, and security review (Modules 3, 7, and 8). Second, the arithmetic assumes the hosts actually speak MCP. In 2026 the major AI desktop apps, code editors, and coding agents do, which is why the argument holds; ten years ago the same math would have been a wish.
A.3 What a protocol standardises that an SDK cannot
A reasonable question: "Why not just a good SDK?" An SDK is code in one language, owned by one vendor, that you import. A protocol is an agreement about the messages that cross a boundary, so two programs that share no code can still work together. The difference shows up in five places.
| Concern | What an SDK gives you | What a protocol gives you |
|---|---|---|
| Language | One language (a Python SDK is useless to a TypeScript host) | Any language that can read and write JSON; MCP has official SDKs in many languages that interoperate |
| Ownership | Whoever ships the SDK decides its future | A public specification with a change process (SEPs, Part E) and a neutral home at the Linux Foundation |
| Discovery | You read docs, then write code against a fixed API | A client asks a running server what it offers (server/discover, tools/list) and adapts at runtime |
| Versioning | Semantic versions of one package | Dated protocol revisions that both sides name on every request, with explicit errors when they disagree |
| Process boundary | Usually in-process function calls | Defined transports (stdio for local subprocesses, Streamable HTTP for remote services), so the server can be a separate, sandboxed process owned by someone else |
The Python SDK you will use in this course is one implementation of the protocol. A TypeScript host built by someone who has never heard of Python will still talk to your server, because both follow the same specification. That is the thing an SDK alone cannot do.
A.4 MCP versus native function calling, REST, and agent-to-agent protocols
Three neighbours get confused with MCP. Here is how they differ, in plain words.
Native function calling (also called tool calling) is a feature of an LLM API. You send the model a list of tool definitions in the provider's format; the model replies "please call search_notes with these arguments"; your code runs the function and sends back the result. It is the mechanism by which a model uses tools. It says nothing about where the tools come from or how another application could reuse them. MCP sits one layer out: it is how a host gets tool definitions and executes tool calls against a separate server. Most MCP hosts use native function calling underneath, converting MCP tools into the provider's format. You will see exactly that in Part C.
Plain REST (or any HTTP API described with OpenAPI) is how services talk to services. It is excellent for that, and many MCP servers are thin wrappers around REST APIs. What REST does not define is LLM-oriented behaviour: descriptions written for a model, a standard way to list callable tools, results shaped for a model to read, user-controlled prompts, or a way for the server to ask the user a question mid-call.
Agent-to-agent protocols, most prominently A2A (Agent2Agent, introduced by Google in April 2025 and now a Linux Foundation project), connect one autonomous agent to another. The remote side is an agent with its own model, its own reasoning, and long-running tasks; you delegate a goal, not a function call. MCP's remote side is usually a capability provider that does exactly what it is told. The two are complementary: an agent might use MCP to reach its tools and A2A to hand work to a peer agent.
| Situation | Use this | Why |
|---|---|---|
| One application, a handful of functions that live in the same codebase, one model provider | Native function calling | Nothing to share, so a protocol boundary adds a process and a dependency for no reuse |
| A capability several AI applications should use (your notes, your database, your ticket system) | MCP | Write it once as a server; every MCP host can discover and call it |
| A service called by other services, no model in the loop | REST, gRPC, or a message queue | Mature tooling for caching, load balancing, and typed contracts; MCP's model-oriented features would be unused |
| Delegating a whole task to another autonomous agent that plans for itself | A2A or a similar agent-to-agent protocol | The remote side needs task lifecycles and negotiation between reasoning agents, not a function signature |
| An existing REST API you want models to use | MCP server wrapping the REST API | Keep REST for services; add a task-shaped MCP layer for models (Module 10 explains why one tool per endpoint underperforms) |
A.5 When MCP is the wrong tool
MCP is an integration protocol. It shines when the same capability must be reached by several AI applications, possibly across process or network boundaries, under user consent. Outside that niche it is overhead. Use this table before you reach for it.
| Situation | Use this | Why |
|---|---|---|
| A deterministic pipeline with fixed steps (nightly export, ETL) | Plain code or a workflow engine | No model decides anything, so tool discovery and model-readable descriptions buy nothing |
| One script calling one model with one or two functions | Native function calling | The Module Lab measures about 2 ms per call over stdio (about 1 ms in memory) and a stdio process start near 0.7 seconds; small, but pure cost when nothing is shared |
| Hard real-time or very high-throughput calls (thousands per second, sub-millisecond budget) | In-process function calls or a binary RPC | JSON-RPC over stdio or HTTP adds serialisation and a hop per call |
| Moving bulk data (gigabytes of EEG recordings) | Object storage or a data API, with MCP returning links | Tool results are read by a model and cost context tokens; return a resource link or a URL, never the bytes |
| Service-to-service integration with no LLM | REST, gRPC, queues | Better tooling and no model-oriented surface to secure |
| Handing a goal to another reasoning agent | An agent-to-agent protocol such as A2A | MCP models capabilities, not peer agents with their own plans |
| Untrusted third-party code you cannot review or sandbox | Nothing yet; review or sandbox first | An MCP server runs with the permissions you give it, and its tool descriptions are read by your model (Module 8) |
| Several AI apps should reach the same data or actions, now or later | MCP | This is the N + M case the protocol was designed for |
The notes assistant sits firmly in the last row: Nare wants her notes in several assistants, and the lab's own host is only one of them.