What Is the Model Context Protocol (MCP)?

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 is current as of the 2026-07-28 specification revision, which is the largest change to MCP since it launched. If you implemented against an earlier revision, several things you built are now deprecated or removed, and this guide says which.

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, which is why this guide gives security and governance as much room as mechanics.

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 built on JSON-RPC 2.0. 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, Google DeepMind, and Microsoft have all since adopted or integrated MCP across their AI products and developer tooling, alongside Anthropic. 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, with a published feature-lifecycle policy and an open change-proposal process on GitHub.

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. Three hosts and three tools go from nine bespoke connectors to six standard ones, and the gap widens fast: ten and ten is a hundred connectors before MCP and twenty after.

Why the Model Context Protocol matters

Collapsing the integration matrix is the mechanical benefit. The strategic ones follow from it.

Benefit	What it means in practice
A clear trust boundary	Because every external capability flows through one defined interface, MCP becomes the natural place to apply identity, authorization, and audit. Once a model can call real tools, the connection point is not plumbing. It is the boundary where governance has to be enforced.
Portability	Move between AI applications without rewriting your integrations. The server you wrote for a coding assistant works unchanged in a chat app.
Interoperability	One MCP server works across many AI hosts; one host can use many servers at the same time.
Runtime discovery	Clients ask servers what tools and data they offer at request time, so capabilities can change without redeploying the client.
Vendor neutrality	Governance sits with the Linux Foundation's Agentic AI Foundation, so the standard does not move at one vendor's commercial convenience.

The first row is the one that decides whether MCP is an asset or a liability in your environment, and we return to it 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 the model can call, data it can read, and prompt templates it can reuse (all three are defined properly in the next section). 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 request semantics, 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, required headers, and authentication. Keeping these separate means the same JSON-RPC messages work identically whether they travel over a local pipe or an HTTP connection, which is why the transport can be deprecated and replaced without touching the primitives.

The connection lifecycle

If you learned MCP before mid-2026, this is the section that changed most. MCP used to be a stateful protocol: every connection opened with an initialize request, negotiated capabilities once, confirmed with a notifications/initialized message, and carried that agreement for the life of the session. The 2026-07-28 revision removed all of it. MCP is now stateless, with self-contained requests and per-request capability negotiation. The initialize handshake is gone, and so is the protocol-level session and its Mcp-Session-Id header.

What replaces it is simpler to reason about and harder to get subtly wrong. A connection still opens and closes, but it carries no protocol state in between.

1. Discovery. The client calls server/discover, which every server must now implement, to learn the protocol versions the server supports, its capabilities, and its identity.
2. Self-contained request. Each request carries its own protocol version and client capabilities in _meta, under io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities. A version the server cannot serve comes back as UnsupportedProtocolVersionError.
3. Result. Every result now carries a required resultType field. "complete" means the server is done.
4. Round trip, if needed. "input_required" means the server needs something first. It returns an InputRequiredResult whose inputRequests field says what, and the client re-issues the original request with inputResponses attached. This pattern is called Multi Round-Trip Requests, and it replaces the old server-initiated requests entirely.

The practical consequence is worth stating plainly. If a server needs to remember something across calls, the protocol will not hold it for you. The spec's answer is an explicit, server-minted handle passed back as an ordinary tool argument, which makes the state visible in the call rather than hidden in the connection. For anyone running a gateway or load balancer in front of MCP, this is a meaningful simplification: requests are independently routable because none of them depend on landing on the same server instance twice.

MCP primitives: tools, resources, and prompts

Once a request carries its own capabilities, the interesting question is what it is allowed to ask for. That is what primitives define. Each primitive has standard methods for discovery (a */list method) and for retrieval or execution, and the data layer keeps those method names consistent across every server you connect.

Server primitives

Servers expose three core primitives, which are the ones most people mean when they say "MCP." They differ in one dimension that is easy to miss and important for security: who decides when they are used. Tools are model-controlled, invoked when the model decides an action is needed. Resources are application-controlled, attached to context by the host. Prompts are user-controlled, chosen deliberately by a person. That split is the reason tools carry most of the risk in this section and most of the governance work later in the guide.

Primitive	What it is	Discovery	Use	Who controls it
Tools	Executable functions the model can invoke to take actions	tools/list	tools/call	Model-controlled
Resources	Data sources that supply context to the model	resources/list	resources/read	Application-controlled
Prompts	Reusable templates that structure interactions	prompts/list	prompts/get	User-controlled

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 at request time with tools/list, the set of available tools can change between calls, and servers are now expected to return that list in a deterministic order so clients and caches behave predictably. For a focused deep-dive, see what MCP tools are and how to use them.

Client primitives

This is the other half of the protocol that the 2026-07-28 revision reshaped. MCP used to define three client-side capabilities that servers could reach back into: Roots, Sampling, and Logging. All three are now formally deprecated, still functional inside a minimum twelve-month deprecation window but not something new implementations should adopt. Elicitation is the only client feature the specification still lists as current.

Client feature	Status	What to do instead
Elicitation	Current	Nothing. It is how a server asks the user for input or confirmation, and it is now delivered through the multi round-trip request pattern rather than a server-initiated call.
Roots	Deprecated	Pass directories and files as tool parameters, as resource URIs, or through server configuration.
Sampling	Deprecated	Integrate directly with an LLM provider API instead of borrowing the host's model.
Logging	Deprecated	Write to stderr on stdio, or emit OpenTelemetry. Per-request log level moved into io.modelcontextprotocol/logLevel in _meta, and logging/setLevel was removed.

The through-line is that servers no longer initiate anything. Where a server used to call back into the client with roots/list, sampling/createMessage, or elicitation/create, it now returns an InputRequiredResult and waits for the client to come back. One direction of travel, one place to apply policy.

Notifications and tasks

Notifications are JSON-RPC messages with no response that let a server push updates, such as notifications/tools/list_changed when its available tools change. Subscribing to them changed shape: subscriptions/listen, a single long-lived POST-response stream for the notifications a client opts into, replaces both the old HTTP GET endpoint and the resources/subscribe and resources/unsubscribe pair. Along the way ping, logging/setLevel, and notifications/roots/list_changed were removed outright.

Tasks are the durable-execution wrapper for long-running or expensive operations, giving you deferred result retrieval and status tracking. If you read that they are experimental, that is out of date. Tasks moved out of the core specification and shipped as a stable official extension, io.modelcontextprotocol/tasks. You poll with tasks/get, send client-to-server input with tasks/update, and tasks/list no longer exists.

MCP transports: stdio vs Streamable HTTP

The transport layer defines how those messages actually move. Two transports are current, and the same JSON-RPC data layer rides on either one unchanged.

	stdio	Streamable HTTP
How it works	Standard input and output streams between local processes	HTTP POST for client-to-server messages, with streamed responses
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	OAuth 2.1 with protected-resource metadata. Client ID Metadata Documents are now the preferred registration path, and clients must validate the iss parameter before redeeming an authorization code.
Required headers	Not applicable	Mcp-Method and Mcp-Name on every POST, so a gateway can route a call without parsing the JSON body
Stream recovery	Not applicable	None. Resumability, Last-Event-ID, and SSE event ids were removed, so a broken stream loses the in-flight request and the client must re-issue it with a new request id.
Notification stream	Inline on the same pipe	subscriptions/listen, a single long-lived POST-response stream

Streamable HTTP is the recommended remote transport. It replaced the earlier HTTP-plus-Server-Sent-Events transport in the 2025-03-26 revision, and as of 2026-07-28 that older transport is not merely superseded but formally Deprecated under the project's feature-lifecycle policy. If you are still running it, you have a defined window to migrate, not an indefinite one. For local development and desktop integrations, stdio remains the simplest and fastest option, because it avoids network overhead entirely.

How the MCP specification has evolved

Deprecating a transport is not something a young protocol usually does gracefully, and it is worth understanding why MCP now can. The Model Context Protocol specification is versioned by date, and the project publishes a formal lifecycle policy that governs how features move between states. That policy is the reason you can read a changelog and know exactly what you have to do.

Revision	What it established
2024-11 (launch)	Anthropic releases MCP with JSON-RPC 2.0 messaging, the host/client/server model, and the three server primitives.
2025-03-26	Streamable HTTP replaces the HTTP-plus-Server-Sent-Events transport for remote servers.
2025-12	Governance moves to the Agentic AI Foundation under the Linux Foundation. The protocol becomes vendor-neutral.
2026-07-28	The largest revision since launch: a stateless core, mandatory server/discover, multi round-trip requests, an extensions model, hardened authorization, and a formal deprecation policy.

Three states now govern every feature: Active, Deprecated, and Removed. Anything that becomes deprecated keeps working for a minimum of twelve months before it can be removed, and the project maintains a registry of deprecated features so you can audit an implementation against it rather than guessing. If you built against an earlier revision, this table is your migration list.

If you relied on	Status	Move to
initialize and notifications/initialized	Removed	Per-request version and capabilities in _meta, plus server/discover
Mcp-Session-Id and protocol sessions	Removed	Server-minted handles passed as ordinary tool arguments
Server-initiated requests	Replaced	Multi round-trip requests with InputRequiredResult
Roots, sampling, logging	Deprecated	Tool parameters, direct provider APIs, and stderr or OpenTelemetry
resources/subscribe, the HTTP GET endpoint	Replaced	subscriptions/listen
SSE resumability and Last-Event-ID	Removed	Re-issue the request with a new request id
HTTP-plus-SSE transport	Deprecated	Streamable HTTP
OAuth Dynamic Client Registration	Deprecated	Client ID Metadata Documents, with DCR retained only for backwards compatibility
ping, logging/setLevel, tasks/list	Removed	Per-request io.modelcontextprotocol/logLevel; poll with tasks/get

The other structural change is the extensions model. Rather than growing the core specification indefinitely, capabilities now ship as named, independently versioned extensions that a client and server can negotiate. Tasks was the first major feature to move out this way. MCP Apps, which lets a server render interactive inline UI inside the host rather than returning text, and Skills over MCP are shipping on the same model. This is how the protocol keeps a small, auditable core while still growing, and it is why the security question below is about what you enable rather than what the standard allows.

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	OWASP ranks prompt injection as the top risk for LLM applications, and it is the mechanism behind most agent hijacking
Tool poisoning and rug pulls	Malicious instructions hidden in a tool's description or metadata, or a trusted tool silently swapped for a lookalike	The attack needs no network exploit, because the tool description is already inside the model's context
Data exfiltration	A malicious or compromised server that reads more than its task requires and ships it out through a legitimate-looking call	A malicious server sharing context with a legitimate one can drain data without tripping a single network control
Credential exposure	MCP server configs often hold API keys, database credentials, and service tokens in plaintext	Credentials in server configuration are rarely rotated and rarely scoped, so one leak is a durable one
Confused-deputy authorization	Proxy servers using 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. The 2026-07-28 authorization changes exist largely to close this
Registry and shadow servers	Poisoned registry entries, or unsanctioned servers connected outside any review process	You cannot govern a server you do not know is connected, and registries are now a supply-chain target in their own right
Over-privileged access	Servers and agents granted far broader permissions than the task requires	Expands the blast radius of any single compromise or mistake

Mapping MCP risks to the OWASP MCP Top 10

The list above is the practitioner's view. There is now a standards-body view to check it against: OWASP publishes a dedicated MCP Top 10, separate from the LLM Top 10, covering ten risk categories specific to the protocol rather than to language models generally. It is the right artifact to map your threat model onto, because it names protocol-level problems that a generic LLM risk list does not, including shadow MCP servers and software supply-chain tampering.

Using it well is a two-step exercise. Map each connected server to the categories it plausibly exposes, then confirm you have a named control for each. Most teams find the gap is not in prompt-injection defenses, which get attention, but in the categories about provenance and inventory. Our explainer on the OWASP Top 10 for MCP walks through the ten categories and what each one looks like in a real deployment.

How to secure and govern MCP

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: for remote servers that means OAuth 2.1 with protected-resource metadata, issuer-bound credentials, and iss validation before any authorization code is redeemed. 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. The required Mcp-Method and Mcp-Name headers make this materially easier than it used to be, because a gateway can route and police a call without parsing the JSON body first. Governance then splits into two ongoing jobs: knowing which identity is behind every call, covered in our guide to MCP identity, and proving it to an auditor, covered in our guide to MCP compliance. 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

Governing what you connect only works if you know who is publishing it, which makes the shape of the ecosystem a security question as much as a market one. The major AI providers support MCP, including OpenAI, Google DeepMind, and Microsoft, alongside Anthropic. Official software development kits exist for many languages, and the project reports SDK downloads approaching half a billion per month across its Tier 1 SDKs as of the 2026-07-28 release, which is the clearest available signal that this is infrastructure rather than a trend.

Between the SDKs and production sit the discovery and hosting layers. Developer tooling such as the MCP Inspector helps you test servers locally. MCP catalogs and registries help teams find servers and decide which ones they trust, which is exactly where registry poisoning becomes a supply-chain concern rather than a hypothetical. Once a server is chosen, MCP server hosting covers running it reliably, and an MCP platform covers doing that across an organization with shared policy and identity. With governance under the Linux Foundation's Agentic AI Foundation and a published deprecation policy behind it, the protocol is positioned as durable, vendor-neutral infrastructure rather than one vendor's roadmap.

How MCP compares to related approaches

MCP is easiest to misjudge when you treat it as a competitor to something you already use. In practice it is almost always a layer rather than a replacement: it sits on top of the APIs you have, underneath the function calling your model already does, and beside the agent-to-agent protocols that handle a different problem entirely. Three comparisons come up constantly.

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.

MCP use cases

With the boundaries drawn, the question becomes where MCP actually lands. Each of these leans on a different primitive, which is a useful way to predict how much governance a use case will need.

• Developer tooling: a coding agent reads a repository through resources, then opens a pull request through a tool. The read side is low risk; the write side is where approval gates belong.
• Data and analytics: an assistant calls a read-only query tool against a warehouse, gets a result set back in the content array, and answers over live data instead of a stale export.
• Customer support: an assistant pulls ticket history as a resource, drafts a reply from a shared prompt template, and issues a refund through a tightly scoped tool that requires human confirmation via elicitation.
• Internal knowledge: document stores and wikis exposed as resources so answers are grounded in company information rather than model recall.
• Multi-tool orchestration: one agent coordinating several MCP servers across a multi-step workflow, which is the case where a single gateway stops being a nice-to-have.

Best practices for adopting MCP

Those use cases have a natural order of difficulty, and the teams that get MCP into production without incident tend to follow it rather than jump to the end. Treat adoption as four stages, not a switch.

1. Start read-only. Expose resources and low-risk tools before granting write or destructive actions. Almost every early win is a read.
2. Scope tools tightly. Give each tool the narrowest permissions and the clearest inputSchema you can, so the model cannot construct a call you did not intend to allow.
3. Vet and pin servers. Use trusted sources, review tool descriptions before you enable them, and pin versions so a server cannot silently change behavior underneath you.
4. Govern centrally, then log everything. Route traffic through one control point for authentication, policy, and audit, and keep a trail of which agent called which tool with what arguments.

MCP implementation checklist

Turning those stages into something you can actually check off, here is the sequence for a first production MCP deployment on the current specification.

Phase	Check
Design	Decide which capabilities are resources (application-controlled) and which must be tools (model-controlled). Anything destructive starts as a tool with human confirmation.
Design	Pick the transport. stdio for local and desktop, Streamable HTTP for anything remote. Do not start new work on HTTP-plus-SSE.
Build	Implement server/discover. It is mandatory, and it is how clients learn your supported versions and capabilities.
Build	Write a strict inputSchema for every tool, and return tools/list in a deterministic order.
Build	Carry no session state. If you need continuity, mint an explicit handle and take it back as a tool argument.
Build	Handle resultType on both sides, including the input_required round trip.
Secure	OAuth 2.1 with protected-resource metadata. Use Client ID Metadata Documents rather than dynamic client registration, key persisted credentials by issuer, and validate iss before redeeming a code.
Secure	Treat every tool response as untrusted input. Never let tool output reach a privileged action without a filter in between.
Secure	Map the deployment against the OWASP MCP Top 10 and name a control for each category you are exposed to.
Operate	Front everything with one gateway. Emit Mcp-Method and Mcp-Name so it can route and police calls without parsing bodies.
Operate	Log every call with the agent identity behind it, and wire the log into AI threat detection so anomalous tool use surfaces in real time rather than at audit.
Operate	Re-check the deprecated-features registry each revision. The twelve-month window is a deadline, not a reprieve.

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). Elicitation is the one remaining client feature. Roots, sampling, and logging are now deprecated.

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 are current. stdio for local servers on the same machine, and Streamable HTTP for remote servers, secured with OAuth 2.1. The older HTTP-plus-SSE transport is now formally deprecated.

Is MCP secure? What are the main risks?

MCP can be secured, but it widens the attack surface. Main risks include indirect prompt injection, tool poisoning, credential exposure, confused-deputy authorization, and unvetted or shadow servers. OWASP publishes a dedicated MCP Top 10 that maps these protocol-level risks to named categories, including shadow MCP servers and software supply-chain tampering.

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.

Is MCP stateful or stateless?

Stateless, as of the 2026-07-28 specification. Every request is self-contained and carries its own protocol version and client capabilities. The initialize handshake and the protocol-level session id were both removed, so servers cannot assume prior context.

What changed in the 2026-07-28 MCP specification?

The protocol became stateless, the initialize handshake and session header were removed, server/discover became mandatory, roots and sampling and logging were deprecated, tasks moved to an official extension, and multi round-trip requests replaced server-initiated calls.

Continue learning: MCP resources

This page is the hub for the broader MCP topic. Each guide below goes deeper on one part of it.

• What is MCP - the short explainer, if you want the concept without the specification detail.
• What is an MCP server - what a server actually is, what it exposes, and how a client reaches it.
• MCP servers: build, deploy, and secure - the end-to-end build guide, from a first tool definition to a hardened deployment.
• What are MCP tools - how tools are defined, discovered, and called, including input schemas.
• MCP server hosting - how to run MCP servers in production, covering scaling, isolation, and uptime.
• MCP catalogs and registries - how teams discover servers and decide which ones to trust.
• MCP platform - what it takes to run MCP across an organization with shared policy and identity.
• MCP security best practices - the defensive playbook, control by control.
• MCP security risks - the full risk catalog with attack mechanics for each.
• OWASP Top 10 for MCP - the ten protocol-specific risk categories and what each looks like in a real deployment.
• Prompt injection - the mechanism behind most agent hijacking, direct and indirect.
• MCP tool poisoning - how a malicious tool description attacks the model, and how to catch it.
• MCP data exfiltration - the attack vectors that turn a legitimate-looking call into a data leak.
• What is an MCP gateway - the central control point for authentication, policy, and audit across every server.
• MCP proxy - how a proxy sits in the call path and what it can enforce there.
• MCP access control - scoping what each agent and tool is allowed to reach.
• MCP authentication - OAuth 2.1, protected-resource metadata, and getting tokens right.
• MCP identity - knowing which human or agent identity is behind every call.
• MCP compliance - proving your MCP controls to an auditor.
• AI threat detection - catching anomalous agent and tool behavior in real time.
• MCP vs A2A - how the tool-access layer differs from the agent-to-agent layer.

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.