Module 1: What MCP Is and Why It Exists

What MCP is: a USB-C for AI applications

Next →

Description

The previous lesson left you feeling the problem —M×N custom adapters— without naming the solution. This lesson names it: the Model Context Protocol (MCP). It is not a library from Anthropic for use with Claude and nothing else: it is an open protocol, published by Anthropic in November 2024, that any AI application —from any vendor— can implement to connect, in a standard way, to tools, data, and prompts that live on external servers.

Connection to the module

This lesson formally names what lesson 02 left unnamed. Lesson 04 takes this definition and turns it into concrete architecture (host, client, server); lesson 05 contrasts it with something you already know (tool_use/tool_result) so you don't confuse it with that. Everything that follows in the guide —including the server and client you run in lesson 07— is a concrete implementation of what this lesson defines.

Analogy: a USB-C port for AI applications

MCP's own official documentation sums up the idea with an image worth taking seriously, not just as a nice turn of phrase: "Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools." (modelcontextprotocol.io/introduction).

Notice what the analogy really captures, not just on the surface:

  • Before USB-C, every laptop manufacturer had its own charging connector, every peripheral (mouse, external drive, monitor) its own cable — lesson 02's M×N problem, but in hardware. Buying a new peripheral was no guarantee it would work with your laptop.
  • With USB-C, a single type of port works for charging, for connecting a monitor, for transferring files. The peripheral manufacturer designs once against the standard; the laptop manufacturer installs one port, not one for each type of peripheral that exists.
  • MCP does the same thing, but with software: a system like Reservo builds one MCP server that exposes its tools, resources, and prompts according to the standard; an AI application like Claude Code implements one MCP client that knows how to speak that standard. Neither of them needs to know anything specific about the other beforehand — the protocol is the "connector" that makes them compatible.

The analogy has a limit, and it's worth naming: USB-C is a physical hardware standard (voltages, pins, electrical signals); MCP is a message standard (JSON-RPC 2.0 over stdio or HTTP). But the role they play —turning "every combination needs its own adapter" into "everyone speaks the same language"— is identical, and it's exactly what MCP's own documentation chose to introduce itself with.

What MCP is, precisely

With the analogy in place, here's the formal definition, piece by piece:

MCP (Model Context Protocol)
├── WHAT IT IS:      an OPEN protocol — a message specification,
│               not a closed library or a single-vendor product.
├── WHO PUBLISHED IT:  Anthropic.
├── WHEN:       November 2024.
├── WHAT IT STANDARDIZES:  how an AI application (the "host") connects to
│               data sources, tools, and prompts, through reusable
│               SERVERS.
└── WHAT IT ISN'T:  it isn't the model, it isn't Claude's Messages API, it
                isn't a product exclusive to Anthropic — it is the WIRING LAYER
                between an AI application and the external systems it uses.

The point most prone to confusion —and worth calling out now, before the wrong idea sticks— is "who can use it." MCP is not a private API that only works with Anthropic models. It's an open protocol: any AI application, whether from Anthropic or not, can implement an MCP client; any system, whether related to Anthropic or not, can implement an MCP server. The fact that Anthropic published it doesn't make it proprietary — if the standard is widely adopted, it makes it more like HTTP or USB-C than a closed SDK: a compatibility layer that benefits everyone who adopts it, not a walled garden belonging to a single manufacturer.

What MCP standardizes, at a glance

MCP defines, with message-level precision, three things we've only seen so far as a problem:

  1. How a server announces its capabilities. A server tells whoever connects what it can offer: tools, resources, prompts, or some combination. You see it run in lesson 07: capabilities: {"tools": {}} is, literally, a server saying "I offer tools, and nothing else."
  2. How a client discovers what's available. Methods like tools/list aren't an informal convention between Reservo and whoever uses it — they're part of the protocol itself, with an exact shape that any MCP client knows how to interpret without needing Reservo-specific documentation.
  3. How a result is invoked and read. tools/call (which Module 3 develops in depth), resources/read (Module 4), prompts/get (Module 5) — each with a fixed response shape, so the client doesn't need to know anything about the server's internal implementation to use it.

What MCP does not standardize —and this matters just as much as what it does— is which AI model the host uses, or how that model decides which tool to call. That remains the territory of each AI application and its own model's protocol (for Claude, the Messages API with tool_use/tool_result, which you already know from agent-fundamentals). Lesson 05 traces that boundary in full detail.

Reservo's MCP server, in these terms

With this definition in place you can now place the guide's project precisely: reservo-mcp-server is a server that implements the MCP protocol to expose Reservo's tools, policies, and templates. It doesn't know —and doesn't need to know— whether whoever connects is Claude Code, your own Python script, or any other application that implements an MCP client. That's exactly the gain over the agent-fundamentals pattern: there, reservo_tools only served the agent that imported it directly. A Reservo MCP server serves any compatible client, without Reservo needing to know beforehand who's going to connect.

Common mistakes

  1. "MCP is an Anthropic library for tool calling with Claude." No. MCP is an open protocol; the fact that Anthropic published it doesn't make it exclusive to its products. Any AI application can implement a client, and any system can implement a server, without depending on Anthropic for any of it.

  2. "MCP is the model, or it makes the model smarter." No. MCP is the wiring layer — it solves how an agent gets access to external tools and data. The intelligence (which tool to call, with what arguments) is still the model's job, and that decision process lives in a different protocol (lesson 05 draws that line).

  3. "USB-C is the perfect analogy, no caveats." The analogy is useful but not exact: USB-C standardizes physical hardware; MCP standardizes JSON-RPC messages. Keep that in mind so you don't push the parallel further than it's useful for — which is explaining why a common standard replaces custom adapters.

  4. "MCP replaces the API my application already uses." Not necessarily. MCP is one more piece, not a total replacement: your application can keep calling an API directly when that's convenient, and use MCP specifically for connections that benefit from a shared, reusable protocol (like when several different hosts want the same tool).

  5. "If my system isn't published by Anthropic, it can't be a real MCP server." No. Anyone can build and implement an MCP server — Reservo, in this guide, is an educational example, not an Anthropic product. The protocol is open precisely for that: so that any system, from any organization, can expose itself in a standard way.

Exercises

Exercise 1: True or false (Easy)

Decide whether each statement is true or false, and why: (a) MCP is exclusive to applications built by Anthropic; (b) MCP was published in November 2024; (c) MCP standardizes how the model decides which tool to call; (d) a system with no relationship to Anthropic can build an MCP server.

See solution

(a) False. MCP is an open protocol; any AI application, whether from Anthropic or not, can implement a client that speaks it.

(b) True. Anthropic published MCP in November 2024.

(c) False. That decision (which tool to call) belongs to the model, within the tool_use/tool_result protocol of the Messages API (or another model vendor's equivalent) — not MCP. MCP standardizes how the agent gets the tools to offer the model, not how the model chooses among them.

(d) True. Any system can implement an MCP server; being an open protocol means exactly that — Reservo, in this guide, is an educational case with no relationship to Anthropic whatsoever.

Exercise 2: Complete the analogy (Medium)

In the USB-C analogy: what role does Reservo (the MCP server) play, what role does Claude Code (the host) play, and what would be, in hardware terms, the equivalent of the "protocol" itself (neither the device nor the peripheral, but the rule that makes them compatible)?

See solution

Reservo (the server) plays the role of the peripheral: the external drive, the monitor, the mouse — something that offers a function (saving files, displaying an image, moving the cursor) and that was designed against the standard, without knowing beforehand which specific laptop it would connect to.

Claude Code (the host) plays the role of the laptop: the application that has the port and that, by connecting the peripheral, gets access to its function without needing a special driver hand-written for that particular peripheral.

The equivalent of the protocol itself is neither the laptop nor the peripheral: it's the USB-C port specification — the voltages, the pins, the order of signals — that both manufacturers (the laptop's and the peripheral's) agree to follow without having coordinated directly with each other. In MCP, that role is played by the specification (modelcontextprotocol.io/specification/2025-06-18): the exact shape of the JSON-RPC messages that both Reservo and Claude Code agree to implement, without either of them having had to talk to the other to agree on it.

Exercise 3: Defend or refute (Hard)

A colleague argues: "If MCP is an open protocol and doesn't depend on Anthropic, then it doesn't matter which AI model my application uses — by implementing an MCP client, any model will automatically know how to use the tools of any server." Is that correct? Justify your answer using the distinction between what MCP standardizes and what it doesn't.

See solution

It is partially correct, with an important confusion. It's true that, being an open protocol, any AI application —regardless of which model it uses underneath— can implement an MCP client and connect to any MCP server; that's exactly what makes MCP solve the M×N problem regardless of vendor.

But the statement gets the next step wrong: implementing an MCP client doesn't make "the model automatically know how to use the tools." The MCP client handles discovering the tools (tools/list) and executing them when asked (tools/call) — but deciding which one to use and with what arguments remains the model's responsibility, through ITS OWN tool-calling protocol (for Claude, tool_use/tool_result; other models might have their own). MCP hands the agent the inputSchema of each discovered tool, and it's the agent's job to translate that MCP inputSchema into the shape its model expects (for example, the Messages API's input_schema) so the model can decide.

In other words: MCP solves "how the tools get to the agent," independently of the model. But "how the model decides to use them" remains a separate protocol, specific to each model vendor — the exact boundary lesson 05 draws.

Summary and next step

  • MCP (Model Context Protocol) is an open protocol, published by Anthropic in November 2024, that standardizes how an AI application connects to tools, data, and prompts through reusable servers.
  • The official analogy: MCP is to AI applications what USB-C is to electronic devices — a common connector that replaces the custom adapters from lesson 02.
  • MCP is not exclusive to Anthropic or Claude: any AI application can implement a client, and any system can implement a server, without Anthropic standing in the middle.
  • MCP standardizes how tools, resources, and prompts are discovered and invoked — it does not standardize how the model decides which one to use. That decision is a different protocol (the Messages API for Claude), which lesson 05 contrasts in detail.
  • The Reservo MCP server this guide builds is exactly that: a server that exposes Reservo's tools, resources, and prompts, without needing to know beforehand which client will connect.

Next lesson: 04 — The host, client, server architecture. Now that you know what MCP is, we see how it's organized in practice: the three roles that appear in every connection, and why a host creates a separate client for each server it talks to.

Additional resources

  1. Model Context Protocol — Introduction — The source of the USB-C analogy and the official description of MCP that this lesson develops.
  2. Model Context Protocol — Specification 2025-06-18 — The exact specification that defines, message by message, what MCP standardizes.
  3. Anthropic — Model Context Protocol (announcement) — Anthropic's original announcement of MCP's publication, November 2024.
  4. Anthropic — Tool use (function calling) overview — The protocol that remains each model vendor's responsibility (not MCP's), which lesson 05 contrasts.
← PreviousThe M×N integration problemNext →The host, client, server architecture