MCP Explained: The Enterprise Guide to Servers, Gateways and Security

Last updated October 14, 2026. Protocol details were checked against the 2026-07-28 Model Context Protocol specification, the official MCP docs, and vendor pages on that date.

An MCP server is a program that exposes tools, data, and prompt templates to AI applications through the Model Context Protocol (MCP), an open standard Anthropic released in November 2024. In 2026 it is the default way agents in Claude, ChatGPT, Copilot, Cursor, and custom stacks reach company systems, and the protocol now sits under the Linux Foundation.

That reach is why security and platform teams now own MCP decisions. Every server is a new path into a system of record, and every agent that calls it acts with someone’s credentials. This guide explains the protocol, separates servers from gateways, registries, and security layers, and lays out the production patterns we see working.

It is the pillar for our MCP coverage under MCP and Agent Protocols, and it pairs with the AgentOps tools map for the tracing and eval side of the same agents. Vendor mentions are unpaid, per our editorial standards and disclosure policy.

What Is MCP? The Model Context Protocol Explained

The Model Context Protocol is an open standard that defines how an AI application discovers and calls outside capabilities. A host such as Claude or VS Code runs one MCP client per connection, and each client talks to an MCP server that exposes tools, resources, or prompts. Messages use JSON-RPC 2.0, so any language can implement either side.

Anthropic open sourced MCP in November 2024 with a specification, software development kits (SDKs), local server support in Claude Desktop, and reference servers for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer, per its launch announcement. The design borrows from the Language Server Protocol, which standardized how code editors talk to programming language tooling. MCP applies the same idea to AI applications and the systems they need to reach.

The problem it solves is integration math. Without a shared protocol, every pairing of an AI client and a data source needs its own connector, so 10 clients and 50 systems can mean up to 500 custom integrations. With MCP, each system ships one server and each client implements the protocol once.

Who governs MCP now

In December 2025 Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI with support from Google, Microsoft, Amazon Web Services (AWS), Cloudflare, and Bloomberg. The Linux Foundation announcement counted more than 10,000 published MCP servers at the time. Technical direction stays with the MCP maintainers and steering group, so the specification process did not change.

For enterprise buyers, foundation governance lowers the risk that one vendor steers the protocol toward its own platform. It also explains why competing model providers and clouds ship MCP support instead of rival standards, per Anthropic.

Why enterprises care in 2026

MCP moved from a developer convenience to an enterprise control problem in about 18 months. Coding agents on laptops connect to local servers with shell and file access, and chat assistants connect to software as a service (SaaS) tools through remote servers. Background agents call internal application programming interfaces (APIs) without a person watching each step, and each of those paths needs identity, permissions, and an audit trail a security team can review.

• Reach: one server can expose every object in a ticketing system, data warehouse, or customer database to any connected agent.
• Delegated authority: tools run with a user’s OAuth token or a service credential, so a bad tool call carries real permissions.
• Sprawl: developers add servers from public directories faster than procurement or security can review them.
• Cost and latency: tool definitions and results add tokens to every model call, and tool round trips show up in agent traces and budgets.

How MCP Works: Hosts, Clients, Servers, and Transports

MCP has three participants and two layers. The host is the AI application, the client is the connector the host creates for each server, and the server provides context and actions. A data layer defines the JSON-RPC messages and primitives, and a transport layer carries them over stdio on one machine or Streamable HTTP across a network.

Participant	What it is	Examples
Host	AI application that coordinates one or more MCP clients	Claude Desktop, Claude Code, VS Code, Cursor, ChatGPT
Client	Connector inside the host with a dedicated connection to one server	One client object per configured server
Server	Program that exposes tools, resources, and prompts	GitHub, Sentry, filesystem, wrappers around internal APIs

Local servers on stdio usually serve one client, while remote servers on Streamable HTTP serve many, per the architecture overview. The term MCP server describes the program regardless of where it runs.

Server primitives: tools, resources, and prompts

Servers expose three primitives. Tools are functions the model can call, such as creating a ticket or running a query. Resources are readable context identified by URIs, such as a file, a schema, or a record, and prompts are reusable templates that users trigger, often as slash commands.

Tools are the primitive security teams should watch most closely, because the specification treats every tool as arbitrary code execution. The spec also says tool descriptions and annotations should be treated as untrusted unless they come from a trusted server, and hosts must obtain user consent before invoking a tool, per the MCP specification.

Client features and extensions

Clients can offer elicitation, which lets a server ask the user for missing input in the middle of a task. Sampling and Roots still work but are deprecated in the 2026-07-28 revision, with a minimum 12 month window before removal. Optional extensions add Tasks for long running operations, Skills over MCP for structured agent instructions, and MCP Apps for interactive interface elements rendered inside the conversation.

Transports: stdio, Streamable HTTP, and the legacy HTTP+SSE path

The stdio transport runs the server as a subprocess of the client and exchanges newline delimited JSON-RPC over standard input and output. It is the default for local servers and serves a single client. Streamable HTTP sends each message as an HTTP POST to one endpoint, with replies returned as JSON or a request scoped Server-Sent Events (SSE) stream, and it is how remote servers serve many clients.

The older HTTP+SSE transport has been deprecated since the 2025-03-26 revision and is now formally on the removal track, per the transports spec. If a vendor server still requires the legacy SSE endpoint, treat that as a maintenance signal during review.

Transport	Where it runs	Typical auth	Enterprise note
stdio	Local subprocess on the host machine	Environment variables or local config	Inherits the user’s operating system permissions, so sandbox it
Streamable HTTP	Remote endpoint, vendor hosted or self hosted	OAuth 2.1 bearer tokens	Mcp-Method and Mcp-Name headers let gateways route per tool
HTTP+SSE (legacy)	Remote endpoint	Varies by server	Deprecated; plan the migration now

What Changed in the 2026-07-28 Specification

The July 2026 revision is the largest change since launch. It made MCP stateless by removing the initialize handshake and the Mcp-Session-Id header, so every request carries its own protocol version and client capabilities. That design suits load balancers and gateways, because any server instance can answer any request without sticky sessions.

• Stateless requests: version and capabilities travel in each request’s _meta field, and a new server/discover call advertises what a server supports.
• Multi round trip requests: servers return an input_required result instead of sending their own requests, and the client retries with the answers.
• Subscriptions: a single subscriptions/listen stream replaces the old GET endpoint and the resource subscribe calls.
• Caching hints: list and read results carry ttlMs and cacheScope, so clients and shared intermediaries can cache tool lists safely.
• Routing headers: Streamable HTTP requests must send Mcp-Method and Mcp-Name headers, which lets a gateway apply policy per tool without parsing the body.
• Tracing: the spec documents OpenTelemetry trace context (traceparent, tracestate, and baggage) in _meta, which ties tool calls to agent traces.
• Deprecations: Sampling, Roots, Logging, the HTTP+SSE transport, and Dynamic Client Registration are all on the removal track.

Ask every server and gateway vendor which protocol revisions they support, since mixed fleets need clients that handle both the session based and the stateless protocol eras. The complete list is on the official key changes page.

Servers, Gateways, Registries, and Security Layers: A Clear Taxonomy

Most MCP confusion comes from vendors using one word for four jobs. A server exposes capabilities, a gateway sits in front of many servers to enforce identity and policy, a registry answers which servers exist and where to get them, and a security layer inspects definitions and traffic for threats. Large deployments use all four.

Layer	Job	Examples	Usual owner
MCP server	Exposes tools, resources, and prompts for one system	GitHub, Sentry, Notion, Stripe, internal API servers	System or app team
MCP gateway	Single entry point for auth, tool policy, credential injection, and audit	Kong AI Gateway, AWS AgentCore Gateway, Docker MCP Gateway, Microsoft MCP Gateway	Platform or security
Registry or catalog	Discovery metadata, versions, install details, and approved lists	Official MCP Registry, GitHub MCP Registry, Smithery, Docker MCP Catalog	Platform, with security review
Security layer	Scans definitions, inspects traffic, and inventories unsanctioned servers	Package scanners, injection detection, endpoint inventory tools	Security

MCP servers

Servers come in three deployment shapes. Vendor hosted remote servers, such as the official Sentry or GitHub servers, run on Streamable HTTP and authenticate with OAuth. Internal servers wrap your own APIs and databases, and local servers run on a developer laptop over stdio with whatever file and shell access that machine allows.

Prefer an official server from the system vendor over a community clone with the same name. The postmark-mcp incident covered below started with exactly that kind of impersonation.

MCP gateways

A gateway is a reverse proxy and control plane for MCP traffic. Clients connect to one endpoint, users sign in once, and the gateway decides which tools each person or agent may call. It also injects upstream credentials and writes a log entry for every call.

Options range from API platforms that added MCP, such as Kong AI Gateway and AgentCore Gateway, to dedicated governance products and open source routers. AWS describes AgentCore Gateway as a managed entry point that converts APIs, Lambda functions, and existing services into MCP tools with ingress and egress authentication, per its developer guide. The AI Gateways category covers the model routing side of the same pattern.

Registries and catalogs

The official MCP Registry is a centralized metadata repository for publicly accessible servers, backed by contributors including Anthropic, GitHub, PulseMCP, and Microsoft. It stores a server.json record with a namespaced name, a package or remote URL, and run instructions, and it verifies namespaces through DNS. It is still in preview and does not list private servers, so the docs recommend hosting your own private registry for internal ones.

Downstream catalogs add curation on top, per the registry docs. The GitHub MCP Registry lists installable servers with usage counts, and Smithery adds hosted connections with OAuth flows handled for the agent. The Docker MCP Catalog ships more than 300 verified servers as container images with versioning and provenance.

Treat public registries as discovery tools, then publish only approved, pinned servers in an internal catalog that your clients are configured to use.

Security layers

Security layers focus on what a gateway alone does not see. They scan tool definitions for hidden instructions, check outputs for prompt injection and data leakage, and inventory servers configured on laptops that never touch the sanctioned gateway. Some gateway vendors bundle these controls, and others sell them to the security team as a separate product.

MCP Security for Enterprises: The Risks That Matter

MCP security failures cluster in five places: weak authorization, over scoped tokens, untrusted servers, prompt injection through tool content, and missing audit trails. The official security best practices page documents attacks such as confused deputy, token passthrough, server side request forgery (SSRF), and local server compromise. Map your controls to that list before you add servers.

Authentication and authorization with OAuth 2.1

For HTTP transports, the specification builds authorization on OAuth 2.1. The MCP server acts as a protected resource, a separate authorization server issues tokens, and clients discover that server through metadata before running the flow, per the authorization spec. Authorization is optional in the protocol, which is why enterprises enforce it at the gateway instead of trusting each server.

Client registration is shifting. Dynamic Client Registration let any client mint a client ID with little verification, and it is now deprecated in favor of Client ID Metadata Documents (CIMD), where the client ID is an HTTPS URL an allowlist can name. Allowlist CIMD domains for internal servers, and require clients to validate the iss parameter, which the 2026 revision made mandatory whenever the authorization server sends it.

Permissions and scope design

The spec forbids token passthrough, where a server forwards a client token to a downstream API without checking that the token was issued for that server. Servers should validate the audience claim and use their own credentials or a token exchange for upstream calls, per the security best practices. Scope design matters as much, since a token that can read and write every project turns one bad tool call into a broad incident.

• Split read and write tools so policy can allow search everywhere and require approval for create, update, or delete.
• Scope tokens per server and per role instead of issuing one broad token per user.
• Require human approval for irreversible actions such as payments, outbound email, or production changes.
• Keep service accounts narrow for background agents that run without a person in the loop.

Anthropic took some internal evaluations off the live internet after agents in its tests took unintended real world actions, which we covered in Anthropic pulls internal evals after AI agents overstep. The lesson for MCP is that write capable tools need explicit approval paths before agents get them.

Data exfiltration and prompt injection

An agent with access to private data, exposure to untrusted content, and a tool that can send data out can be steered into leaking that data. Malicious text in a GitHub issue, a web page, or an email can instruct the model to call a tool it should not. Hidden instructions inside tool descriptions, often called tool poisoning, work the same way at install time.

Break that combination by keeping untrusted content and outbound tools on separate servers or in separate agent sessions. Gateways help by enforcing egress allowlists, masking secrets and personal data in responses, and logging every tool call with its arguments.

Supply chain risk in MCP servers

In September 2025, Koi Security and Snyk documented postmark-mcp, an npm package that impersonated Postmark’s official server and, from version 1.0.16, silently copied every outgoing email to an attacker controlled address. Koi Security described it as the first malicious MCP server found in the wild, and the analysis by Snyk traced the leak to a single added BCC line. Postmark confirmed the package was never its own.

In July 2025, JFrog disclosed CVE-2025-6514, a critical flaw with a Common Vulnerability Scoring System (CVSS) score of 9.6 in the popular mcp-remote proxy. It allowed operating system command execution when a client connected to a malicious remote server, per JFrog. Both incidents point to the same controls: pin versions, prefer official publishers, scan packages before approval, and run local servers in containers with minimal privileges.

Audit and compliance

Auditors will ask who called which tool, with what arguments, on whose authority, and what came back. Logs scattered across laptops cannot answer that consistently, which is the strongest argument for routing production traffic through a gateway. Export those records to your security information and event management (SIEM) system with the user, client, server, tool name, and policy decision on every entry.

Risk	Control	Where it lives
Confused deputy and token passthrough	Audience validation, per server tokens, consent per client	Server and gateway
Malicious or impersonated servers	Approved catalog, pinned versions, package scanning	Registry and security layer
Prompt injection and tool poisoning	Definition scanning, output inspection, split untrusted content	Security layer and agent design
Data exfiltration	Egress allowlists, data loss prevention masking, read and write split	Gateway
Local server compromise	Containers, consent before install, no open localhost listeners	Endpoint and client config
Missing audit trail	Per call logs with identity, exported to the SIEM	Gateway

Our agent security category tracks the guardrail products that sit around these controls.

When to Use an MCP Gateway Versus Direct Server Connections

Use direct connections while one team runs a handful of read only servers with no regulated data. Add a gateway once several teams share servers, tools can write to systems of record, or auditors need one log of every call. The trigger is usually the first security review, well before any traffic limit.

Signal	Direct connections	Gateway
Teams	One team with known users	Several teams or a company wide rollout
Servers	Under 10, mostly vendor hosted	10 or more, mixed internal and vendor
Tool risk	Read only	Write, delete, payments, or outbound messages
Identity	Per server OAuth is acceptable	Directory identity and offboarding required
Audit	Client logs are enough	Central log and SIEM export required
Unsanctioned servers	Not a concern yet	Laptop inventory needed

A gateway does not make an unsafe server safe, because a compromised server behind it can still return poisoned content. Treat the gateway as the place where identity, policy, and audit converge, and keep server review in the approval process.

Practical Architecture Patterns for Production MCP

Production MCP deployments tend to follow four patterns, and most enterprises run more than one. Platform teams centralize remote servers behind a gateway, and developers keep sandboxed local servers for coding agents. Internal APIs become MCP servers behind the same gateway, and agents in a cloud account use that provider’s managed gateway.

Pattern 1: centralized gateway for remote servers

All sanctioned clients point at one gateway URL. Users sign in with single sign-on (SSO), the gateway maps directory groups to tool permissions, and upstream OAuth tokens live in its vault instead of on laptops. This is the default for chat assistants and company wide rollouts.

Pattern 2: sandboxed local servers for coding agents

Coding agents need filesystem and shell tools that only make sense locally. Run those servers in containers with mounted project directories, no access to private keys or cloud credentials, and outbound network rules, which is the model Docker’s MCP Toolkit packages. Pair it with an endpoint inventory so security can see which servers each laptop runs.

Pattern 3: internal APIs as MCP servers

Many teams expose existing internal services as MCP servers instead of writing new integrations. Gateways from Kong and AWS can convert OpenAPI definitions into tools, and the official SDKs make a thin wrapper a short project. Keep the wrapper narrow, with task shaped tools such as get_invoice in place of a generic call_any_endpoint tool.

Pattern 4: managed gateway inside one cloud

Agents that already run on a cloud platform can use that provider’s managed gateway, such as Amazon Bedrock AgentCore Gateway, with identity from the cloud’s identity and access management (IAM) service or an OpenID Connect (OIDC) provider. It removes infrastructure work, though it only sees traffic inside that account. Laptop and third party traffic still need pattern 1 or pattern 2.

Anti-patterns to avoid

• One shared admin token behind a server that every agent uses.
• Installing servers from public directories straight into production clients without review.
• Generic passthrough tools that let the model call any endpoint with any payload.
• No version pinning, so a new package release changes behavior overnight.

How MCP Connects to AgentOps and Observability

Every MCP tool call is a step in an agent run, so it belongs in the same traces as model calls, retrieval, and evals. The 2026-07-28 revision documents OpenTelemetry trace context in request metadata, which lets a gateway or server continue the trace the agent started instead of producing an isolated log line.

In practice that means three joins. Tool spans should carry the server, tool name, latency, and result size, and gateway decisions should link to the same trace ID. Eval suites should test tool selection as well, since a wrong tool choice rarely shows up as an error, and our AI agent observability tools roundup, open source LLM observability guide, and AI agent evaluation tools list cover each side.

Budget follows the same path. Tool descriptions and results add tokens to every prompt, so long tool lists raise cost and latency, and that spend belongs next to tracing spend in LangSmith vs Langfuse vs Braintrust pricing. The AgentOps tools map shows where gateways and guardrails sit in the wider stack.

Most agent frameworks now ship MCP client adapters, so compare that support when you choose one in our AI agent frameworks comparison. Teams on Anthropic’s hosted runtime can follow the Claude Managed Agents release notes for platform changes.

MCP Rollout Checklist for Platform and Security Teams

A safe rollout starts small and adds controls before adding servers. Inventory what is already configured on laptops, approve a short list of official servers, put identity and audit in front of anything that writes, and connect tool calls to your tracing stack. Then expand team by team, with each new server going through the same review.

1. Inventory: find MCP configs in Claude, Cursor, VS Code, and other clients across managed devices.
2. Approve: publish a private catalog of pinned, official servers with a named owner for each.
3. Authenticate: require OAuth 2.1 with CIMD or preregistered clients, and retire shared static keys.
4. Authorize: map directory groups to tools, and require approval for write actions.
5. Isolate: run local servers in containers and block outbound traffic they do not need.
6. Observe: send per call logs to the SIEM and trace context to your observability tool.
7. Review: recheck servers on every version bump, and retire servers no team owns.

Frequently Asked Questions

Related Guides

Once the protocol basics are clear, the next decision is usually where the gateway runs. Kong vs AWS AgentCore vs Docker compares the three most common MCP gateway defaults side by side.

• MCP category hub and MCP and Agent Protocols
• AgentOps tools map and AI Gateways
• 12 Best AI Agent Observability Tools and open source LLM observability
• AI agent evaluation tools and 12 Best AI Agent Frameworks
• LangSmith vs Langfuse vs Braintrust pricing and Langfuse vs LangSmith vs Braintrust
• Agent security and Anthropic evals and agents that overstep
• Editorial standards, disclosure, and contact