mcp model context protocol
The Model Context Protocol solves an integration-counting problem: without a shared standard, connecting M different AI applications to N different tools and data sources requires something close to M times N custom integrations, since each application's tool-calling implementation and each tool's API are both one-off. Anthropic introduced MCP in late 2024 as an open standard specifically to collapse that multiplication — a tool built once as an MCP server works with any MCP-compatible application, and an application that speaks MCP can use any MCP server, without either side writing integration code specific to the other. The protocol has since been described as "USB-C for AI applications," the same comparison that made the earlier shift from dozens of proprietary charging connectors to one standard port intuitive.
MCP's architecture splits cleanly into three roles: host, client, and server, each with a distinct job. The host is the AI application itself — Claude Desktop, an IDE, a custom agent — that manages the overall interaction and user context. The client is the protocol-aware component living inside the host that discovers what a given server can do and invokes its capabilities on the host's behalf. The server exposes capabilities from some external system — a database, a filesystem, an API — in MCP's standardized format, with no awareness of which specific host is calling it. This separation is what makes the N-times-M reduction actually work in practice: a host only needs to implement the client side of the protocol once, and from then on it can talk to any server at all, rather than needing bespoke integration code for every new tool.
The protocol distinguishes four capability types rather than treating every server feature as an undifferentiated "tool." Tools are actions a server can perform — run a query, call an external API, write a file. Resources are structured data a server exposes for the model to read, like the contents of a specific document or database table. Prompts are reusable interaction templates a server provides, so a common workflow doesn't need to be re-specified by every client that wants to use it. Sampling is a less common but distinctive capability: it lets a server itself request a model completion through the host, inverting the usual direction where only the host calls out to servers. Separating these four types, rather than collapsing everything into generic function calling, is what lets MCP standardize validation and tooling around each category specifically rather than treating every integration as the same undifferentiated shape.
Scoped permissions and explicit approval flows are what keep MCP's convenience from becoming a security liability. Because a server can expose write-capable tools — sending an email, modifying a database, executing a shell command — a host that trusts every connected server with broad default access turns a convenience integration into an open door for prompt injection to cause real damage: malicious content a model reads could instruct it to invoke a tool the user never intended. Production MCP deployments scope permissions per server and per capability rather than granting blanket trust, require explicit approval for sensitive or write-capable actions, and log capability invocations with their parameters and the identity context that triggered them — the same defense-in-depth principle that applies to any system where an LLM can be steered by content it reads into taking an action the user didn't ask for.
MCP's distinguishing bet, relative to a model provider's own native function calling, is vendor neutrality rather than any difference in the underlying mechanism. OpenAI's function calling and Google's extension patterns both let a model invoke external tools, but each ties the integration work to that specific provider's API conventions — a tool built for one doesn't transfer to the other without rewriting. MCP's standardized contract means a server built once can, in principle, serve any MCP-compatible client regardless of which model provider's application is hosting it, which matters specifically for organizations running multiple models or switching providers over time, where provider-specific integration work would otherwise need to be duplicated or redone with every change.
Read MCP as solving the same problem every successful interface standard solves: not making any single integration smarter, but making the cost of adding the next integration roughly constant instead of growing with the size of the ecosystem — the value compounds precisely because it's a shared contract rather than a better implementation of any one connection.