Every week a new acronym shows up in AI, and most don't survive six months. MCP (Model Context Protocol) is one of the ones worth understanding — not because it's trendy, but because it solves a real, annoying problem that anyone building AI agents knows by heart: connecting the model to real-world tools is a pain, and everyone keeps reinventing the wheel.
This is the no-nonsense guide. What it is, what it solves, when to actually use it — and when it's just extra complexity.
The problem MCP solves
An AI agent that only chats is a fancier chatbot. An agent that acts — looks up an order, generates an invoice, opens a ticket — is real software. I've written about this in the function calling guide: the difference between talk and product is the tools the model can trigger.
The problem is that, historically, every tool was wired up its own way. You write the code that describes the tool to the model, the code that runs it, the code that validates it — all bespoke, for that agent, in that project. Then you start another project and do it all over again. That integration with the same CRM you've already built three times? Again. Multiply that by dozens of tools and several agents and you end up with a swamp of integrations nobody reuses.
MCP goes straight at this: standardizing how an LLM discovers and uses external tools, so an integration built once serves any compatible agent.
The USB-C analogy
Before USB-C, every device had its own connector. One phone's charger didn't fit the next. USB-C didn't make the devices more powerful — it made the coupling standard, and suddenly one cable works for everything.
MCP is that for AI agents. Before: each AI "client" (an agent, an app, an assistant) connected to each tool "server" (your CRM, your database, your API) with its own wiring. After: the client speaks MCP, the server speaks MCP, and they understand each other with no bespoke code.
In practice, the protocol defines two ends:
- MCP server: exposes capabilities — tools (actions the model can run), resources (data it can read), and prompts (reusable instructions). Whoever owns a system (an ERP, a knowledge base) writes an MCP server once.
- MCP client: the agent/application side. It discovers what the server offers and makes it available to the model in a standardized way.
The payoff is composition: connect one client to many servers, or many clients to the same server, without rewriting the glue every time.
MCP doesn't replace function calling — it organizes it
This is where the most common confusion lives. MCP and function calling are not competitors.
- Function calling is the model's ability, mid-conversation, to say "I want to call the
get_ordertool with this argument." It's the model's reasoning choosing to act. - MCP is the standard for how that tool is described, discovered, and exposed. It's the socket; function calling is the decision to plug in.
You still need function calling. MCP just makes the tool the model calls come from a standardized place instead of bespoke wiring. All the discipline I preach about tools still applies — and it's worth repeating:
The model executes nothing. It decides what to call; the one that runs it, validates, and confirms is your code, on your side. MCP standardizes the transport, not the responsibility. An MCP server that runs an irreversible action with no validation and confirmation is as dangerous as poorly done function calling. The protocol won't save you from bad architecture.
When to use MCP (and when not to)
I'm a stickler about this because I've watched projects die from complexity adopted too early. MCP is a tool, not a religion.
It's worth it when:
- You have lots of tools and want to reuse them across agents/projects without rewriting the glue.
- You want to plug in ready-made third-party servers (an MCP server that already talks to a given system) instead of integrating from scratch.
- You're building a platform where tools come and go, and a standard prevents the chaos of N ad-hoc integrations.
- You want the same set of tools to serve different clients (a desktop assistant, a WhatsApp agent, an internal app).
It's probably overkill when:
- Your agent is small and focused, with three or four tools only it uses. Direct integration with function calling is simpler, and you don't pay the protocol's infrastructure cost.
- You have a single integration and no plans to reuse it. Standardizing a one-off is ceremony with no return.
- Your project's bottleneck isn't integration — it's scope definition, conversation quality, or the business decision. MCP solves none of those.
The question I ask: how many times am I going to reuse this tool? If the answer is "once," direct integration. If it's "many times, in different places," the standard starts to pay for itself.
What MCP changes day to day for builders
Less glue, more reuse. A well-built MCP server for your ERP becomes an asset: the next agent that needs to talk to the ERP already has the socket ready. That shortens the path between the idea and the shipped product — which is, in the end, what matters.
But there's a cost. You add a layer (client + server, transport, discovery) that has to be operated, versioned, and monitored like any infrastructure. In production, that means the same questions as always: what happens if the MCP server goes down? How do you log what each tool did? How do you validate the action before running it? The protocol standardizes the plumbing; resilience is still your job — just like what I described in the architecture of agents that survive production.
The honest summary
MCP is a useful standard that solves a real problem: the mess of bespoke integrations between LLMs and tools. It's the USB-C of agents — it standardizes the coupling, not the intelligence. It doesn't replace function calling; it organizes where the tools come from. It shines at scale and reuse; it's dead weight in a small, one-off agent.
Like every new technology, the mistake isn't to ignore it or embrace it blindly — it's adopting it without asking what problem of mine does this solve today. If you have lots of tools to reuse, it's worth studying. If you're still fighting to get your first agent live, solve the first agent. The standard will be there when scale arrives.
I build AI agents that act in production — with or without MCP, always with the real integration and validation the real world demands. If you have tools and systems to connect to an agent, let's talk.