What MCP is in one line: the Model Context Protocol is an open standard Anthropic shipped in November 2024 so any AI model can connect to your tools and your data through one cable, instead of a custom connector per integration. It lowers the cost of connecting. It doesn’t lower the cost of having a bad process or dirty data. That’s the whole thesis — the rest of this piece backs it up without smoke.
What is MCP (Model Context Protocol)
MCP stands for Model Context Protocol. It’s an open protocol —public spec and code— that defines a standard way for an AI application to request context (files, database records, messages) and invoke actions (tools, functions) against external systems. The analogy everyone repeats is "USB-C for AI": one plug for everything. It’s useful to grasp the idea and misleading if you buy it whole, because a plug doesn’t fix what’s on the other end of the cable. The spec and official SDKs live in the MCP documentation.
The real problem it solves: N×M integration
Before MCP, wiring each model to each tool was a bespoke connector. With N models and M tools you end up with N×M integrations to maintain, each with its own format, its own auth and its own way of breaking. MCP turns that N×M into N+M: each tool exposes an MCP server once, each model speaks MCP once, and in the middle there’s a common contract. It’s not magic — it’s what a universal charger did for the drawer of cables. The saving is on integration, not on judgment.
| Axis | Without MCP (bespoke connectors) | With MCP |
|---|---|---|
| Cost to integrate | N×M custom connectors | N+M (one protocol) |
| Format | A different one per tool | Standard JSON-RPC |
| Maintenance | Every change breaks a connector | The contract absorbs the change |
| Reuse | Almost none across projects | One server serves many clients |
| What it does NOT solve | Process and data | Process and data |
How it works: client, server and three primitives
The architecture is client-server, inspired by the Language Server Protocol code editors already use. The AI application acts as an MCP client and opens a connection to one or more MCP servers, which expose real-world capabilities. Messages travel as JSON-RPC 2.0 over various transports. What a server can offer boils down to three primitives:
- Tools: actions the model can invoke —open a ticket, look up an order, move a row—. This is what most people mean by "the agent does things".
- Resources: data the model can read as context —a document, a query result, a file—. Read, not act.
- Prompts: reusable interaction templates the server offers the client for repeated tasks.
There are official SDKs in TypeScript, Python, Java, Kotlin and C#, so standing up an MCP server today is a matter of hours, not weeks. And that’s the comfortable trap: because it’s easy to build, it’s tempting to think the work is done when it has actually just begun.
Who adopted it (and why that matters)
MCP stopped being an Anthropic thing fast. Through 2025 it was natively adopted by clients from OpenAI, Google and Microsoft, among many others, and by year-end Anthropic donated the protocol to a foundation under the Linux Foundation umbrella with those same players as founding members (first-anniversary recap). A standard held up by competitors instead of a single owner is exactly what makes it safe to bet on: you’re not depending on one company staying interested. For a company deciding where to invest, that shared governance weighs more than any demo.
What actually changes for enterprise agents
The concrete part: the glue between your agent and your systems stops being an integration project per tool and becomes a reusable piece. Connecting an agent to your CRM, your ERP or your database no longer justifies a five-figure budget on its own. That’s real and it’s good. We walk through it in the guide on connecting an AI agent to your CRM, where the cable matters less than deciding what the agent can touch and what it can’t.
But connecting isn’t the same as building. An MCP server gives you access; you still need the agent that decides well what to do with that access, with its guardrails, its evals and its human in the loop where judgment matters. That part —the one that actually does the work— isn’t solved by the protocol, and it’s the one we break down in how to build an AI agent that ships to production.
What an MCP server does NOT fix
This is where the excitement crashes into a real Tuesday. An MCP server connects the model to your data exactly as it is. If the process behind it is a mess, MCP hands you a mess accessible by API — faster, not better. Three fronts the protocol doesn’t touch:
- The process. If nobody has decided how the work is done today —who touches it, where it jams, what criteria decide—, MCP just automates the disorder. That diagnosis is half the work, and it’s what separates automating a process with agents from buying tech and praying.
- The data. An MCP server over duplicated, ownerless, undefined data serves answers that are confident and wrong. Data quality isn’t set by the protocol; you set it first.
- Governance. What the agent can read, what it can write, who answers when it’s wrong. MCP moves the context; it doesn’t decide permissions for you. Without that layer, a universal plug is also a universal hole.
When building an MCP makes sense (and when it’s theatre)
- You’ve mapped the process. You know the specific task the agent will touch and the metric that should move. If it doesn’t fit in two sentences, it’s not protocol time yet.
- You’ll reuse the connection. An MCP server pays off when several agents or teams will use it. For a one-off, throwaway integration, a direct connector is sometimes more honest.
- You’ve decided governance. Permissions, limits and an owner before you open the cable, not after the first scare.
- You’re not building it for the demo. If the goal is to show a meeting that "we already speak MCP", that’s theatre with a technical name. The system is judged on an ordinary Tuesday, running on its own, not in the room.
Put another way: MCP is very good news for whoever already did the work inside, and an expensive trap for whoever thought the cable was the problem. We use MCP where it saves weeks of integration, and we don’t use it to dress up a process that doesn’t exist yet. If the pain is connecting AI to the systems you already run and leaving it measured, that’s AI infrastructure for the enterprise; if it’s a specific case —say, putting AI inside HubSpot without breaking anything—, see AI for HubSpot. The protocol is the means. The work, as always, is what gets charged for.