[ AGENTS · MCP · INTEGRATION ]

The Model Context Protocol, explained

MCP is an open standard that lets AI assistants talk to your tools and data through one consistent interface — instead of a bespoke integration per app.

Watch the lecture, then read Max's deep-dive below.

▸ In this video you'll see

Why MCP exists — the M×N integration problem
The three primitives: tools, resources, prompts
How a client and server handshake and exchange capabilities
Building agents that compose multiple MCP servers
The security boundary each server draws around your tools

The Model Context Protocol (MCP) is an open standard, published in late 2024, for connecting AI assistants to the systems where your data and tools already live. The problem it solves is combinatorial: every model that wants to use every tool used to need its own custom integration — an M×N mess. MCP turns that into M+N: a tool is exposed once as an MCP server, and any MCP-capable client (an IDE, a desktop assistant, an agent runtime) can use it.

The three primitives

An MCP server exposes capabilities through three kinds of building blocks. Understanding them is most of understanding the protocol:

Tools — functions the model can call, each with a name, a description, and a JSON Schema for its inputs. This is the write/act surface: send an email, query a database, create a file.
Resources — read-only data the client can load into context, addressed by URI (a file, a database row, an API response). Think of these as attachments the model can pull in.
Prompts — reusable, parameterized message templates the server offers, often surfaced to the user as slash-commands or shortcuts.

How the wire protocol works

MCP speaks JSON-RPC 2.0 over a transport. Two transports are standard: stdio (the client launches the server as a subprocess and talks over stdin/stdout — ideal for local tools) and streamable HTTP (for remote servers, with Server-Sent Events for streaming). The conversation starts with an initialize handshake where client and server exchange capabilities and protocol versions, then the client can tools/list, resources/list, and call tools/call.

A useful mental model: MCP is to AI tools what the Language Server Protocol (LSP) is to code editors. LSP let one language server serve many editors; MCP lets one tool server serve many AI clients. The design is a deliberate homage.

Why it matters for building agents

Without a standard, an agent's tool layer is a pile of one-off adapters that break whenever an API shifts. With MCP, the tool layer becomes composable: you can drop in a filesystem server, a Postgres server, and a web-search server, and your agent immediately has all three — no glue code per model. Servers are also a natural security boundary. Each one declares exactly which tools and resources it offers, so you can reason about, scope, and audit what an assistant is allowed to touch.

Build your own in five minutes

The official SDKs (TypeScript, Python, and others) reduce a server to a few declarations. In pseudocode, a server registers a tool with a schema and a handler, then starts a transport:

server.tool("get_weather",
  { city: z.string() },
  async ({ city }) => ({ content: [{ type: "text", text: await lookup(city) }] })
);
server.connect(new StdioServerTransport());

Point an MCP client at that process and the model can now call get_weather as naturally as any built-in function. That is the whole promise: write the tool once, use it everywhere.

Keep going

modelcontextprotocol.io — the official spec, docs, and SDKs
Reference servers — open-source MCP servers you can read and run

MCP Agents Tools JSON-RPC