PROTOCOL
What Is MCP (Model Context Protocol)?
MCP (Model Context Protocol) is an open protocol that standardizes how an AI application connects to external tools, data sources, and systems. Rather than writing a custom integration for every tool a model might use, you implement one interface that any compliant client and server can speak.
What the video explains
One adapter between a model and its tools
MCP stands for Model Context Protocol, and it lets an AI model use tools. On its own, an LLM is a box: text comes in, text goes out. It can reason about that text, but it cannot send an email or book a meeting. In an MCP setup the model sits on the client side, so it is called the MCP client.
The other side is the MCP server, which is what most people mean when they say MCP. The client is the model; the server is where the tools are described and connected. Think of the server as a catalog. Every action the model is allowed to take is listed with a name: create meeting, search web, send email, get weather, read file. Some tools only retrieve data, and others act and change something.
Walking through one call
Say a user, Mike, types: create a meeting on the third of April with Rachel. The model knows an MCP server is connected, so its first move is to look. It asks the server which tools it has, and the server sends back a short manual for every tool. For create meeting, the manual says what it does (books a calendar slot), what to give it (a title, a date, and people), and what it gives back (a link to the event).
The model reads all the manuals and sees that only create meeting can book a meeting, so it picks that one. It then writes the exact input the tool needs, and the server reads the request and runs the tool. The result goes back to the model: a link to a meeting that now exists, with Rachel invited. All the model did was read a catalog and send some text.
The recap
The client is the model, and the server holds the catalog. The model reads the catalog, picks a tool, sends its input, and gets the result. Any tool that speaks MCP can be used the same way.
The problem MCP solves
Before MCP, wiring a model to N tools across M applications meant roughly N×M custom integrations. A Slack app talking to one model needs different glue code than the same app talking to another, and every new tool is its own one-off wiring job.
MCP turns that into N+M. A tool ships one MCP server. An application ships one MCP client. Any client then talks to any server with no custom code on either side, the way any browser talks to any website because both speak HTTP.
How it works
An MCP server exposes three primitives. Tools are functions the model can call, each with a name, a description, and an input schema. Resources are data the model can read, like a file or a query result. Prompts are reusable templates the server offers.
An MCP client, usually built into an AI application, connects to one or more servers, discovers what each exposes, and hands that to the model. The model never speaks MCP itself. It reads the tool descriptions, decides when to call one, and the client carries the protocol traffic.
Transport is JSON-RPC 2.0 over stdio for a local server run as a subprocess, or HTTP with Server-Sent Events for a remote one. A deliberately boring choice. MCP is not inventing a wire format, it is standardizing what goes over an existing one.
- 1. Mike asks the model to book a meeting.
- 2. The model asks the server which tools it has. The server replies with its catalog.
- 3. It reads the manual for create_meeting: what it does, what it needs, what it returns.
- 4. The model writes exactly the input the tool needs and sends it.
- 5. The server runs the tool and returns a link. The meeting exists.
MCP vs. a plain function call
A model that supports tool calling can already invoke a function you define inline, in the same codebase, for one conversation. MCP is for when the tool should work across applications and be maintained on its own, separate from any app that uses it.
Wiring a model to your own database inside your own app? An inline tool definition is simpler, and MCP is overhead. Building a GitHub integration you want every MCP-compatible client to use? MCP is the right layer.
FAQ
- Does MCP require a specific model provider?
- No. MCP is provider-agnostic. It defines the protocol between a client and a server; which model the client is built around is a separate decision.
- Is MCP the same as a plugin system?
- Similar in spirit, but standardized rather than tied to one vendor. A plugin system built for one application only works in that application. An MCP server works with any MCP-compliant client.