MCP (Model Context Protocol) Explained: The Standard for AI Tool Use
MCP has come up repeatedly in this blog’s agent articles, yet there was never a post explaining MCP itself. This post fills that gap. The conclusion up front: MCP (Model Context Protocol) is an open standard protocol connecting LLM applications to external tools and data. Anthropic released it in November 2024; OpenAI, Google, Microsoft, and AWS adopted it through 2025, and as of 2026 it is the de facto standard in this space. Using it in an app is covered in LLM App Development #11, building your own server in AI Agent Development #6 — this post is the concept piece that belongs in front of both.
The problem it solves: N×M becomes N+M #
Before MCP, every tool integration was bespoke. If an app needed Slack, GitHub, and an internal database, each connector was coded for that app — and the next app rebuilt the same connectors. The result was integration code proportional to N apps × M tools.
MCP inserts a standard interface in between. On the tool side, build an MCP server once and every MCP-supporting app can use it; on the app side, implement an MCP client once and it connects to every MCP server. Turning N×M into N+M is the protocol’s reason to exist.
This also settles its relationship to function calling. Function calling is “the model’s ability to emit a tool call in a defined schema”; MCP is “the standard for who provides that tool and how it is discovered.” They are not competitors — they sit on different layers. The model still invokes tools via function calling; MCP supplies the tool catalog in a standard way.
The structure: hosts, clients, servers, and three primitives #
- Host: the LLM app the user faces — a desktop assistant, an IDE, an agent runtime.
- Client: the component inside the host that manages one connection to one server. A host attached to three servers runs three clients.
- Server: the side exposing tools and data. A filesystem, GitHub, database queries, a wrapper around an internal API — anything you want to make usable by a model becomes a server.
What a server exposes falls into three kinds:
| Primitive | What | Who drives it |
|---|---|---|
| tools | Actions the model invokes (search, create, send) | The model decides to call |
| resources | Read-only data (files, schemas, documents) | The app supplies as context |
| prompts | Reusable prompt templates | The user selects |
There are two transports: stdio, spawning the server as a local process (the default for filesystem and dev-tool integrations), and streamable HTTP for remotely deployed servers (organization-wide sharing, SaaS integrations). Remote authentication is standardized around OAuth.
As of 2026: how it became the de facto standard #
- Nov 2024: Anthropic released it as open source.
- 2025: OpenAI (March, Agents SDK), Google (April, Gemini SDK), Microsoft (Copilot Studio, Windows), and AWS (Bedrock) added support one after another, shedding the “one vendor’s protocol” label.
- Jan 2026: Anthropic transferred MCP to a foundation under the Linux Foundation. With governance neutralized, the last blocker for enterprise adoption was cleared.
- Scale: the official registry counts on the order of ten thousand servers as of mid-2026, with community indexes several times larger. The spec keeps revising under date-based versions (e.g. 2025-06-18), so check the target version when updating SDKs.
Security: the attack surface standardized along with the convenience #
The risks to review are those of tool integration in general — but easier connections mean you hit them more often.
- Third-party server trust: being in a registry does not mean being safe. Servers supply tool descriptions to the model, and attacks that steer model behavior through malicious descriptions (tool poisoning) have been demonstrated. Attach only servers with verified provenance and maintain an internal approved list.
- Prompt injection: the model following instructions embedded in tool results — web pages, issue bodies, emails. Not an MCP-specific flaw but a problem for every tool-using agent; the practical defense is human approval gates on sensitive actions (writes, sends, deletes).
- Least privilege: start server credentials read-only and minimally scoped. “Just use the admin token for now” is the most common incident path.
- Context bloat: every attached server’s tool definitions eat context, taxing both cost and accuracy. Operate with only the servers a task needs enabled.
Adoption call: when it pays and when it doesn’t #
If one app uses three or four tools, wiring them directly with function calling is simpler than adopting MCP. MCP earns its keep in these cases:
- The same tools across multiple clients: if the same internal tools should work in an IDE, a desktop assistant, and your own agent, one server covers all of them.
- Sharing tools within an organization: instead of every team rebuilding the same connectors, manage an internal MCP server catalog as a standard asset.
- Leveraging the third-party ecosystem: attach existing servers (GitHub, databases, search) and gain tools without writing them.
- Shipping an agent as a product: if users must connect their own tools, there is effectively no alternative to the standard protocol.
Summary #
- MCP is the open standard connecting LLM apps to tools and data. It reduces the N×M integration problem to N+M: one server, one client.
- It does not compete with function calling. Function calling is the model’s output capability; MCP is the standard for supplying tools.
- The structure is host, client, server; servers expose tools, resources, and prompts. Local runs on stdio, remote on streamable HTTP with OAuth.
- Major-vendor adoption in 2025 and the foundation handover in early 2026 made it the de facto standard. The spec keeps revising under date versions.
- Third-party server trust, prompt injection, and least privilege are the axes of a security review. For a single app with a handful of tools, not adopting it is also a correct answer.