MCP· Lesson 1 of 3
What Is MCP?
In one line · MCP is an open standard that lets any AI app use any tool without a custom integration per pair — write the tool once, it works everywhere.
MCP (Model Context Protocol) solves the N×M problem: instead of every AI app building a custom integration with every tool (Slack, GitHub, your database…), the tool is wrapped in an MCP server and the app acts as an MCP client — both speaking one shared language. The way USB standardized plugging any device into any computer.
Before MCP, connecting 5 AI apps to 10 tools meant 50 custom integrations. After it: 10 servers, 5 clients, done. The standard was adopted rapidly across the industry and became the practical skill for anyone building agents that talk to the outside world — whether you consume ready-made servers or write one for your own tools.
You know agents need tools. The question is: where do the tools come from? If every developer wrote their tools in a different format for each app, nothing would work with anything. MCP says: let's agree on one format — a tool is described one standard way, and any app that understands that way can use it immediately.
Like USB-C ports: every device used to have its own charger and cable, and the drawer filled up with them. Today any charger charges any device because everyone agreed on one standard. The MCP server is the 'device,' the MCP client is the 'port,' and the protocol is the agreed plug shape.
Want your AI assistant to read GitHub issues? There's a ready GitHub MCP server: you connect it to the app, the app auto-discovers its tools (list issues, create PR…), and the model starts using them — without you writing a single line of GitHub API integration.
The picture has three roles: the Host is the app the user sees (like Claude Desktop or an IDE), with the model inside. The Client is the component inside the host that holds one connection to each server. The Server is a small program wrapping a tool or data source and advertising its capabilities. The host asks each server 'what have you got?', collects the tools, and presents them to the model — and when the model requests a tool, the client sends the request to the server and returns the result.
The protocol is built on JSON-RPC; servers run locally over stdio or remotely over HTTP. A server exposes more than tools — also resources (readable data) and prompts (ready templates). Key note: the model itself knows nothing called MCP — the host translates MCP tools into the model's ordinary tool-calling format.
🧪 Try it: connect a ready MCP server (like the official filesystem server) to any MCP-supporting host, then ask the model to do something with its tools — say, summarize a file from a folder. Watch the three roles in action: you're in the host, the client opened the connection, the server did the reading. Then open the host's settings and see how the discovered tools are named.
A common mistake: believing MCP 'gives the model new capabilities.' It doesn't — it only standardizes how capabilities are connected; the same tool via MCP or direct integration does the same thing. Second mistake: connecting any server off the internet with blind trust — a server is code running with permissions, and choosing one is a security decision, not a detail.
Use MCP when you want your tool to work with more than one AI app (write it as a server once), or when a trusted ready-made server exists for the service you need — consuming it beats building an integration from scratch.
If you're building one agent talking to one internal API and won't reuse the tool anywhere else, direct integration (a plain function in your code) is simpler and faster — the protocol is an extra layer you earn back only with reuse or a broader ecosystem.