MCP (Model Context Protocol), Explained From Zero

Once you have more than one AI assistant and more than one tool, a practical problem appears: how do you connect them all without building a tangle of one-off integrations? The Model Context Protocol is the industry's answer, and it spread remarkably fast because it solves that problem the way every other part of computing eventually does — with a standard. This guide starts from nothing and builds up what MCP is and why it matters.

1 · The messy world before a standard

Say your company builds a support assistant, a coding assistant, and a research assistant, and each needs to reach the same systems — your database, your ticketing system, your file store. Without a standard, every team wires up every connection by hand, in its own way. Three assistants times five tools is fifteen custom integrations, each built differently, each maintained separately, each breaking on its own schedule. It's a tangle of one-off wiring, and when a new tool appears, every assistant must be updated individually to use it. This is exactly the kind of mess that, everywhere in computing, eventually gets solved by agreeing on a standard — and MCP is that standard for AI tools.

2 · MCP is a shared plug shape

The Model Context Protocol is an agreed way for an AI assistant to connect to tools and data sources, so that instead of custom wiring for every pair, everyone speaks the same language. The comparison people reach for is USB-C. Before USB-C, every device had its own charger and cable; afterwards, one plug shape fits everything. MCP is the USB-C moment for AI tools: agree on the plug shape once, and any assistant that speaks MCP can connect to any tool that speaks MCP — without either side knowing the other's specifics in advance. So MCP isn't a new AI capability on top of tool calling; it's a standard for how the connection is described and made, so those connections become reusable and shareable instead of one-off. That single idea — standardise the plug — is what untangles the mess.

3 · Two sides: client and server

MCP has two sides, and the names are worth getting straight. On one side is the server: a small program that wraps a specific tool or data source — your database, your file system, a third-party service — and exposes it in the standard MCP way. On the other side is the client: the AI assistant, or the app hosting it, which knows how to talk MCP. When the client connects, it can ask the server what it offers — “what tools do you have, and what inputs do they need?” — and the server answers in the standard format. This discovery step is the heart of it: the assistant doesn't need those tools hard-coded in advance; it learns them at connection time. So the server publishes a menu, the client reads it, and the assistant suddenly knows a new set of tools it can request — the tool-calling menu from the last topic, delivered over a standard connection rather than wired in by hand.

4 · Build once, everyone reuses it

Here's the payoff that makes MCP worth caring about. Because the connection is standard, you build a server once and every MCP-speaking assistant can use it. Wrap your database in one MCP server, and your support, coding, and research assistants can all connect — no custom integration per assistant. That fifteen-integration tangle collapses into a handful of reusable servers. Even better, an ecosystem grows: other people publish MCP servers for common systems — file systems, code repositories, popular services — and you plug your assistant into them without writing the connector yourself. It flips the economics. Instead of every team rebuilding the same plumbing, connectors get built once and shared, the way libraries and packages are shared in ordinary software. Build once, reuse everywhere — that's the quiet superpower a standard unlocks.

5 · Tools and resources: actions and data

MCP servers offer more than actions to run. They can also expose data — documents, records, files — the assistant can read as context. In MCP terms, a server can provide both tools, which are actions the assistant can request, and resources, which are pieces of content it can pull in to inform its answer. So a single server for your document store might let an assistant both search the documents (an action) and read a specific one (a resource). This ties neatly back to what we've learned: the resources side connects to retrieval and context, feeding the model the right information; the tools side connects to tool calling, letting it take action. MCP wraps both in one standard connection — which is why it's called the Model Context Protocol: a standard way to give a model everything it needs from the outside world, whether information to read or actions to perform, through the same tidy plug.

6 · The same safety rules still apply

A standard plug doesn't change the safety story — it makes it more important, because connecting becomes so easy. Everything from the tool-calling topic still holds. Trust: an MCP server is a real program with real access, so connect only to servers you trust, exactly as you'd vet any dependency; a malicious server could expose harmful tools or leak data. Least privilege: a server should grant only the access genuinely needed — a read-only document server shouldn't also delete files. Confirmation: actions that change data or cost money still deserve a human check before they run. And prompt injection still lurks — content pulled through a server as a resource is outside text that might try to manipulate the model, so treat it as untrusted. MCP standardises the connection, not the trust. The convenience is wonderful; the responsibility to control what each connection can reach is still entirely yours.

7 · Where MCP fits in the bigger picture

Place MCP in the story. Tool calling, from the last topic, is the raw ability for a model to request actions and receive results. MCP is a standard for how those tools and data sources are described and connected, so they become reusable and shareable rather than hand-wired one at a time. And the topics ahead — context engineering and agent memory — are about orchestrating all of this into assistants that reliably accomplish real goals. You can absolutely do tool calling without MCP, wiring each connection yourself; MCP just makes it scale gracefully across many assistants and many tools. Think of it as the layer that turns a pile of individual tool integrations into a clean, plug-and-play ecosystem. As AI assistants become common inside organisations, this standardisation is what keeps the whole thing from collapsing back into the tangle we started with.

8 · A simple test you can run this week

9 · Glossary — every term, spelled out

MCP (Model Context Protocol)

A standard for connecting AI assistants to tools and data sources — the “USB-C for AI.”

MCP server

A program that wraps a tool or data source and exposes it in the standard MCP way.

MCP client

The AI assistant, or its host app, that speaks MCP and connects to servers.

Discovery

The step where a client asks a server what it offers, so tools don't need hard-coding.

Tools (in MCP)

Actions a server exposes that the assistant can request.

Resources (in MCP)

Pieces of content a server exposes that the assistant can read as context.