Model Context Protocol (MCP): The Complete Guide

The Model Context Protocol (MCP) is an open standard that lets AI models and agents connect to external tools, data, and systems through a single, consistent interface. Instead of building a custom integration for every model-and-tool combination, you expose your data and actions through an MCP server once, and any MCP-compatible AI application can use it.

This guide is written for developers, AI and platform engineers, and the technical product and security leaders building or governing agentic AI. It explains what MCP is, the problem it was designed to solve, how its architecture and core primitives work, the transports it runs over, and the security and governance questions that matter once you connect a model to real systems. Along the way it links out to deeper guides for each subtopic, so you can go as far down as you need.

What is the Model Context Protocol (MCP)?

The Model Context Protocol is an open standard for connecting AI applications to the external context they need: the tools they can call, the data they can read, and the prompts that shape how they work. A useful first analogy is that MCP is a "USB-C port for AI applications," a universal connector that replaces a tangle of one-off cables with a single standard plug. That analogy explains the convenience. It does not explain that every port you open is also a new entry point that has to be secured and governed. That is where the more interesting questions live, and where this guide spends real time.

Concretely, MCP defines how an AI application talks to an external program that supplies context. The AI application runs an MCP client, the external program is an MCP server, and they exchange structured messages over a defined protocol. Because the interface is standardized, the same MCP server works across many AI hosts, and a single host can talk to many servers at once. If you want a lighter introduction first, see our explainer on what MCP is.

Who created MCP and who maintains it now

MCP was introduced by Anthropic in November 2024 as an open standard, created to solve the integration sprawl that came from wiring each AI model to each data source by hand. Adoption moved quickly. OpenAI adopted MCP in early 2025 and added support across products including ChatGPT, Google DeepMind announced support in 2025, and Microsoft integrated it through tooling such as Semantic Kernel and Copilot Studio. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation. The protocol is now governed as a vendor-neutral, community standard rather than a single company's project.

The problem MCP solves: the N×M integration problem

Before MCP, connecting AI to the outside world was an "N times M" problem. If you had N AI applications and M tools or data sources, you potentially needed a custom connector for every combination. Each integration carried its own authentication, its own data format, and its own maintenance burden. Adding one new tool meant updating every application that wanted to use it. Adding one new application meant rebuilding every integration it needed.

MCP collapses that matrix into a single standard. You expose a tool or data source once as an MCP server. Any MCP-compatible application can then discover and use it without bespoke glue code. The integration cost stops scaling with the product of N and M and starts scaling with N plus M. That is the difference between an unmanageable explosion and a maintainable ecosystem.

Why the Model Context Protocol matters

MCP matters because it turns ad hoc AI integrations into reusable, portable infrastructure. That value shows up in several distinct ways.

Benefit	What it means in practice
Interoperability	One MCP server works across many AI hosts; one host can use many servers.
Lower integration cost	Build a connector once instead of once per model-and-tool pair.
Dynamic discovery	Clients ask servers what tools and data they offer at runtime, so capabilities can change without redeploying the client.
Portability	Move between AI applications without rewriting your integrations.
A clear trust boundary	Because every external capability flows through a defined interface, MCP becomes the natural place to apply identity, authorization, and audit.

That last row is the one most explainers skip. Once a model can call real tools and read real data, the connection point is not just plumbing. It is the boundary where security and governance have to be enforced. We return to that in depth below.

How MCP works: architecture

MCP follows a client-server architecture with three named participants. An MCP host is the AI application itself, such as a coding assistant, a chat application, or an IDE. The host creates one MCP client for each server it wants to use, and every client maintains a dedicated, one-to-one connection with a single MCP server. The server is the program that provides context: tools to call, data to read, and prompts to reuse. Servers can run locally on the same machine as the host, or remotely over the network. For a deeper look at the server side, see our guide to what an MCP server is and the complete guide to building, deploying, and securing MCP servers.

Participant	Role	Example
MCP host	The AI application that coordinates one or more clients	An IDE, chat app, or coding agent
MCP client	Holds one dedicated connection to one server and relays context to the host	A connection object inside the host
MCP server	Exposes tools, resources, and prompts to clients	A filesystem server, database server, or SaaS connector

The two layers: data layer and transport layer

MCP is organized into two layers. The data layer is the inner layer. It defines the protocol the client and server actually speak, built on JSON-RPC 2.0, and it covers lifecycle management, the core primitives, and notifications. The transport layer is the outer layer. It defines how messages physically move between client and server, including connection setup, message framing, and authentication. Keeping these separate means the same JSON-RPC messages work identically whether they travel over a local pipe or an HTTP connection.

The connection lifecycle

MCP is a stateful protocol, so each connection follows a defined lifecycle that begins with capability negotiation.

1. Initialize. The client sends an initialize request that includes the protocol version it supports, the capabilities it offers, and identifying client information.
2. Capability negotiation. The server responds with its own protocol version and the capabilities it supports, such as tools, resources, or prompts. If the two sides cannot agree on a compatible protocol version, the connection is terminated.
3. Initialized. The client sends a notifications/initialized message to signal it is ready.
4. Operation. The client discovers and uses primitives, and the server can send notifications when its capabilities change.
5. Termination. Either side closes the connection cleanly when finished.

MCP primitives: tools, resources, and prompts

Primitives are the heart of MCP. They define what servers and clients can offer each other. Each primitive has standard methods for discovery (a */list method) and for retrieval or execution, and the data layer keeps these consistent across every server.

Server primitives

Servers expose three core primitives, which are the ones most people mean when they talk about "MCP."

Primitive	What it is	Key methods	Example
Tools	Executable functions the model can invoke to take actions	tools/list, tools/call	Run a database query, send an email, call an API
Resources	Data sources that supply context to the model	resources/list, resources/read	File contents, database records, API responses
Prompts	Reusable templates that structure interactions	prompts/list, prompts/get	A system prompt or few-shot example set

Each tool carries a JSON Schema inputSchema that describes its parameters, so the model can construct valid calls and the server can validate them. A tool call returns a content array that can hold text, images, or embedded resources, which gives rich multi-format responses. Because clients discover tools dynamically with tools/list, the set of available tools can change at runtime. For a focused deep-dive, see what MCP tools are and how to use them.

Client primitives

MCP also defines primitives that the client and host expose, so server authors can build richer, two-way interactions.

• Sampling (sampling/createMessage): a server can ask the host's LLM for a completion. This lets server authors use a language model without bundling their own model SDK, staying model-independent.
• Elicitation (elicitation/create): a server can ask the user for more input or to confirm an action, keeping a human in the loop.
• Logging: a server can send log messages to the client for debugging and monitoring.

Notifications and tasks

Beyond server and client primitives, MCP includes utility features. Notifications are JSON-RPC messages with no response that let a server push real-time updates, such as notifications/tools/list_changed when its available tools change. These are sent only when the relevant capability was negotiated. Tasks are a newer, experimental feature: durable execution wrappers that allow deferred result retrieval and status tracking for long-running or expensive operations.

MCP transports: stdio vs Streamable HTTP

The transport layer defines how MCP messages actually move. The protocol supports two mechanisms, and the same JSON-RPC data layer rides on either one.

	stdio	Streamable HTTP
How it works	Standard input/output streams between local processes	HTTP POST for client-to-server messages, with optional Server-Sent Events for streaming
Typical use	"Local" servers running on the same machine as the host	"Remote" servers reachable over the network
Clients served	Usually one client per server	Often many clients per server
Authentication	Process-level, no network auth needed	Bearer tokens, API keys, custom headers; OAuth recommended for obtaining tokens

Streamable HTTP is the recommended remote transport. It replaced the earlier HTTP-plus-Server-Sent-Events transport in the 2025-03-26 revision of the specification, which simplified how remote servers stream responses. For local development and desktop integrations, stdio remains the simplest and fastest option, because it avoids network overhead entirely.

MCP security and governance

MCP is powerful precisely because it lets a model take real actions and read real data. That same power is why security cannot be an afterthought. Every MCP server you connect is a new entry point into your systems, and a model that follows instructions is a model that can be tricked into following the wrong ones. Treating MCP connections as a trust boundary, not just a convenience, is the single most important shift for any team adopting it.

Top MCP security risks

Risk	What it is	Why it matters
Indirect prompt injection	Hidden instructions planted in data, tool output, or web pages that the model reads and obeys	Listed by OWASP as the top risk for LLM applications; can hijack an agent into taking unintended actions
Tool poisoning and rug pulls	Malicious instructions hidden in a tool's description or metadata, or a trusted tool silently swapped for a lookalike	A malicious server sharing context with a legitimate one can exfiltrate data with no obvious network exploit
Credential exposure	MCP server configs often hold API keys, database credentials, and service tokens	Audits have found thousands of secrets exposed through insecure MCP credential handling
OAuth confused-deputy	Proxy servers that use a static client ID with dynamic client registration can be tricked into reusing a user's existing consent	Lets an attacker obtain authorization the user never intended to grant
Over-privileged access	Servers and agents granted far broader permissions than the task requires	Expands the blast radius of any single compromise or mistake

How to secure and govern MCP

The mitigations are practical, and they reinforce each other. Apply least privilege so each server and tool gets only the access it needs. Keep a human in the loop for sensitive or irreversible actions. Isolate and sanitize inputs and outputs, and treat every tool response as untrusted data rather than trusted instruction. Enforce strong identity and authorization, using OAuth for remote servers. And rather than securing dozens of servers one at a time, route MCP traffic through a centralized control point that can apply policy, authentication, and audit logging in one place.

That central control point is where an MCP gateway and an MCP proxy earn their place. They give you a single chokepoint to authenticate clients, scope what each agent can reach, filter calls, and produce an audit trail across every connected server. For the full risk catalog and defenses, see the deeper guides on MCP security risks, MCP security best practices, MCP access control, and MCP authentication.

The MCP ecosystem and adoption

MCP has grown into a broad ecosystem. The major AI providers support it, including OpenAI, Google DeepMind, and Microsoft, alongside Anthropic. Official software development kits exist for many languages, and there is a growing catalog of reference and third-party MCP servers for common systems. Developer tooling such as the MCP Inspector helps you test servers, and MCP catalogs and registries help teams discover and manage which servers they trust. With governance now under the Linux Foundation's Agentic AI Foundation, the protocol is positioned as durable, vendor-neutral infrastructure.

The specification itself is versioned by date, and it continues to evolve toward a more scalable, stateless core and stronger authorization. Because the exact current version changes over time, treat dated facts here as a snapshot and consult the official specification for the version your tools implement.

MCP vs related approaches

MCP vs traditional APIs and plugins

A traditional API is built for a developer to call from code at build time. MCP is built for an AI model to discover and call at runtime, with machine-readable schemas and descriptions designed for a model to reason about. MCP often sits in front of existing APIs: the MCP server wraps your API and exposes it in a form an agent can use safely. They are layers, not competitors.

MCP vs LLM function calling

Function calling is a model capability that lets an LLM emit a structured request to invoke a function. MCP is the standard that defines where those functions live, how they are discovered, and how the call is transported and secured. In practice they work together. The model uses function calling to decide it wants a tool, and MCP provides and governs that tool. MCP makes function calling portable across hosts instead of hard-coded into one application.

MCP vs A2A

MCP connects an AI application to tools and data. A2A (agent-to-agent) protocols focus on how autonomous agents communicate and delegate to each other. They address different layers of an agentic system and are frequently used together. For a detailed comparison, see MCP vs A2A.

Best practices for adopting MCP

If you are introducing MCP into a real environment, a few habits prevent most of the trouble.

• Start read-only. Expose resources and low-risk tools before granting write or destructive actions.
• Scope tools tightly. Give each server the narrowest permissions and clearest input schemas you can.
• Vet and pin servers. Use trusted sources, review tool descriptions, and pin versions so a server cannot silently change behavior.
• Centralize through a gateway. Route traffic through a single control point for authentication, policy, and audit instead of securing each server separately.
• Log everything. Keep an audit trail of which agent called which tool with what arguments.
• Treat tool output as untrusted. Assume any text a tool returns could contain injected instructions, and isolate it accordingly.

MCP use cases

MCP shows up anywhere an AI application needs reliable access to outside systems.

• Developer tooling: coding agents that read repositories, run tests, and open issues through MCP servers for tools like version control and CI.
• Data and analytics: agents that query databases, warehouses, and BI tools to answer questions over live data.
• Customer support: assistants that pull from ticketing and knowledge systems and take actions on behalf of an agent.
• Internal knowledge: connecting models to document stores and wikis so answers are grounded in company information.
• Multi-tool orchestration: a single agent coordinating several MCP servers to complete a multi-step workflow.

Frequently asked questions

What is the Model Context Protocol in simple terms?

MCP is an open standard that lets AI applications connect to external tools and data through one consistent interface, so a tool built once works with any MCP-compatible AI app.

Who created MCP and who maintains it now?

Anthropic introduced MCP in November 2024. In December 2025 it was donated to the Agentic AI Foundation under the Linux Foundation, making it a vendor-neutral open standard.

What problem does MCP solve?

It solves the N-times-M integration problem. Instead of a custom connector for every model-and-tool pair, you expose a tool once as an MCP server and any AI app can use it.

What are the three core MCP primitives?

Tools (executable functions), resources (data the model can read), and prompts (reusable interaction templates). Clients can also expose sampling, elicitation, and logging.

What is the difference between an MCP host, client, and server?

The host is the AI application, the client is a connection object inside the host that talks to one server, and the server is the program that exposes tools, resources, and prompts.

What transports does MCP use?

Two. stdio for local servers on the same machine, and Streamable HTTP for remote servers over the network, with OAuth recommended for authentication.

Is MCP secure? What are the main risks?

MCP can be secured, but it expands the attack surface. Main risks include indirect prompt injection, tool poisoning, credential exposure, and OAuth confused-deputy attacks. Mitigate with least privilege, human-in-the-loop approval, and a governed gateway.

Is MCP the same as an API?

No. An API is called by developers from code. MCP is discovered and called by AI models at runtime, and an MCP server often wraps an existing API to make it safe for agents.

How is MCP different from LLM function calling?

Function calling is how a model requests a tool. MCP is the standard that defines, discovers, transports, and secures those tools across applications. They work together.

Do OpenAI, Google, and Microsoft support MCP?

Yes. OpenAI, Google DeepMind, and Microsoft have all adopted or integrated MCP, alongside its originator Anthropic.

Continue learning: MCP resources

This page is the hub for the broader MCP topic. To go deeper into any subtopic, continue with these guides:

• What is MCP (quick explainer)
• MCP servers: build, deploy, and secure
• What is an MCP server
• What are MCP tools
• MCP security and best practices and MCP security risks
• What is an MCP gateway
• MCP access control
• MCP authentication
• MCP proxy
• MCP vs A2A
• MCP catalogs

Securing MCP in production

Connecting models to tools is the easy part. Doing it without opening your systems to prompt injection, credential leaks, and over-privileged agents is the hard part, and it is exactly where a governed MCP layer pays off. If you are moving MCP from a prototype into production, put a control point in front of it that handles identity, authorization, policy, and audit across every server you connect. Learn how a purpose-built MCP gateway helps teams secure and govern MCP at scale.