What Is the Model Context Protocol (MCP)? An Enterprise Guide

The Model Context Protocol (MCP) is an open standard that defines how AI applications discover and call external tools, read data, and load prompt templates through one JSON-RPC 2.0 interface, so a capability built once as an MCP server works in any compliant AI client. Anthropic released MCP on November 25, 2024, and donated it on December 9, 2025 to the Agentic AI Foundation, a directed fund of the Linux Foundation. The current specification revision, 2026-07-28, made the protocol stateless, deprecated the Roots, Sampling, and Logging features, and moved long-running tasks into an optional extension. For an enterprise, MCP is the integration layer between AI assistants or agents and systems of record, so the decisions that matter are which servers you approve, which identity each one runs as, and what you log.

MCP at a glance

The table answers the first questions buyers ask, using the 2026-07-28 specification as the reference point.

Who created MCP, and who governs it now?

Anthropic created MCP and open-sourced it on November 25, 2024, shipping the specification, SDKs, local server support in the Claude Desktop apps, and reference servers for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer, according to Anthropic's launch announcement. Four dated revisions followed. The 2025-03-26 revision added OAuth 2.1 authorization and replaced the original HTTP+SSE transport with Streamable HTTP, per the 2025-03-26 changelog. Later revisions added elicitation, structured tool output, and Client ID Metadata Documents, and 2026-07-28 rebuilt the core as a stateless protocol.

On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), which the Linux Foundation launched with MCP, Block's goose, and OpenAI's AGENTS.md as founding projects and with Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI as platinum members. The MCP governance page gives final authority to individual Lead Maintainers, currently David Soria Parra and Den Delimarsky, and routes every specification change through a Specification Enhancement Proposal (SEP). Seats belong to people, so no company holds a reserved seat. At the donation, Anthropic reported more than 10,000 active public MCP servers, and at the 2026-07-28 release the maintainers reported that the four Tier 1 SDKs (TypeScript, Python, Go, and C#) were close to half a billion downloads a month.

How MCP works: hosts, clients, and servers

MCP uses a client-host-server architecture. The host is the AI application the user works in, such as a chat app, an IDE, or an agent runtime, and it runs the model, collects consent, and decides what context each server receives. Inside the host, each MCP client holds a one-to-one connection with a single server. A server exposes a focused set of capabilities, runs as a local process or a remote service, and sits in front of a real system: a file share, a database, a ticketing platform, or a SaaS API.

The architecture section of the specification sets a design rule worth holding every implementation to: servers should not be able to read the whole conversation or see into other servers, and the host controls every cross-server interaction. That makes the host the enforcement point for consent and data sharing, and it makes each server's credentials the ceiling on what a misled model can reach through that server.

What are MCP tools, resources, and prompts?

MCP servers offer three primitives, and a different party controls each one. Clients offer elicitation back to servers. Two other client features, Sampling and Roots, are deprecated in 2026-07-28 and, under the deprecated features registry, keep working for at least twelve months.

Two rules in the tools specification shape enterprise design: there SHOULD always be a human in the loop with the ability to deny tool invocations, and clients MUST treat tool annotations, such as a read-only hint, as untrusted unless they come from a trusted server. The elicitation specification adds a third: servers MUST NOT use form mode to collect passwords, API keys, access tokens, or payment credentials, and must use URL mode so the secret never passes through the client or the model.

What changed in the 2026-07-28 specification?

The 2026-07-28 revision is the largest change since launch. The maintainers' release post describes a move from a bidirectional stateful protocol to a request and response stateless one, so remote servers no longer need sticky sessions or a shared session store, and any server instance can answer any request behind an ordinary load balancer. The 2026-07-28 changelog lists the changes implementers feel most:

• The initialize handshake and the Mcp-Session-Id header are gone, and every request carries its protocol version and client capabilities in _meta.
• Every server MUST implement server/discover, which returns its supported versions, capabilities, and identity.
• Multi Round-Trip Requests (MRTR) replace server-initiated requests: the server returns an InputRequiredResult, and the client retries the call with the answers.
• Streamable HTTP requests carry Mcp-Method and Mcp-Name headers, so gateways can route traffic without parsing the body.
• Tasks moved into an official extension, and Roots, Sampling, Logging, and RFC 7591 client registration are deprecated.

Compatibility is the operational issue. The versioning rules call 2026-07-28 and later revisions modern and 2025-11-25 and earlier revisions legacy, and a modern-only client fails against a legacy-only server. Run dual-era servers until every client in your estate speaks the new revision.

MCP transports: stdio and Streamable HTTP

MCP defines two standard transports. stdio runs the server as a subprocess the client launches, exchanges newline-delimited JSON-RPC over standard input and output, and gives the server the user's privileges on that machine. Streamable HTTP exposes one endpoint that accepts a POST for every message and answers with JSON or a server-sent events stream scoped to that request. It replaced the HTTP+SSE transport of 2024-11-05, which the specification now classifies as Deprecated.

The Streamable HTTP binding sets three checks for every remote server review. Servers MUST validate the Origin header to block DNS rebinding, local servers SHOULD bind to 127.0.0.1, and servers MUST reject requests whose MCP headers do not match the JSON body, so a gateway and a server never act on different values.

How does MCP authorization work?

MCP authorization is optional, applies to HTTP transports, and follows a profile of OAuth 2.1; stdio servers take credentials from the environment instead. A protected MCP server acts as an OAuth 2.1 resource server and MUST publish Protected Resource Metadata (RFC 9728) that points clients to its authorization server. The client uses PKCE (RFC 7636) and MUST send a resource indicator (RFC 8707) naming the exact server, so each token is bound to one server as its audience, per the MCP authorization specification.

Three more rules close common gaps. Servers MUST NOT accept or pass through tokens issued for anything else, which rules out token passthrough. Clients MUST check the issuer (iss) parameter under RFC 9207 when the authorization server returns it, which defeats mix-up attacks. Clients and authorization servers SHOULD support Client ID Metadata Documents, where an HTTPS URL serves as the client ID. Servers name the scopes they need in WWW-Authenticate challenges, so a client can start with read scopes and step up only when a write tool needs more.

For enterprises, the most useful piece is the Enterprise-Managed Authorization extension, which makes the identity provider, such as Okta or Microsoft Entra ID, the authority on which MCP servers each employee can reach. The client exchanges the user's corporate identity assertion for an Identity Assertion JWT Authorization Grant (ID-JAG), and revoking access at the identity provider takes effect across every client. Client support varies, so confirm it for each host you deploy.

Is there an MCP registry?

Yes. The official MCP Registry launched in preview on September 8, 2025 at registry.modelcontextprotocol.io and is still labeled preview as of October 2026. It stores metadata only: a server.json record that points to a package on a public registry such as npm, PyPI, NuGet, or Docker Hub, or to a remote URL, with server names tied to verified GitHub accounts or domains. It leaves security scanning to the package registries and downstream aggregators, and it does not accept private servers.

That last point shapes enterprise design. The registry maintainers recommend that organizations host their own private registry for internal servers, and they publish an OpenAPI specification that private registries can implement so host applications can read from them. On the client side, VS Code offers an MCP server gallery and lets organizations manage MCP access centrally through Copilot enterprise-managed settings.

MCP vs API: what is the difference?

An API is the interface a system publishes for programs. MCP packages capabilities, usually built on those APIs, so AI applications can find and use them at runtime. Function calling is the model side of the exchange: the developer declares functions, the model returns a structured call, and, as Google's Gemini function calling guide notes, the application executes it because the model does not. MCP standardizes how the application finds the tool and reaches the system behind it.

BD Emerson's rule: build an MCP server when three conditions hold. More than one AI client needs the capability, the model has to decide when to call it, and the capability fits a tool schema a reviewer can audit. If any condition fails, call the API from ordinary code. The arithmetic explains the appeal. An organization with four AI clients and six internal systems needs 24 point-to-point integrations without a shared protocol, and 10 implementations with one: four MCP clients and six MCP servers.

Who supports MCP?

As of October 2026, the major model providers and developer tools support MCP, each with a different subset of the specification. The Linux Foundation's December 2025 announcement named Claude, Cursor, Microsoft Copilot, Gemini, VS Code, and ChatGPT among adopters, and the table records what each vendor documents.

Enterprise use cases for MCP

Production MCP use cases share one trait: the model chooses among several actions in systems the company already runs. The table pairs each pattern with its primitives and the control security reviewers ask about first.

How to deploy MCP servers inside a company

Deploy MCP the way you would deploy any integration platform that holds credentials: a short list of approved servers, one controlled path to reach them, a distinct identity per server, and logs you can replay. BD Emerson recommends this rollout order, and each step traces to the specification or the registry documentation.

1. Run a private registry and an allowlist. Publish approved servers in a private registry that implements the MCP Registry OpenAPI specification, pin versions, and review full tool definitions before approval, because descriptions go straight into the model's context.
2. Put a gateway in front of remote servers. One gateway authenticates users, enforces the allowlist, and routes on the Mcp-Method and Mcp-Name headers without parsing request bodies.
3. Give each server its own audience-bound identity. Use Enterprise-Managed Authorization where clients support it, and keep scopes_supported minimal.
4. Gate side effects. Require human approval for tools that send, delete, pay, publish, or change permissions, and keep tools that read untrusted content out of any conversation that can send data out.
5. Log every call with trace context. Record the tool name, arguments, identity, and approval decision, and propagate the OpenTelemetry traceparent value in _meta so one call can be traced from host to system of record.
6. Sandbox local servers. Run stdio servers in containers with restricted file system and network egress, and use clients that show the exact launch command before install, as the MCP security best practices recommend.

The threats these controls answer, including tool poisoning, prompt injection through tool results, and the confused deputy, are covered in MCP security explained, and the agent-level threat model is in securing AI agents. Unapproved MCP servers on employee laptops are a form of shadow AI, and the same discovery methods find them.

How BD Emerson helps

BD Emerson designs and builds MCP servers and agentic systems through its AI integration services. The agentic AI security practice reviews MCP architectures against the controls above, and our offensive team tests deployed agents and servers with AI red teaming methods: tool poisoning, injection through tool results, scope abuse, and cross-server interaction against the real configuration.

Frequently asked questions

Is MCP an Anthropic product? Anthropic created MCP and released it as an open standard on November 25, 2024, then donated it to the Agentic AI Foundation under the Linux Foundation on December 9, 2025. Individual maintainers run the project through Specification Enhancement Proposals, and any vendor can implement it. OpenAI, Google, Microsoft, and AWS document MCP support in their own products.

What is an MCP server? An MCP server is a program that exposes tools, resources, or prompts to AI applications through the Model Context Protocol. It usually wraps an existing system, such as a database, a ticketing platform, or a SaaS API, and runs as a local process over stdio or as a remote service over Streamable HTTP. Each server should hold only the credentials and scopes its tools need.

Does MCP replace APIs? No. Most MCP servers call existing APIs underneath. MCP adds a standard way for AI applications to discover capabilities at runtime, call them with a consistent message format, and authorize access per server. Keep direct API calls for deterministic, high-volume jobs, and use MCP where a model chooses among actions or several AI clients share a capability.

Is MCP secure? MCP defines security requirements, including audience-bound OAuth tokens, Origin header validation, and human approval for tool calls, but the protocol cannot enforce how a deployment uses them. Most risk sits in configuration: which servers you trust, what scopes they hold, and which tools share a conversation. An allowlist, a gateway, per-server identities, and complete logging address most of it.

What changed in the 2026-07-28 MCP specification? The 2026-07-28 revision made MCP stateless. It removed the initialize handshake and protocol sessions, added the server/discover method, replaced server-initiated requests with Multi Round-Trip Requests, and added routing headers for gateways. It also deprecated Roots, Sampling, Logging, and RFC 7591 client registration, and keeps each deprecated feature working for at least twelve months.

Is MCP free to use? Yes. MCP code and specifications are published under the Apache License 2.0, and its documentation under Creative Commons Attribution 4.0. There is no license fee to build a client or a server. The cost sits in engineering and operations: building servers, running a registry and gateway, and testing the deployment.

Which AI tools support MCP? As of October 2026, MCP support is documented for Claude and the Claude API, OpenAI's Responses API, Gemini CLI and Google-managed MCP servers, VS Code and Microsoft Copilot Studio, and Amazon Bedrock AgentCore Gateway. Some clients implement only tools, so confirm which primitives a client supports before relying on resources, prompts, or elicitation.

If you're planning an MCP rollout, our AI integration team can help you choose which systems to expose first, build the servers, and put the registry, gateway, and identity controls in place before the first agent goes live.