Model Context Protocol — how MCP connects LLMs to the world

In short

The Model Context Protocol (MCP) is an open protocol that standardizes the connection between language models and external tools or data. Before MCP, every integration required dedicated development work. With MCP, a server written once works with any compatible client — Claude, GPT, Gemini. Launched by Anthropic in November 2024, the protocol was handed over to the Linux Foundation in late 2025 and now has adopters at nearly every major AI player.

In short: MCP is to AI what the USB plug is to peripherals. Before USB, every mouse, keyboard, and printer had its own proprietary cable. With USB, any peripheral plugs into any computer. MCP takes the same step for LLMs: a connector (server) written once works with all compatible models. Competition shifts from connector (commodity) to the content behind (the tool or data).

The problem before MCP

A language model, on its own, cannot read a local file, query a database, or call an API. It generates text — nothing else. To give it access to tools, developers wrote custom integrations: a GitHub connector here, a PostgreSQL access layer there, a Slack wrapper somewhere else.

Each integration was specific to one model. If the team switched AI providers, the connectors had to be rewritten. If a new tool appeared, a new connector had to be built. The fragmentation was structural.

The comparison frequently drawn is with the Language Server Protocol (LSP), which solved an analogous problem for IDEs: before LSP, every editor implemented its own support for every programming language. LSP introduced a single interface. MCP does the same thing for LLMs.

In short: before MCP, each model × tool marriage required its own development, as if each phone brand required its own charger. Integration cost was quadratic: N models × M tools = N × M connectors. With MCP, you fall to N + M: each model speaks MCP, each tool speaks MCP, and everything works together. Network effects play out: more servers means each client becomes more useful, and vice versa.

Architecture: three entities, two directions

MCP is based on a client-server architecture with three components.

The MCP Client is the LLM application: Claude Code, Cursor, VS Code Copilot, Replit. It initiates connections and consumes the capabilities exposed by servers.

The MCP Server is an independent process that exposes tools, data, or templates. Each server runs separately. It can give access to a Git repository, a database, a SaaS API, a file system.

The Transport is the channel between the two. Two mechanisms are active in the current spec:

• stdio: the client launches the server as a subprocess, messages flow through stdin/stdout. Used for local tools and IDE plugins.
• Streamable HTTP: the server exposes a single HTTP endpoint supporting POST and GET, with optional streaming. The standard for remote connections.

A third mechanism, pure SSE, was deprecated in 2025 in favor of Streamable HTTP. The reason: two separate endpoints created deployment complications that a single endpoint solves.

The message protocol is JSON-RPC 2.0. The schema is defined first in TypeScript, then exposed as JSON Schema for broader compatibility.

The six primitives

The MCP spec defines six types of capabilities a server can expose.

Tools: actions the LLM can trigger — read a file, call an API, run a SQL query. This is the most-used primitive.

Resources: read-only data exposures. The server makes content available (repository contents, database schema) that the application controls when and how to load.

Prompts: parameterizable prompt templates. The server exposes reusable prompt structures the client can instantiate.

Sampling: the reverse mechanism — an MCP server delegates an LLM inference to the client. Useful in multi-tenant architectures where the server has no direct model access.

Roots: defines the boundaries of allowed access. For example, the file directories a server is allowed to read. Explicit opt-in.

Elicitation: lets a server request additional information from the user via the client. A recent primitive, rarely implemented in practice.

The first two (Tools and Resources) cover most common use cases. The other four address more advanced architectures.

MCP vs function calling: two different levels

A confusion comes up regularly in technical discussions: MCP would just be rebranded function calling. The distinction deserves to be laid out clearly.

Function calling is a model-side mechanism: it turns an intent expressed in natural language into a structured function call. It remains provider-specific — the OpenAI format and the Anthropic format are not identical.

MCP operates at a different level: it standardizes the execution of those calls and the discovery of available tools. An MCP server works without modification with Claude, GPT-4o, or Gemini. The integration logic is written only once.

The two mechanisms are complementary. Function calling turns language into a structured call. MCP standardizes what that call triggers and how the result flows back.

Ecosystem: from a few servers to hundreds

Anthropic published official servers for Google Drive, Slack, GitHub, Git, PostgreSQL, and Puppeteer. These are the reference implementations, available at modelcontextprotocol/servers.

The community followed quickly. Third-party registries — claudemcp.com, glama.ai, mcp.run — aggregate several hundred servers covering databases (Supabase, Neon), cloud providers, SaaS APIs, monitoring tools, headless browsers.

On the client side, MCP support has spread across major development environments: Claude Code via .claude/settings.json config file, Cursor natively, VS Code Copilot since June 2025, Zed, Replit, Codeium, Sourcegraph.

One notable technical innovation: MCP Tool Search (lazy loading). Instead of injecting the definition of every available tool into each prompt, the client loads a definition only when it is needed. Measured result: up to 95% reduction in context consumption for environments with many active servers.

Institutional adoption and governance

MCP’s adoption trajectory is unusual for a technical protocol. In March 2025, four months after launch, OpenAI integrated it into its Agents SDK, its Responses API, and ChatGPT Desktop. In April 2025, Google DeepMind confirmed support in Gemini.

In December 2025, Anthropic handed governance over to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation. The co-founders are Anthropic, Block, and OpenAI. AWS, Google, Microsoft, Cloudflare, and Bloomberg are among the supporting members.

In January 2026, the Python SDK and the TypeScript SDK together reached 97 million monthly downloads.

This pace of adoption is partly explained by the fact that the problem solved — integration fragmentation — is structural and shared by every player. MCP offers a solution that benefits the whole ecosystem, including its creator’s competitors.

Which transport and mode by context

Limits and open problems

Tool selection

LLMs remain unreliable at picking the right tool among many options. Multiplying MCP servers worsens this problem by exposing many tool definitions. Lazy loading mitigates the context-size effect, but the underlying selection problem is not addressed in the spec.

Stateful sessions

The current spec implies stateful sessions, which complicates horizontal deployment: load balancers and multiple instances need to synchronize session state. The 2026 roadmap targets a stateless protocol with resumable sessions. That evolution is not finalized.

Security: an uncontrolled attack surface

This is the most serious issue. Several categories of vulnerabilities are documented:

Tool poisoning consists of injecting malicious instructions into a tool’s metadata — into description fields, invisible to the user but read by the model. The LLM then executes unintended actions. This vector is structurally hard to detect.

Path traversal affects servers that provide file-system access: an incorrect Roots implementation lets the model read files outside the allowed directory.

In 2025, 492 MCP servers publicly exposed without authentication were identified by security researchers. A CVE was published (CVE-2025-6514) for a remote code execution through mcp-remote.

The source of the structural problem: the MCP spec does not define a mandatory authentication mechanism between client and server. Ad hoc approaches (OAuth, Bearer tokens in HTTP headers) are documented by third parties, but no normative standard exists in the current spec. Microsoft published recommendations against indirect injection, without establishing a de facto standard.

Note: a figure often cited in discussions — “43% of tested implementations vulnerable” — circulates across several articles but with no identifiable reference to the primary study. To be treated with caution.

What to remember

• MCP solves a real problem: the fragmentation of integrations between LLMs and tools. Each custom integration is replaced by a server that works with every compatible client.
• The architecture is simple: client (the LLM app), server (the connector), transport (stdio for local, HTTP for remote). Six primitives cover most needs.
• Adoption is broad and fast: OpenAI, Google, Microsoft, AWS back the protocol. Governance was transferred to the Linux Foundation in late 2025.
• The limits are real: tool selection is hard at scale, stateful sessions complicate deployment, and above all an uncontrolled security attack surface remains due to the lack of an authentication standard in the spec.