What is the Model Context Protocol (MCP)?
The Model Context Protocol (MCP) is an open protocol that standardises how AI models connect to external tools, data sources, and services. It defines a client-server architecture where AI hosts act as clients, and tools, resources, and prompts are exposed by servers.
Why this subject matters
Before MCP, every AI model integration with an external tool was a bespoke implementation — different APIs, different authentication patterns, different data formats. MCP provides a single, open standard that any model can use to discover and invoke tools, read resources, and use prompt templates. This means tool builders write one server, and every MCP-compatible AI host can use it. It is the equivalent of USB for AI-tool connectivity.
Current status
MCP was introduced by Anthropic in November 2024 and has gained rapid adoption across the AI ecosystem. As of mid-2026, it is supported by major AI hosts including Claude Desktop, Continue, Cline, and Zed, with servers available for filesystems, databases, APIs, and development tools. The specification continues to evolve with community contributions. The protocol is open and not controlled by any single vendor.
Core concepts
- Host
- The AI application that initiates connections — e.g. Claude Desktop, a coding IDE, or a custom agent. The host is an MCP client.
- Client
- A protocol client that maintains a 1:1 connection with a server. The host may manage multiple clients, each connected to a different server.
- Server
- A lightweight program that exposes tools, resources, and prompts via the MCP protocol. Each server provides specific capabilities — file access, database queries, API calls, etc.
- Tool
- A function that the AI model can invoke. Tools are model-controlled: the model decides whether and when to call a tool, and the server executes it. Tools take structured inputs and return structured outputs.
- Resource
- A structured data object exposed by the server that the model can read. Unlike tools, resources are application-controlled: the host decides what context to include. Resources can be static (files), dynamic (API responses), or subscribed (live updates).
- Prompt
- A reusable prompt template provided by the server. Prompts help standardise interactions — for example, a server might provide a code-review prompt template that the host can offer to users.
- Transport
- The communication layer between client and server. MCP supports stdio (for local processes) and HTTP with Server-Sent Events (for remote servers). The transport layer is pluggable — new transports can be added.
Architecture / Mechanism
MCP follows a client-server model inspired by the Language Server Protocol (LSP). The host application (e.g., Claude Desktop) embeds an MCP client. That client connects to one or more MCP servers, each running as a separate process — locally via stdio, or remotely via HTTP+SSE.
When a user asks a question, the AI model (running within the host) can decide to invoke a tool. The tool call goes from the model → host → client → server. The server executes the tool and returns the result. The result is added to the model's context, allowing it to incorporate real-time data or take real-world actions.
Resources work differently: the host pre-fetches relevant resources and injects them into the model's context before the model generates a response. This means the model always has access to the latest data without needing to make tool calls for every query.
This separation — tools are model-pulled, resources are host-pushed — is a key design decision that balances flexibility with control.
What it does
MCP enables AI models to:
- Read files, databases, and live data feeds
- Execute code, run queries, and call APIs
- Interact with development tools (git, linters, build systems)
- Access web services and external platforms
- Use structured prompt templates for consistent interactions
- Discover available capabilities dynamically at connection time
What it does not do
MCP does not:
- Define what the AI model decides to do — it only defines how tools are exposed and invoked
- Provide authentication or authorisation — that is the responsibility of each server implementation
- Enforce safety policies — the host must implement guardrails
- Replace function calling — MCP is a protocol for connecting to tools; function calling is the model's mechanism for invoking them
- Dictate a specific AI model or provider — any model that supports tool/function calling can use MCP
Known limitations
- MCP does not define a standard for tool permissions or access control — each server must implement its own authorisation.
- The protocol is still evolving; breaking changes to the specification are possible.
- Remote transports (HTTP+SSE) require network configuration and have different security properties than local stdio.
- Server discovery is not yet standardised — users must manually configure which servers a host connects to.
- There is no built-in mechanism for servers to compose or chain — complex multi-tool workflows must be orchestrated by the host.
- Resource subscriptions (live updates) are defined but not yet widely implemented across servers.
Security and governance considerations
MCP's design introduces a fundamental tension: the protocol makes it easy to give AI models access to powerful tools, but it does not prescribe how much access is safe. This is the execution-governance gap.
Key security considerations:
- Tool poisoning: A compromised server could return malicious results that influence the model's behaviour.
- Confused deputy: The model may invoke a tool in a way the user did not intend, using its authority to perform unintended actions.
- Credential exposure: Servers often hold API keys and credentials — if a server is compromised, those secrets may be exposed.
- Indirect prompt injection: Data from tools and resources enters the model's context and could contain injected instructions.
- Transport security: Remote HTTP connections must use TLS; stdio connections are limited to the local machine but are still vulnerable to process-level attacks.
Human approval, tool-use policies, and execution sandboxing are critical complements to MCP that the protocol itself does not provide.
Implementation options
MCP TypeScript SDK
Learn more →MCP Python SDK
Learn more →Claude Desktop (built-in client)
Learn more →Continue (IDE extension)
Learn more →Timeline / Significant changes
Claims and Evidence
MCP is an open protocol, not controlled by any single vendor.
MCP follows a client-server architecture inspired by the Language Server Protocol (LSP).
MCP enables a clear separation between model-pulled tools and host-pushed resources.
MCP does not define authentication or authorisation — security is the responsibility of each server implementation.
Open questions / Disputed areas
- Will MCP server discovery become standardised, or will manual configuration remain the norm?
- How should tool permissions be managed at scale — per-user, per-session, or per-tool?
- Should MCP include a standard for human-approval gates (e.g., 'ask user before executing this tool')?
- Can MCP servers be safely composed without introducing new attack surfaces?
- How does MCP compare to emerging agent-to-agent protocols like A2A (Google's Agent-to-Agent)?