What Is MCP? Model Context Protocol Explained

The Model Context Protocol, or MCP, is the open standard that lets AI models like Claude read your files, query your databases, and trigger actions in tools like Slack or GitHub — without a developer having to hand-write a custom integration for every single one. Anthropic created MCP and open-sourced it in November 2024, and it has since become a shared standard that OpenAI, Google, and Microsoft all build against. Here is what MCP actually is, how it works, and what to watch for before connecting one to your own data.

What is the Model Context Protocol?

MCP is an open-source standard for connecting AI applications to external systems: data sources such as local files and databases, tools such as search engines and calculators, and workflows such as specialized prompts. According to the protocol's own documentation, MCP exists so that AI applications like Claude or ChatGPT can "access key information and perform tasks" that live outside the model itself.

The official docs use a now-common comparison: MCP is "like a USB-C port for AI applications." Just as USB-C gives any laptop a single, standardized way to plug into monitors, drives, and chargers, MCP gives any AI application a single, standardized way to plug into databases, code repositories, project-management tools, and local files — instead of every AI vendor and every data source negotiating its own one-off API integration.

MCP is deliberately scoped. It does not tell a model how to think, plan, or manage a conversation. Its specification states plainly that it "focuses solely on the protocol for context exchange — it does not dictate how AI applications use LLMs or manage the provided context." That separation is what allows MCP to sit underneath very different products: a chat app, a coding agent like Claude Code, or an enterprise chatbot, all speaking the same wire protocol to very different servers.

Who created MCP, and how has it evolved?

Anthropic built MCP internally and announced it publicly on November 25, 2024, in a post titled "Introducing the Model Context Protocol." The protocol's creators, credited by Anthropic and listed in MCP's own governance documentation, are David Soria Parra and Justin Spahr-Summers. Anthropic's announcement framed the problem directly: even the most capable models are constrained by their isolation from data, trapped behind information silos and legacy systems, and every new data source has historically required its own bespoke integration — an approach that does not scale.

At launch, Anthropic shipped three things together: the MCP specification and SDKs, local MCP server support built into the Claude Desktop app, and an open-source repository of pre-built servers for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer. Early adopters named in that announcement included Block and Apollo, with development-tool makers Zed, Replit, Codeium, and Sourcegraph also building MCP support into their platforms from the start.

The protocol's governance has since changed in a way that matters for anyone betting on it long-term: MCP is no longer solely an Anthropic project. Per MCP's own governance documentation, the project is now formally established as "Model Context Protocol, a Series of LF Projects, LLC" — meaning it sits under the Linux Foundation, with code and specification contributions licensed under Apache 2.0 and documentation under Creative Commons. Technical direction is set by an MCP Steering Group of Lead Maintainers, Core Maintainers, and Maintainers, with seats tied to individuals rather than to the companies that employ them. The GitHub organization that hosts the project also records that its official SDKs are co-maintained with outside companies: the Go SDK with Google, the C# SDK with Microsoft, and the Java SDK with Spring AI. That is a concrete, source-verifiable sign of how far MCP has moved from a single-vendor project toward shared industry infrastructure.

The protocol itself keeps shipping dated revisions. MCP's architecture documentation references a 2026-07-28 specification version in which several early client-side features — sampling, logging, and roots — were marked deprecated in favor of newer mechanisms, a sign of a standard that is still actively maturing rather than frozen at its 2024 launch state.

The problem MCP was built to solve

Before MCP, connecting an AI assistant to a new data source or tool typically meant writing a dedicated integration for that pairing of model and system. A team that wanted Claude to read from Postgres and also post to Slack needed two separate, non-reusable integrations; a team supporting multiple AI assistants against the same systems needed to repeat that work for every assistant. Anthropic's announcement describes this directly as a problem of fragmentation: "Each new data source requires its own custom implementation, making truly connected systems difficult to scale."

MCP replaces that N×M integration problem with a single protocol on both sides. A company exposes its data or tool once, as an MCP server. Any MCP-compatible AI application — Claude, an IDE, a custom agent — can then connect to that one server using the same client logic it already uses for every other MCP server. The integration work shifts from "one integration per model-tool pair" to "one server per tool, usable by any client."

How MCP works: hosts, clients, and servers

MCP's architecture documentation defines three participants that make up every MCP interaction:

• MCP Host — the AI application that coordinates one or more connections, such as Claude Desktop, Claude Code, or an IDE like Visual Studio Code.
• MCP Client — a component the host creates for each server it talks to; each client maintains one dedicated connection and fetches context from its server for the host to use.
• MCP Server — the program that actually provides context: it might run locally on the user's machine or remotely on a vendor's own infrastructure.

A single host can run many clients at once, each one wired to a different server — for example, VS Code might maintain one client connected to a Sentry MCP server for error data and a second client connected to a local filesystem server for project files, with each client-server pair communicating independently.

Underneath that, MCP splits into two layers. The data layer defines the actual message protocol — a JSON-RPC 2.0 exchange covering capability discovery, the core primitives, and real-time notifications. The transport layer defines how those messages physically move: MCP supports a local stdio transport, where client and server are processes on the same machine talking over standard input/output with no network overhead, and a Streamable HTTP transport for remote servers, which supports Server-Sent Events for streaming and standard HTTP auth methods including bearer tokens and OAuth. A local server using stdio typically serves exactly one client; a remote server over Streamable HTTP is built to serve many clients at once.

The core primitives: tools, resources, and prompts

The part of MCP that developers actually build against is its set of primitives — the types of context a server can offer a client. MCP's architecture documentation defines three primitives that servers expose, plus one that clients expose back to servers:

In practice, a client first calls a discovery method — tools/list, for instance — to see what a server currently offers, then invokes a specific capability by name, such as tools/call. Because that list can change at runtime, servers can also push notifications/tools/list_changed messages so a client knows to refresh what it knows, rather than working from a stale menu of capabilities. Two other client-side primitives, sampling (letting a server borrow the client's own model) and logging, exist in the protocol but are marked deprecated as of the 2026-07-28 specification, with MCP's docs now directing new implementations to call LLM provider APIs directly instead.

Why MCP matters for Claude and agentic AI

For Claude specifically, MCP is the mechanism behind "connectors" — the Google Drive, Slack-style, and custom integrations a user or enterprise can attach to a conversation so Claude can pull in real files, tickets, or records rather than working only from what's typed into the chat box. The same protocol underlies how Claude Code reaches out to a project's own tools — linting, testing, issue trackers — while it works.

For agentic AI more broadly, MCP matters because agents are only as useful as the systems they can reach. The official MCP documentation sums up the value for each side of that equation: developers get reduced complexity when building or integrating an AI application; AI applications and agents gain access to "an ecosystem of data sources, tools and apps" that widens what they can do; and end users get more capable assistants that can "access user data and take actions on the user's behalf when necessary." MCP does not replace an application's own agent logic or planning loop — it standardizes the plumbing those agents use to fetch context and take action, so that work is not duplicated per model and per tool.

MCP is not the only protocol in this space, either. Google has published its own Agent2Agent (A2A) protocol aimed at a related but distinct problem — letting independent agents talk to each other, rather than letting one host application talk to tool servers — and Anthropic itself has layered Claude Skills on top of its agent stack as a complementary way to package reusable capabilities. Readers comparing the two protocol approaches can see how A2A's agent-to-agent model differs from MCP's host-to-server model in Pandromeda's explainer on Google's A2A protocol.

The MCP ecosystem: servers, connectors, and clients

MCP's own documentation describes "broad ecosystem support" across both AI applications and development tools, explicitly naming Claude and ChatGPT as supporting AI assistants, and naming Visual Studio Code, Cursor, and MCPJam among development tools that support the protocol as clients. OpenAI's own Agents SDK documentation confirms this from the other side: it documents hosted MCP tools that let OpenAI's Responses API connect to a publicly reachable MCP server directly, with OpenAI's infrastructure owning the connection and handling authentication for OpenAI connectors.

The server side of the ecosystem has grown from the half-dozen reference integrations (Google Drive, Slack, GitHub, Git, Postgres, Puppeteer) that shipped with MCP's 2024 launch into a much larger catalog. The MCP project's GitHub organization now maintains a dedicated servers repository of maintained reference servers, a registry repository Anthropic describes as a community registry for discovering MCP servers, and an inspector tool purpose-built for testing servers during development — all signs of tooling built to support a much larger, decentralized set of third-party servers rather than a short, vendor-curated list.

That same GitHub organization also documents multi-vendor investment at the SDK level rather than only at the server level: alongside Anthropic's TypeScript and Python SDKs, the official Go SDK is co-maintained with Google and the official C# SDK with Microsoft, with further community SDKs covering Java (with Spring AI), Kotlin, PHP, Ruby, Rust, and Swift. For a protocol that launched from a single company a short time ago, that spread of co-maintained SDKs across major cloud and platform vendors is a concrete marker of how far MCP has moved into shared infrastructure.

Security considerations: what to watch for

MCP's design hands an AI application the ability to run code and move data on a user's behalf, through servers that a user did not necessarily write and may not fully trust — which is exactly the trade-off MCP's own security documentation is built around. A few considerations stand out for anyone connecting a third-party MCP server:

• Treat server-supplied content as untrusted input. MCP's specification for the tools primitive explicitly instructs clients that tool annotations "MUST" be considered untrusted unless they come from trusted servers, and requires servers to sanitize tool outputs while directing clients to "validate tool results before passing to LLM." The underlying risk is structural: whatever text, data, or instructions a tool returns becomes part of what the model reads next, so a malicious or compromised server can attempt to steer the model's behavior through its own output — the same class of risk security researchers broadly call prompt injection, applied here to tool results rather than to a webpage or document.
• A human should stay in the loop for consequential actions. The specification states there "SHOULD always be a human in the loop with the ability to deny tool invocations," and recommends that applications show users which tools are exposed, flag when a tool is invoked, and present confirmation prompts before an action runs.
• Local servers can run arbitrary code with the client's own privileges. MCP's security best-practices documentation walks through "Local MCP Server Compromise" as its own attack category, warning that a malicious startup command or a compromised package can be used for data exfiltration or destructive file operations, and recommends sandboxing, restricted file-system and network access, and a clear consent dialog showing the exact command a server will run before a client executes it.
• Remote, authenticated servers carry OAuth-specific risks. The same documentation details the "confused deputy" problem, where a proxy server's static client ID combined with a lingering consent cookie can let an attacker obtain an authorization code without real user consent, and a related "token passthrough" anti-pattern, where a server forwards a client's token to a downstream API without validating it was actually issued for that server. MCP's authorization specification states servers "MUST NOT" accept tokens that weren't explicitly issued for them.
• Elicitation has its own privacy guardrail. Because elicitation can be used to ask a user for information mid-task, the specification separately warns that servers must not use its standard "form mode" to request passwords, API keys, tokens, or payment credentials — that kind of sensitive exchange is meant to go through a separate, out-of-band URL flow instead.

None of this is unique to MCP as a technology — any system that lets a model call external code and read back arbitrary external data faces a version of these risks. What MCP's maintainers have done is write the mitigations directly into the specification, so a compliant client and a compliant server both carry baseline protections rather than reinventing them per integration.

What's next for MCP

With MCP now governed as a Linux Foundation project rather than a single-vendor release, its trajectory looks less like a product roadmap and more like that of other cross-industry protocols: periodic dated specification revisions (the architecture docs already reference a 2026-07-28 version that deprecated early features like sampling, logging, and roots), a growing server registry meant to make discovery easier as the number of third-party servers climbs, and SDK maintenance spread across more companies as adoption widens. The practical open question for users and developers is less "will MCP survive" — it is already embedded in Claude, ChatGPT's Agents SDK, VS Code, and Cursor — and more which servers in a fast-growing, decentralized ecosystem are worth trusting with real credentials and real data. Anyone adding a new MCP server is, in effect, extending their AI assistant's trust boundary, and MCP's own documentation increasingly reads like a checklist for doing that carefully rather than a reason to avoid it.

Written byTheo Park

Theo Park runs the AI desk at Pandromeda. He follows model launches from the frontier labs and the open-weight community, tracks the assistants and developer tools built on them, and explains what each release changes on pricing, capability and safety. His reporting leans on primary sources: model cards, technical reports, API documentation and the companies' own announcements.

More from Theo ParkAll AI coverage