Model Context Protocol (MCP) Explained for Builders

If you've built anything with LLMs in the last year, you've hit the same wall I have: the model is brilliant in the abstract and useless about your data. It can't read your database, hit your internal API, or open your files. So everyone writes the same glue code — a bespoke adapter between the model and each tool — over and over, in every project, in a slightly different way.

The Model Context Protocol (MCP) is the standard that makes that glue reusable. This is the explainer I give people when they ask "what's the deal with MCP?"

The one-sentence version

MCP is an open protocol for connecting LLM applications to tools and data sources through a common interface. Anthropic introduced it and open-sourced it, and the ecosystem ran with it fast.

The analogy that stuck: MCP is a USB-C port for AI applications. Before USB-C, every device had its own connector. After, one port talks to everything. MCP is that for the model-to-world connection.

Why it caught on so fast

Standards usually die on the vine. MCP didn't, for a few reasons:

It solved a real, universal pain. Everyone was writing tool adapters. A shared format meant you write a server once and any MCP-aware client can use it.
The timing was right. Agents were taking off, and agents are only as good as their tools. MCP arrived exactly when the tool problem became everyone's problem.
It's genuinely open. Open spec, open SDKs, and adoption across multiple clients and IDEs — not a single-vendor lock-in play.

The result: a growing library of off-the-shelf servers for GitHub, databases, file systems, search, and hundreds of SaaS tools — that you can plug into instead of building.

The mental model

There are three roles:

Host / client — the LLM application (a chat app, an IDE, an agent). It speaks MCP.
Server — a small program that exposes capabilities over MCP. You write these, or use existing ones.
Transport — how they talk: stdio for local servers, or HTTP/SSE for remote ones.

A server exposes three kinds of things:

Tools — actions the model can invoke (create_issue, query_db, send_email). These are the workhorses.
Resources — data the model can read (files, records, documents). Think GET-style, read-only context.
Prompts — reusable prompt templates the server offers to the client.

The clean separation between tools (do something) and resources (read something) is one of the quietly smart design decisions. It maps to the difference between a side-effecting action and a safe read.

A minimal server

Here's the shape of an MCP server in TypeScript — deliberately tiny, because the point is how little ceremony there is:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "orders", version: "1.0.0" });

server.tool(
  "get_order_status",
  { orderId: z.string() },
  async ({ orderId }) => {
    const order = await db.orders.find(orderId);
    return {
      content: [{ type: "text", text: order ? order.status : "not found" }],
    };
  }
);

That's a real, usable tool. Any MCP client can now discover get_order_status, see its schema, and call it. You didn't write any model-specific code — the protocol handles discovery and invocation.

How it changes how you build

Before MCP, adding a capability to an agent meant editing the agent. After MCP, you stand up a server and point the agent at it. That decoupling is the whole game:

Reuse across projects. Your internal "company API" server works in your chat app, your IDE, and your CI bot — write once.
Reuse across the ecosystem. Need GitHub access? There's a server for that. Postgres? Done. You assemble rather than build.
Security boundary. The server is where you put validation, auth, and rate limits — not scattered through prompt logic. The model only ever sees the narrow, validated interface.

This is exactly why MCP pairs so well with building production agents: the agent's tool surface is a set of MCP servers, and good tool design is most of what makes an agent reliable.

Where it fits in the bigger picture

MCP isn't an agent framework, a model, or an orchestration library. It's the connective tissue. You still bring your own loop, your own model, your own evals. MCP just standardizes the boundary between "the model's reasoning" and "the outside world."

That narrow scope is a feature. The protocol does one thing and stays out of the way of everything else — which is why it composes with whatever stack you already have.

If you want the wider context on where Anthropic is taking this — Claude's latest models, MCP, and agent skills — I covered that in a separate post.

Should you use it?

If you're wiring an LLM to anything real — yes, almost certainly. Even for a single project, MCP gives you a clean, testable tool boundary and access to a large library of pre-built servers. The cost to adopt is low and the lock-in is near zero because the spec is open.

The one caveat: for a trivial one-tool prototype, a direct function call is still simpler. MCP earns its keep the moment you have more than one tool, more than one client, or any intention of reusing your integrations.

Common mistakes when adopting MCP

A few things I've seen trip people up, so you can skip the lesson:

Exposing tools that are too broad. A run_query(sql) tool hands the model a loaded gun. Narrow, validated, intention-revealing tools (get_orders_by_customer) are safer and the model uses them more accurately.
Forgetting that tool output is untrusted. If a server returns web or user-controlled content, that content can carry a prompt injection. Treat everything coming back through a tool as data, never as instructions.
Putting business logic in the client. The server is the right home for auth, validation, and rate limiting. Keep the client thin and the boundary clean.
Skipping the resources/tools distinction. Read-only context should be a resource; side-effecting actions should be tools. Collapsing them muddies your security model.

Get those right and MCP stays the clean boundary it's meant to be, instead of becoming a new place for bugs to hide.

The takeaway

MCP won because it solved a problem every LLM builder had, with an open spec, at exactly the right moment. Learn the three roles (host, server, transport) and the three primitives (tools, resources, prompts), and the rest is detail. Stand up one small server today; you'll feel the difference the next time you start a project and your integrations are already there waiting.

Related reading

Anthropic's Latest: Claude Opus 4.x, MCP & Agent Skills
Building Production AI Agents in 2026
See the research and systems I've built on top of these primitives.