What is the Model Context Protocol (MCP)? MCP is an open protocol for connecting AI assistants to external tools and data, released by Anthropic in November 2024. It defines a standard server-client contract so any compatible AI can talk to any compatible tool without bespoke integration code on either side.
The natural question: isn’t this just an API with extra steps? Structurally, MCP and APIs are similar. Both are contracts between software. The difference is that MCP defines a single protocol every server implements the same way, while every API on earth has its own conventions. For AI models that distinction is the difference between “plug in a new tool” and “write custom integration code.”
Why does every API feel different?
An API is a defined interface that one program offers to others. It specifies what operations are available, what data those operations expect, and what they return. Stripe’s API exposes operations like createCharge. Slack’s exposes sendMessage. Your bank’s exposes getBalance. The function names, authentication scheme, request format, error codes, and pagination behavior differ in every API on the planet. No central authority defines how an API should look. Every team makes its own choices.
That’s tolerable when humans are the integrators. A developer reads the docs once, writes the integration once, and ships it. The cost of fragmentation is paid in developer time, and it’s bounded.
What does an MCP server expose?
An MCP server exposes three things: tools (operations the AI can invoke, like send_email or query_database), resources (data the AI can read, like documents, database rows, or API responses), and prompts (reusable templates that shape how the AI interacts with the server). An MCP client, embedded in an AI app like Claude or ChatGPT, connects to the server and surfaces those capabilities to the model in a format the model is trained to use.
The standardization is the point. Every MCP server, regardless of what it wraps, is described in the same schema. The model doesn’t learn the Slack server differently from the GitHub server. Same protocol, same shape, same expectations.
Where do MCP and APIs overlap?
Most MCP servers are wrappers around existing APIs. The Slack MCP server calls the Slack REST API. The Google Drive MCP server calls the Drive API. MCP doesn’t replace the API; it adds an AI-consumable surface on top of it. Both are contracts. Both define operations, inputs, and outputs. Both cross network boundaries.
How do MCP and APIs differ?
Four practical differences:
Audience. APIs are designed for human developers reading documentation. MCP is designed for AI models receiving structured tool descriptions and choosing among them at runtime.
Uniformity. APIs have no shared spec. Each provider invents its own auth, schema conventions, error formats, and pagination. MCP defines all of that once. A client that speaks MCP can talk to any compliant server with no custom code.
Direction. Most APIs are stateless request-response. MCP is bidirectional. Servers can stream progress for long-running operations, send notifications, and even ask the client to run a model call on the server’s behalf, a feature called sampling.
Discovery. With an API, a developer reads the docs and decides what to call. With MCP, the model receives a structured list of available tools at session start and decides at runtime.
| API | MCP | |
|---|---|---|
| Primary consumer | Human developer at design time | AI model at runtime |
| Spec | Per-provider, no common standard | Single open spec across all servers |
| Communication | Request/response | Bidirectional, with notifications and sampling |
| Tool discovery | Read docs, hard-code | Model queries server, decides at runtime |
| Switching models | Rewrite the integration | Server is unchanged; new client connects |
What problem does MCP solve?
Every AI application that wanted to give a model access to outside tools used to face the same combinatorial problem. Every model had its own function-calling format. Every tool had to be wrapped in code specific to whichever model would call it. Anthropic named this the N×M problem: with N AI applications and M tools, you needed N×M integrations to maintain. Switch one model, rewrite all the wrappers attached to it.
MCP collapses N×M to N+M. Each AI application implements the protocol once. Each tool implements the protocol once. The matrix becomes a sum.
What can MCP do that wasn’t possible before?
Three concrete things, in roughly increasing importance.
Plug-in tool ecosystems. Adding a capability to an AI assistant becomes installation, not engineering. Drop in an MCP server, the model sees its tools, the assistant uses them. Thousands of servers have shipped since launch, covering Drive, GitHub, Postgres, Linear, and a long tail of internal and niche systems.
Model portability. The integration lives in the MCP server, behind the standard interface, not inside the AI application. Switch from one model provider to another and your tools come with you.
Composition. Every server speaks the same protocol, so a model can chain operations across servers in a single session. Query Postgres, transform the result, post to Slack, log the run, all in one flow with no custom orchestration code.
How did we get to MCP?
Function calling became standard in mid-2023. That capability let models take actions instead of just producing text, but every provider invented its own format. OpenAI’s tool schema, Anthropic’s, and Google’s were mutually incompatible, so tool integrations had to be written multiple times for the same task.
Anthropic released MCP as an open standard in November 2024 with reference servers for Drive, Slack, GitHub, Git, Postgres, and Puppeteer. Adoption was unusually fast for a protocol. OpenAI committed to support in early 2025. Google DeepMind followed. By 2026, MCP is the default substrate for connecting agents to tools, and most major AI applications support it natively.
What does MCP mean for businesses?
The cost of giving an AI access to your existing software is collapsing. Integrations that used to be custom development projects are becoming installable components. If your CRM, accounting platform, or file storage exposes an MCP server, plugging an AI into your operations is closer to installing software than building it.
That changes the calculus on a lot of AI projects. Workflows that didn’t justify a custom integration twelve months ago might justify a thirty-minute setup today. The bottleneck moves from “can we connect this?” to “what should we build with the connection?”
Get in touch if you want help thinking through where the connections are worth making, or take the AI Readiness Scorecard for a quick self-assessment.