What Is Model Context Protocol (MCP)? Full Guide

The Model Context Protocol (MCP) is an open standard that connects AI applications to external tools, data sources, and services, and it has quickly become the way AI agents reach the systems where work happens. Anthropic introduced MCP in November 2024, and the shift it set off is easy to describe. AI agents used to be limited to what a model could reason about inside a chat window. With MCP, an agent can read a customer record, update a ticket, or send a message through one shared interface, which means those connections carry both information and action. That combination is exactly why MCP now sits on the security team’s agenda as much as the engineering team’s.

For security architects and platform teams, the practical questions follow a predictable order: how MCP works, how it compares to APIs, function calling, and retrieval-augmented generation (RAG), and what needs to be in place before agents use it at scale. This article covers each in turn.

What Is the Model Context Protocol?

The Model Context Protocol is an open standard that defines how AI applications connect to external tools, data sources, and services. Before MCP, every connection between a model and a system such as a CRM, a code repository, or an internal database required its own custom-built integration. Hundreds of one-off connectors, each with its own authentication method and failure mode, was a realistic outcome.

MCP replaces that fragmentation with a single, shared interface. A tool or data source exposes itself once, through an MCP server, and any MCP-compliant AI application can connect to it without additional custom code. It works in both directions: applications can pull in context, such as a customer record or a file, and they can also trigger actions, such as updating a ticket or sending a message.

Adoption has been fast. Within roughly a year, MCP spread across the major model providers and mainstream developer tools, and in December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, with backing from Google, Microsoft, AWS, Cloudflare, and Bloomberg. That made MCP vendor-neutral infrastructure, and it reflects how central the protocol has become to agentic AI development.

How Does MCP Work?

MCP works through a request-and-response cycle between an AI application and the servers that expose tools. The application discovers which tools, data sources, and prompt templates each connected server offers. From there, three things happen every time the model needs to act:

1. Selection. Based on the user’s intent and the conversation’s context, the model decides which available tool fits the task.
2. Invocation. The application sends a structured request, formatted as JSON-RPC, containing the input parameters the tool needs.
3. Execution. The server carries out the request, whether that’s a database query, an API call, or a file read, and returns the result for the model to use in its response or next action.

This cycle repeats for every tool call, and a single task can involve dozens.

A worked example: investigating an account escalation

Consider an internal support agent. The host is the company’s agent platform, running one MCP client for a CRM server and another for a ticketing server. A user asks it to investigate the Acme escalation and update the ticket. Here’s where the permission checks belong:

1. The host confirms who is asking. It verifies the user’s identity and which MCP servers that user may reach. This is the first consent point.
2. The CRM client calls an account-history tool. The request carries a token issued for the CRM server only.
3. The CRM server validates the request. It confirms the token was issued for it and the scope is read-only, then returns the history as a resource.
4. The model drafts a resolution and selects a ticket update. Because this is a write action, the host pauses for user approval. This is the human review checkpoint.
5. The ticketing server acts with the user’s permissions. It validates its own token and uses the requesting user’s access, not a broad service account, which prevents a confused deputy.

To the user, that’s one smooth interaction. Underneath, it’s several independent trust boundaries crossed in quick succession, which is where governance needs visibility.

MCP Architecture: Hosts, Clients, and Servers

MCP’s architecture is deliberately simple on paper: a host, a client, and a server. Each one plays a distinct role, and each introduces its own considerations for anyone responsible for securing the environment. The distinction that trips people up is that the model doesn’t connect to servers directly. The host application and its MCP clients handle that communication on the model’s behalf.

MCP host

The host is the AI application the end user actually interacts with, such as a coding tool, a desktop AI application, or an internal agent platform. The host manages the overall experience, holds the model’s conversation context, and coordinates one or more clients. Because user intent originates here, the host is also where consent and session isolation matter most.

MCP client

For every server it connects to, the host creates a dedicated client. The client manages that one connection: it handles authentication, discovers what the server exposes, and translates the model’s tool selections into formatted requests. Clients typically run alongside the host, so a compromised client can expose every server it’s connected to.

MCP server

The server is where the actual capability lives. It can be local, such as a filesystem or a script running on the same machine, or remote, such as a hosted service sitting behind a company’s firewall. Servers can wrap anything from an internal ticketing system to a public SaaS product, and they often carry elevated permissions to do their job. An over-privileged or poorly maintained server is one of the most common ways an agent ends up with more access than it should have.

Tools, Resources, and Prompts

MCP’s capabilities are organized around three components. A single server can expose all three, which lets it present the full functional surface of a complex system in a way any compliant client can understand.

MCP was built for two-way communication. A model doesn’t just retrieve information; it can also act on it, which is what makes MCP foundational to agentic AI rather than a retrieval mechanism alone.

Local and Remote MCP Servers

Where a server runs changes how it’s connected and how it’s secured. The current standard defines two transport bindings, and the choice between them shapes the trust model.

Local servers over stdio

With the stdio transport, the host launches the server as a local process and exchanges messages over standard input and output. The specification says these servers should read credentials from the environment rather than use the authorization framework, so the trust boundary is the process itself. Sandboxing it, and controlling which credentials it inherits, matters more than any token flow.

Remote servers over Streamable HTTP

Remote servers communicate over HTTP, which is where the protocol’s authorization framework applies. A protected remote server acts as an OAuth 2.1 resource server: it validates access tokens issued by a separate authorization server and rejects requests without a valid one. A server reachable over the network is also one that other parties can find, probe, and impersonate.

How the MCP Specification Has Evolved

The protocol has moved quickly, and much of what’s been written about it describes older revisions.

• March 2025: introduced the Streamable HTTP transport and OAuth 2.1-based authorization for remote servers.
• June 2025: formalized servers as OAuth resource servers and required resource indicators so tokens are bound to the intended server.
• November 2025: added Client ID Metadata Documents, OpenID Connect discovery, experimental long-running tasks, and JSON Schema 2020-12.
• July 2026: the largest revision since launch, with a stateless core, a formal extensions framework, hardened authorization, and a deprecation policy.

The July 2026 revision changes how people should think about state. Earlier versions opened every connection with an initialization handshake and tracked a protocol-level session. Today, each request is self-describing and carries its own protocol version and capabilities, so any server instance can handle any request. That doesn’t make applications stateless: the host still manages conversation context, and servers can issue explicit handles for the model to pass back. The protocol just no longer manages that state for you.

On authorization, the July 2026 revision added issuer validation on authorization responses, deprecated Dynamic Client Registration in favor of Client ID Metadata Documents, and kept the rule that tokens are bound to a specific server. These additions matter, but they define a baseline rather than a guarantee. The specification standardizes how tools are discovered and called, and how tokens are validated for HTTP servers. It leaves consent flows, access controls, and the behavior of each component to the people who build and deploy them.

MCP vs. APIs, Function Calling, and RAG

MCP is often described alongside three other approaches, and the confusion is understandable because they overlap. They address different problems, and in practice they work together.

MCP vs. APIs

An API is the interface a single service exposes. MCP is a shared protocol above those interfaces, so an AI application can discover and call capabilities the same way across many services. Many MCP servers wrap existing APIs; the difference is that a server is built once and any compliant application can use it.

MCP vs. function calling

Function calling is a model capability: given function definitions, the model can produce a structured request to call one. MCP covers what surrounds that moment, including where tool definitions come from and how the call reaches the system that runs it. Function calling is how a model asks for an action; MCP is how an application finds the tools and gets it done.

MCP vs. RAG

RAG grounds a model’s response in documents retrieved at the time of the question, so it’s primarily about reading. MCP can serve as a retrieval channel through resources, but it also lets agents act and chain steps together. Many architectures use both: RAG for knowledge, MCP for live systems.

MCP Security Risks and Controls

MCP matters because it turns a language model into something that can act: look something up, take an action, and chain several steps together without a human directing every move. That shift from generating text to executing workflows defines agentic AI, and it’s why governance is non-negotiable. This section covers what the protocol does and doesn’t provide, then the patterns that show up most often.

What the protocol provides, and what it doesn’t

MCP defines an HTTP authorization framework based on OAuth 2.1. Authorization is optional, and servers that run locally over stdio take credentials from the environment instead. When authorization is used, it governs how tokens are obtained, bound to a server, and validated. It doesn’t decide what an agent does with a tool it’s legitimately allowed to call, and it doesn’t verify that a tool’s description or a server’s code is trustworthy. A correctly authorized agent can still be manipulated into a harmful but legitimate-looking call.

The risks seen in practice

The risk isn’t hypothetical. In September 2025, researchers found a compromised npm package impersonating the legitimate Postmark email MCP server. The malicious version behaved identically to the real one for fifteen releases, earning trust and adoption, and then quietly added a single line of code that copied every outgoing email to an attacker-controlled address. Because MCP servers typically run with broad, pre-authorized access, the exposure covered anything sent through that server, including password resets, invoices, and internal correspondence, for over a week before it was caught.

OWASP’s MCP-specific security guidance documents this as one pattern among several. Alongside supply chain compromise, common risks include tool poisoning, where a manipulated tool description misleads the model, and the confused deputy problem, where a server acts on its own broad privileges instead of the requesting user’s permissions. Each traces back to the same root cause: something trusting an instruction, description, or dependency it can’t reliably verify.

Extending posture management to MCP

This is why AI Security Posture Management (AISPM) needs to extend to MCP itself, not just the agents on top of it. Discovery, risk assessment, and runtime enforcement all have to treat the agent, the client, and the server as three trust boundaries, each capable of failing independently.

How to Get Started With MCP

Adopting MCP doesn’t require choosing between speed and security, but it does require sequencing the two correctly.

A quick-start path

For a first hands-on experience, keep the scope small and the permissions narrow. The official introduction and implementation guides cover each step in more depth.

1. Choose a compatible host. Pick an AI application that supports MCP clients, ideally in a non-production environment.
2. Select a trusted server. Start with a vetted vendor or maintainer, and pin the version.
3. Configure access. Grant the narrowest scope that works, and keep credentials out of shared configuration files.
4. Test a limited operation. Begin with a read-only action, then try one low-risk write.
5. Review the activity. Check what the agent called and what came back before widening access.

A governance checklist

Once MCP moves beyond experimentation, these five practices keep adoption from outrunning oversight.

1. Inventory before you integrate. Know which MCP servers, local and remote, are already in use across the organization before adding more. Shadow MCP adoption is easy when any developer can spin up a server in minutes.
2. Treat every server as untrusted until proven otherwise. Vet MCP servers the way you’d vet any third-party dependency with elevated access, and don’t assume a tool’s description or behavior at install time will hold at runtime.
3. Apply least privilege at the server level. Scope permissions to what a given tool actually needs, rather than relying on the model to self-limit what it invokes.
4. Build in human review for high-risk actions. Not every tool call needs approval, but the ones that touch sensitive data or take irreversible actions should.
5. Pair adoption with continuous visibility. Know what agents exist, which MCP servers they’re connected to, and what they’re actually doing at runtime, not just what they’re configured to do.

Teams that get this sequence right move quickly without treating every integration as a fire drill. Zenity’s MCP Server Security Report breaks down the specific governance gaps showing up across real enterprise deployments, for teams that want a closer look before they scale further.

Securing MCP Before It Scales

The Model Context Protocol is a major unlock for what AI agents can do inside an enterprise. It’s also a new, fast-growing attack surface that traditional application security tools weren’t built to see.

Adopting MCP without visibility into what it’s actually doing is not a risk worth taking as agents move from pilot to production. Zenity gives security teams the discovery, posture management, and runtime enforcement they need to let agents use MCP safely, from the first server they connect to the thousandth. Book a demo to see how Zenity secures MCP across your environment.

FAQs About the Model Context Protocol

What is the Model Context Protocol in simple terms?

MCP is an open standard that lets AI applications connect to external tools, data, and services through one shared interface instead of a custom integration for every connection. Anthropic introduced it in November 2024, and OpenAI, Google DeepMind, and Microsoft have since adopted it.

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

The host is the AI application the user interacts with. The client, created by the host, manages the connection to a single server. The server exposes the actual tools, resources, and prompts that give the model something to work with.

Does MCP include built-in security?

Partly. The specification includes an optional, OAuth 2.1-based authorization framework for HTTP-based servers, and local stdio servers take credentials from the environment instead. It doesn’t enforce consent, least privilege, input validation, or runtime monitoring, so the security of any deployment depends on how it’s implemented.

Is OAuth required for every MCP server?

No. Authorization is optional. HTTP-based servers that support it should follow the OAuth 2.1-based framework, while local stdio servers read credentials from the environment.

What are the biggest risks associated with MCP?

Common risks include servers with no authentication, supply chain compromise, tool poisoning, and over-privileged servers that give a manipulated agent more access than intended.

How is MCP different from a typical API integration?

A traditional API integration is built for one specific connection. MCP is a shared protocol: build a server once and any MCP-compliant AI application can use it. Many MCP servers wrap existing APIs, so the two complement each other.

How should a security team get started with MCP governance?

Start with discovery. Before adding controls, security teams need a full inventory of which MCP servers are already connected to which agents, followed by risk assessment and runtime enforcement layered on top.