MCP fundamentals

What is Model Context Protocol?

Why MCP matters for agent systems.

A standard for hooking up tools

So far in this curriculum, "tools" have been Python functions you wrote and registered with your agent. That works fine for one project. It scales badly the moment you want the same tools across multiple agents, multiple frameworks, multiple languages. Every agent re-implements read_file, query_db, send_email. Updates ship one project at a time. Sharing means copy-pasting.

The Model Context Protocol (MCP) is the standard that fixes this. It defines a wire protocol between agents and tool providers. Once a capability is exposed as an MCP server, any MCP-compatible agent can use it without knowing how it's implemented. The same query_db server can serve a Python agent today and a TypeScript agent tomorrow without code changes on either side.

This is the "USB-C for agent tools" comparison you'll hear repeatedly. It is a reasonable shorthand: standard plug, standard semantics, vendor-neutral.

What MCP standardizes

Three things, all of them small but important:

1. The shape of a tool call

Every MCP tool has a JSON Schema for its input, a JSON Schema for its output, a name, and a description. This is not new (it's the same shape OpenAI and Anthropic tool-calling APIs use), but MCP fixes a single canonical version so servers and clients agree.

2. The lifecycle of a connection

How a client discovers what tools a server offers, how it negotiates capabilities, how it handles errors and disconnections. None of this is novel either; what MCP adds is agreement on the details so any client can talk to any server.

3. Two more primitives beyond tools

Tools are one of three MCP primitives. The others are resources (read-only data the agent can fetch) and prompts (named, parameterized prompt templates the server provides). Most servers expose only tools, but the resource and prompt primitives matter for specific use cases (covered in Module 2 lesson 2).

What MCP doesn't standardize

Worth being explicit about what's outside scope:

• The agent. MCP says nothing about how the agent reasons, plans, or runs its loop. It's the protocol below the agent.
• The transport details. MCP defines the shape of messages but supports multiple transports (stdio, SSE, streamable HTTP). The next lesson covers them.
• Authentication. MCP includes hooks for auth but the actual mechanism is up to the server (covered in Module 4).
• Cross-server orchestration. If an agent talks to five MCP servers, MCP tells you nothing about how to compose their tools. That's the agent's problem.

The protocol is intentionally narrow. It does one thing: standardize how an agent talks to a tool provider. Everything else stays where it was.

Why MCP matters now

Three reasons it's gaining traction over plain function-calling registries:

1. Tools you don't own

If your agent needs to talk to GitHub, Google Drive, Linear, your company's internal Postgres, and three vendor APIs, you previously had to write client code for each one. With MCP, the providers ship their own MCP servers and you just connect. Vendor-side MCP servers are now common; the ecosystem is real.

2. Cross-language reuse

A team writes a Postgres MCP server in Rust. Their Python agents use it. Their TypeScript agents use it. Their Go data pipeline uses it. The server doesn't care about the client language; the wire protocol handles the translation.

3. Reduced lock-in

If your agent uses a vendor's tool registry directly, switching vendors means rewriting tool code. If your agent uses MCP servers, switching frameworks is mostly about the agent loop; the tool infrastructure is reusable.

These benefits are real but pragmatic. MCP doesn't make agents smarter; it makes the plumbing portable. For small projects with a few owned tools, plain function calling is fine. For larger systems with many tools across many providers, MCP earns its complexity.

The mental model

[ Agent (host) ]
       |
       v   "client" inside the host
[ MCP client ]
       |
       v   wire protocol (stdio / SSE / HTTP)
[ MCP server ]
       |
       v   server-specific implementation
[ Actual capability: filesystem, DB, API, ... ]

Three roles: host, client, server. The host is the agent application. The client is a small library inside the host that speaks the MCP wire protocol. The server is a separate process (or hosted endpoint) that implements MCP and exposes the actual capability. The next lesson goes deep on these three.

When not to use MCP

• Single project, few tools, no sharing. A handful of in-process Python functions has lower overhead.
• Latency-critical inner loops. MCP adds an IPC hop. If you're shaving milliseconds, in-process is faster.
• Tools that need direct access to the agent's memory. MCP is process-isolated by design; if a tool truly needs to mutate the agent's working memory (rare), bypass MCP.

For everything else, MCP is a reasonable default. Even projects that don't currently need it benefit from being structured to make the eventual move easy.

What this track will do

Four modules:

1. MCP fundamentals. This module: protocol, architecture, transports.
2. Building MCP servers. Exposing your own capabilities as MCP servers.
3. Building MCP clients. Connecting to MCP servers from your agent.
4. MCP in production. Auth, security, orchestration, observability for MCP at scale.

By the end you'll be able to expose any capability as an MCP server, connect to multiple servers from a single agent, and run the whole stack with the production controls Track 2 introduced.

Key takeaway

MCP standardizes how agents talk to tool providers: the shape of tool calls, the lifecycle of connections, and three primitives (tools, resources, prompts). It's a small protocol with a large impact: tools become portable across agents and languages, ecosystems can share servers, and lock-in to any single framework drops. The next lesson breaks down the host/client/server roles in detail.