The Model Context Protocol is the USB-C moment for AI tools. Here is what it actually is, how it works, and where it breaks.
Two years ago I built the same thing six times. A client would say "connect our LLM assistant to our CRM," and I would sit down and write the plumbing: a function schema for the model, a Python adapter for the CRM API, a loop that executed calls and fed results back, plus authentication, retries, and logging. Six different clients, six different CRMs, six different codebases — and every single one was the same engineering problem wearing a different logo.
When Anthropic released the Model Context Protocol in late 2024, I remember reading the spec on a flight and realizing it was aimed directly at that exact pain. Not a tool, not a library — a standard for how AI applications connect to the data and systems around them. The kind of thing that only becomes obviously necessary after you have written the same glue code enough times to feel it in your hands.
So what is MCP, actually, and does it live up to the hype? Let me break it down the way I had to, for myself.
Before MCP, connecting an AI model to a tool meant an N×M integration problem. For every model/framework you use (your app, your agent, your IDE assistant) and every system you want it to reach (a database, a ticketing API, a file system), you write custom code. Your OpenAI assistant has one integration for the CRM, one for email, one for the ticketing system — each hand-built, each with its own auth, its own schema, its own error handling. Every new model vendor means redoing all of it. Every new tool means writing it all again.
MCP inverts the topology. Instead of N×M integrations, you get N+M: each tool exposes itself once, behind the protocol, and every client that speaks the protocol can use it without knowing anything about the underlying system. It is the difference between a charger with a proprietary port for every device and a USB-C port on everything.
This is the core insight and the reason the protocol matters: MCP standardizes the interface between AI applications and the tools they use, the way SQL standardized the interface between applications and databases. Once a tool speaks MCP, it works with every client that speaks MCP — no per-client rewrite.
MCP has a small, learnable vocabulary, and that is a feature. Everything you will ever do with it is one of three things:
And the servers expose exactly three kinds of capability:
That is the whole model. Tools for acting, resources for reading, prompts for starting. Everything else in the spec is transport, security, and bookkeeping.
Resources and prompts get less attention than tools, so let me give them their due. A resource is how a server hands the model context without making it call a function first — say the latest campaign brief, a set of policy documents, or a database schema. The client can fetch a resource and inject it into the model's context automatically, which is exactly the retrieval step in a RAG system, standardized. A prompt is a reusable template the user or client can trigger — "summarize this ticket," "write a PR description from these changes." The server supplies the template and the required parameters; the client fills them and runs it. Both capabilities exist so that servers can contribute not just actions but context and workflows, and they matter more than the marketing suggests, because they are the difference between a tool that needs the model to know what to ask for and a system that brings the right context to the model on its own.
Here is the shape of a real MCP exchange, end to end:
┌────────────┐ 1. connect + initialize ┌────────────┐
│ │ ─────────────────────────▶ │ │
│ MCP Client │ 2. list tools/resources │ MCP Server │
│ (your app)│ ◀───────────────────────── │ (a tool) │
│ │ 3. model picks a tool │ │
│ │ ─── tool call ───────────▶ │ │
│ │ 4. server executes + │ │
│ │ 5. result streams back ◀── │ │
└────────────┘ └────────────┘
The lifecycle is deliberate. First the client and server handshake and negotiate versions and capabilities. Then the client asks what the server can do and gets back a list of tools with their schemas — this list is what the model sees and decides against. When the model calls a tool, the client forwards the request, and the server can stream progress and partial results as it works (long-running tools report progress so the user is not staring at a spinner for thirty seconds).
The two transports matter for deployment, so choose deliberately:
I default to this rule: local, single-user, dev-time tools on stdio; anything shared, remote, or user-facing on HTTP.
The protocol is JSON-RPC 2.0 under the hood, and there are official SDKs in TypeScript, Python, and others that handle the protocol so you only write the tool logic. Here is the smallest server worth reading — a TypeScript server that exposes one tool that reads the latest rows from a Postgres table:
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
const server = new McpServer({
name: "sales-pipeline",
version: "1.0.0",
});
server.tool(
"latest_deals",
"Return the most recently updated deals from the pipeline.",
{ limit: z.number().int().min(1).max(100).default(10) },
async ({ limit }) => {
const rows = await db.query(
`SELECT id, name, amount, updated_at
FROM deals
ORDER BY updated_at DESC
LIMIT $1`, [limit]);
return {
content: [{ type: "text", text: JSON.stringify(rows) }],
};
}
);
const transport = new StdioServerTransport();
await server.connect(transport);
That is a complete tool, exposed through a standard interface, callable by any MCP client. The same server file can be wired to an HTTP transport with two lines of changes, and suddenly every MCP-capable app in your organization can talk to your sales pipeline without you writing a single integration for any of them. That is the payoff, made concrete.
A practical note on testing a server before wiring it into an app: the SDKs ship a lightweight inspection tool (for the TypeScript SDK it is npx @modelcontextprotocol/inspector
) that connects to your server and lets you list tools, inspect their schemas, and invoke them interactively. I run that before connecting any client — it catches the two bugs that otherwise burn an afternoon: a malformed JSON schema the client parses differently than you expected, and a tool that works in a unit test but times out on the real transport. Test the server in isolation first; debug against a live client second.
Two details in the protocol are easy to miss and matter in production. First, tool calls are asynchronous: the server can return progress notifications while a long task runs, so a client can show "processing, 40% done" instead of an indefinite spinner. Second, tool results can include structured content, not just text — a result can carry an image, a resource, or structured data, which means a code-review tool can return a diff and a weather tool can return a chart. Design your server results with this in mind: return the structured thing the client can render, not a formatted string you force the model to re-parse.
The strategic argument is not about today's code; it is about the compounding effect of a standard:
I am optimistic, but I am also the person who will get called when it misbehaves, so here is the honest list of problems:
writeFile
enabled and no confirmation. Do not be that team.For a single app talking to a single API, MCP is overhead. If your LLM needs one endpoint and one function schema, just call the API directly — a protocol layer adds process, transport, and debugging surface with zero benefit. MCP pays off when the integration is reused: multiple clients, multiple tools, a shared backend, or an ecosystem where you want to publish a capability. The rule: adopt MCP when you would otherwise write the same adapter twice. Otherwise, a direct call is the right call.
If you are wiring an application or agent to MCP, work through this list:
I am not usually early to standards — I have watched enough of them die to stay skeptical. MCP is different because it solves a problem I have personally paid for, repeatedly, and because it is already shipping in the tools people actually use. The moment your agent needs to reach outside itself — a database, a ticketing system, a file system, a browser — is the moment a protocol for that boundary stops being theoretical and starts saving you the same six weeks I spent, six times over.
Build one server. Point one client at it. You will feel the difference the first time a second client connects without you writing a single line of integration.
*Gulshan Yad