Model Context Protocol (MCP)

The Model Context Protocol (MCP) is an open standard for connecting AI applications to the tools and data they need. Anthropic open-sourced it in November 2024, OpenAI and Google adopted it within six months, and in December 2025 it moved to neutral governance under the Agentic AI Foundation, a Linux Foundation fund co-founded by Anthropic, OpenAI, and Block. The common analogy is a USB-C port for AI: one connector that any model can use to reach any compliant system. Under the hood it is deliberately boring: JSON-RPC 2.0 messages over a couple of standard transports, plus a shared vocabulary for describing what a system offers.

The N times M problem it solves#

Before MCP, every AI application integrated with every external system through bespoke glue code. If you have M applications and N systems they should reach, wiring each pair directly costs M times N custom integrations, each with its own auth handling, error semantics, and maintenance burden. A company running four AI surfaces (a chat assistant, an IDE agent, a support copilot, an internal workflow bot) against ten systems (Postgres, GitHub, Jira, Slack, the CRM, and so on) is staring at forty integrations. With MCP it needs fourteen artifacts: ten servers and four clients, and every pair just works. Build a server once and every MCP-compatible app can use it; support MCP in your app once and the whole ecosystem of servers becomes reachable. This is the same trick the Language Server Protocol pulled for editors and programming languages, and the MCP spec cites LSP as direct inspiration.

Hosts, clients, and servers#

MCP has three roles. The host is the AI application itself: Claude Desktop, ChatGPT, VS Code, Cursor, or your own AI agent. The host spawns one client per connection, and each client holds a dedicated, stateful link to exactly one server. The server is a small program that exposes some system's capabilities in MCP's vocabulary: a Postgres server, a GitHub server, a filesystem server. At connect time the two sides negotiate capabilities and the client discovers what the server offers, so a server can add or change capabilities without the host shipping new code.

Two transports carry the JSON-RPC messages. Stdio is for local servers: the host launches the server as a subprocess and talks over standard input and output, which is ideal for tools that need access to your machine, like a filesystem or a local database. Streamable HTTP is for remote servers: a single HTTP endpoint that can stream responses, with OAuth-based authorization for connecting to services you do not run yourself. Local stdio servers dominated the first year; by 2026 the momentum is firmly with remote servers, because one hosted server can serve every user of a product without anyone installing anything.

Three primitives: tools, resources, and prompts#

Servers expose three kinds of things, and the distinction is about who decides when they are used. Tools are model-controlled: executable functions the model invokes on its own judgment, MCP's standardized form of tool calling. create_ticket(title, priority) or run_query(sql) are tools. Resources are application-controlled: read-only data identified by URI, like file contents, a database schema, or a log stream, that the host attaches as context rather than the model executing anything. Prompts are user-controlled: reusable templates the person picks explicitly, like a slash command that expands into a well-crafted workflow.

A concrete example: a Postgres MCP server might expose one query tool, every table schema as resources so the model knows the shape of the data before it writes SQL, and an "explain this slow query" prompt the user can invoke by name. The protocol also lets clients offer features back to servers, notably sampling (the server asks the host's model to complete something) and elicitation (the server asks the user a clarifying question), but tools, resources, and prompts cover most real servers today.

The ecosystem in mid-2026#

MCP's adoption curve is the fastest of any integration standard in recent memory. OpenAI adopted it across its products in March 2025; Google confirmed Gemini support a month later; Microsoft wired it into Windows, VS Code, and Copilot. In December 2025 Anthropic donated the protocol to the Agentic AI Foundation, putting the spec under vendor-neutral governance. The current stable spec revision is 2025-11-25, and the official registry at registry.modelcontextprotocol.io, launched in late 2025, indexes thousands of servers (close to ten thousand by mid-2026) with independent directories counting even more.

The payoff of all this is portability. Your integration layer stops being welded to one vendor's assistant: swap the underlying model, move from one host app to another, or add a new data source, and the MCP servers you built keep working unchanged. For teams building internal AI tooling, that decoupling is the practical reason to care.

Security: treat third-party servers as untrusted code#

Connecting an agent to arbitrary servers expands the attack surface in ways that are easy to underestimate. The headline risk is tool poisoning, demonstrated by Invariant Labs in April 2025: malicious instructions hidden inside a tool's description, which the model reads in full but the user typically never sees. Their proof of concept got an innocuous-looking addition tool to exfiltrate SSH keys. Related risks include prompt injection through tool results (any text a tool returns becomes model input), rug pulls (a server changes its tool descriptions after you approved it), and one malicious server shadowing or redirecting the behavior of a trusted one.

The dangerous combination is an agent that simultaneously has access to private data, reads untrusted content, and has a channel to send data out. Practical mitigations: pin server versions and prefer registries or vendors you trust, scope credentials to least privilege, require human approval for destructive or data-moving actions, and put guardrails and red-teaming on the agent as a whole rather than trusting each server. The spec mandates explicit user consent for tool invocation, but consent screens only help if users understand what they are approving.

Practical takeaway#

MCP is to AI tool integration what HTTP was to the web: a boring, shared standard that lets the interesting parts compose. If you are building AI features, expose your own systems as MCP servers once instead of writing per-assistant glue, consume the ecosystem of existing servers rather than rebuilding them, and treat any third-party server with exactly the suspicion you would give an npm package that ships with shell access.