Model Context Protocol: What MCP Means for Enterprise AI

The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in November 2024, for connecting AI applications to external systems: data sources, tools, and workflows. Its practical value to an enterprise is that it collapses the integration problem: instead of building a custom connector for every pairing of AI application and internal system, a team builds one MCP server per system and any MCP-compatible application can use it. For a leader, the decision is not whether MCP is interesting technology, but whether standardizing your AI-to-systems plumbing on it reduces long-term integration cost and vendor lock-in enough to justify operating servers as governed infrastructure. This article explains what MCP is, how it works, who has adopted it, the security questions it raises, and what to do now.

Key takeaways

MCP standardizes the connection between an AI model and external tools, data, and prompts. The official framing is that it is "a USB-C port for AI applications," and it addresses an N-by-M integration problem by turning N applications times M tools into N plus M.
Adoption crossed vendor lines quickly. OpenAI adopted MCP in March 2025, Google DeepMind announced support in April 2025, and Microsoft brought MCP to general availability in Copilot Studio in May 2025, alongside Anthropic's own Claude products and major developer tools.
MCP does not replace function calling. Function calling is how a model invokes a tool inside one application; MCP is how reusable tools and context get distributed across many applications. Production systems commonly use both.
MCP introduces new trust boundaries. The official security guidance forbids token passthrough and prohibits using sessions for authentication, and independent researchers flag tool poisoning, over-privileged access, and audit blind spots as the primary enterprise risks.
The recommended enterprise pattern is a governed central registry of servers with consistent access policy, not ad-hoc point-to-point connections between agents and servers.

What exactly is the Model Context Protocol, and why should a leader care?

MCP is an open standard for wiring an AI application up to the outside world: files and databases, search engines and APIs, and reusable prompt workflows. Anthropic describes the underlying problem plainly, noting that even sophisticated models are "constrained by their isolation from data, trapped behind information silos," and that "every new data source requires its own custom implementation, making truly connected systems difficult to scale." MCP replaces those bespoke implementations with a single protocol.

The reason this matters to a leader is economic, not merely architectural. Before MCP, connecting N AI applications to M internal systems meant up to N times M custom connectors, each with its own authentication, data schema, and transport. MCP turns that into N plus M: a system owner writes one MCP server, an application vendor writes one MCP client, and they interoperate. The official shorthand is "build once and integrate everywhere." This is the same combinatorial problem that standards such as USB, the Language Server Protocol, and ODBC solved in their own domains, now applied to model context and tool use.

One point of scope is worth internalizing before you evaluate MCP: it is deliberately narrow. Per the specification, MCP "focuses solely on the protocol for context exchange" and "does not dictate how AI applications use LLMs or manage the provided context." It standardizes the plumbing between a model and external capabilities, not the model's reasoning or your orchestration logic. That narrowness is a feature. It is what lets the protocol stay stable while the models and agent frameworks above it change. If you are already implementing agentic orchestration with Anthropic APIs, MCP is the standardized tool and context layer that such an orchestration depends on, sitting below your agent logic rather than replacing it.

How does MCP actually work under the hood?

MCP is a stateful client-server protocol with three roles, two layers, and a small set of primitives. A leader does not need to implement it, but understanding the shape of it clarifies where cost, control, and risk actually live.

Participants: hosts, clients, and servers

There are three roles. The host is the AI application itself, for example Claude Desktop, Claude Code, VS Code, Cursor, or ChatGPT; it owns the interaction with the language model and coordinates one or more clients. A client is a connector component inside the host that maintains one dedicated, stateful connection to exactly one server. A server is a program that exposes capabilities. The host instantiates one client per server, so a host connected to three servers runs three clients, each holding its own one-to-one connection.

Servers run in one of two places. Local servers typically communicate over standard input and output and serve a single client, which suits a filesystem or a local database. Remote servers typically use HTTP and serve many clients concurrently, which suits a shared enterprise service. The distinction matters for governance: a remote server is a piece of infrastructure you host, secure, and monitor like any other network service.

Two layers: data and transport

MCP is defined as a data layer wrapped by a transport layer. The data layer is a JSON-RPC 2.0 protocol that defines message structure and semantics: lifecycle, the primitives, and notifications. It is transport-independent. The transport layer is the concrete channel that handles connection setup, message framing, and authorization. Because the same JSON-RPC message format runs over any transport, the two standard transports (local standard input/output and Streamable HTTP over a single endpoint) are interchangeable from the model's point of view.

Lifecycle and capability negotiation

Every connection opens with an initialization handshake. The client sends an initialize request carrying its protocol version (for example "2025-06-18") and the capabilities it supports; the server replies with its own negotiated version and capabilities; the client then sends an initialized notification to signal readiness. If no mutually compatible protocol version exists, the connection is terminated. This negotiation is what stops either side from calling operations the other does not support, and it is why "supports MCP" is not a single binary fact but a set of negotiated capabilities.

Primitives: what actually gets exposed

Primitives are the heart of the protocol. A server can expose three, and the "controlled by" distinction is the key mental model for a leader thinking about risk and governance:

Tools are executable functions the model can invoke to take action, such as API calls, database writes, or file operations. They are model-controlled: the language model decides when to call them. This is where real-world side effects, and therefore most of the risk, live.
Resources are passive, read-only context data addressed by a URI, such as file contents, schemas, or records. They are application-controlled: the host decides how to fetch and inject them. Because the application decides how to use returned data (inject it wholesale, embed and rank it, or search it), resources are the natural place to enforce scoped, relevant retrieval rather than dumping whole knowledge bases into context. That is the same discipline behind sending the model only the relevant slice of context.
Prompts are reusable, parameterized instruction templates. They are user-controlled, typically surfaced as slash commands or buttons that a person invokes deliberately.

The protocol is bidirectional. A server can also ask things of the host through client-exposed primitives: sampling lets a server request a model completion from the host's model, so server authors get model access without bundling their own model SDK or API key; elicitation lets a server request additional input or confirmation from the user mid-operation; and logging lets a server send diagnostic messages to the client. There is also an experimental primitive, Tasks, for durable execution of long-running requests.

Discovery is dynamic. Each primitive has a list operation for discovery and a read, get, or call operation for use, and clients discover what is available at runtime. When a server's tool set changes it emits a notification such as notifications/tools/list_changed, and the client re-lists, so the model's available capabilities stay current without polling. For an enterprise, dynamic discovery is convenient and also a governance consideration, because the set of tools a model can reach is not fixed at deploy time.

Who supports MCP, and is it a real standard or a single-vendor bet?

MCP is a genuine cross-vendor standard, not a single-vendor bet. The strongest evidence is that a direct competitor standardized on a rival's protocol: OpenAI officially adopted MCP in March 2025, with support landing first in its Agents SDK and then documented across its Responses API, Connectors, and Apps SDK. That is unusual, and it is the single most significant adoption fact.

The rest of the map is broad. According to the Wikipedia record of the protocol and reporting from TechCrunch, Google DeepMind's chief executive Demis Hassabis announced in April 2025 that Gemini models and SDK would support MCP, calling it "rapidly becoming an open standard for the AI agentic era." Microsoft brought MCP to general availability in Copilot Studio in May 2025; note that this is Copilot Studio, the agent-building platform, not the consumer Copilot, and that Microsoft has also co-authored MCP security work. Anthropic's own Claude products, including Claude Desktop, Claude Code, and the Claude API's MCP connector, remain reference implementations. On the developer-tool side, VS Code (through GitHub Copilot Chat), Cursor, and JetBrains IntelliJ IDEA all support MCP, alongside a longer list of editors and agent tools. Salesforce and Cloudflare feature as well, with Cloudflare positioned as a host for deploying remote servers.

Two caveats belong in any executive summary of adoption. First, client capability is uneven: not all clients implement all primitives, so a client that "supports MCP" for tools may not support resources, prompts, sampling, or the newer interactive UI features. Verify the specific capabilities you need rather than trusting a logo. Second, the significance of an open standard here is strategic. An open, provider-agnostic protocol reduces the embedded-dependency risk that comes with betting your integration surface on one vendor's proprietary interface, which connects directly to the argument about architectural independence and avoiding vendor lock-in.

How does MCP compare with bespoke integrations and function calling?

These three approaches operate at different layers and are complementary rather than mutually exclusive. The most common misconception is that MCP replaces function calling; it does not. Function calling is a model capability for invoking a tool inside one application, while MCP is a protocol for distributing reusable tools and context across many applications. Many production systems use MCP to deliver tools and the model's native function calling to invoke them.

Dimension	Bespoke point integrations	Function / tool calling	Model Context Protocol
What it is	Hand-written code calling a specific API	A model capability: the LLM emits structured JSON requesting a tool your code runs	An open client-server protocol for exposing tools, resources, and prompts
Scope	One application, one integration	Inside one application	Across any MCP-compatible application
Portability	None; rebuilt per application	Provider-specific	Provider-agnostic; build a server once
Discovery	Static, coded in	Static tool list defined in the app	Dynamic, discovered at runtime
Scaling behavior	N times M connectors	Per-application tool wiring	N plus M: server reused by every client
Maintenance at scale	Highest; every API or auth change is manual code	Moderate; tied to one app	Lowest per integration, but you now operate the server as infrastructure
Best for	One-off or highly specialized connections	App-specific business logic, validation gates, routing	Reusable integrations shared across agents and tools

The practical reading for a leader: use function calling for the in-application logic that belongs to one product, keep a bespoke integration when a connection is genuinely one-off and specialized, and reach for MCP when the same capability needs to be reused across multiple AI applications or teams. This comparison synthesizes framing from Descope's analysis of MCP versus function calling and practitioner guidance on choosing between MCP, direct APIs, and function calling, both cited below.

What are the security and governance implications for the enterprise?

MCP introduces new trust boundaries that traditional perimeter security was not designed for, and the model-controlled nature of tools means an AI can take real-world actions. The official specification treats this seriously, and independent researchers have documented concrete attack patterns. This is the section to read closely before any production rollout.

The MCP Security Best Practices specification (dated 2025-06-18) sets several requirements at the strongest level. Among them: token passthrough is explicitly forbidden, with the rule that "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server," because passthrough breaks audit trails, rate limiting, and trust boundaries and enables data exfiltration with stolen tokens. Sessions must not be used for authentication, and session identifiers must be non-deterministic and bound to user identity. The spec also addresses the confused-deputy problem in proxy servers, server-side request forgery through OAuth discovery URLs pointed at cloud metadata endpoints, remote code execution risk from one-click local server installs, and OAuth URL injection, and it calls for scope minimization to limit blast radius. For remote servers specifically, the guidance requires validating the Origin header to block DNS-rebinding attacks, recommends binding only to localhost when running locally, and recommends authenticating all connections.

Because tools can take actions, MCP builds in human oversight by design: tools "may require user consent prior to execution," and hosts are expected to implement per-call approval, pre-approval settings for safe operations, per-interaction tool enablement, and activity logs of every execution.

Independent and enterprise sources add a governance layer on top of the protocol requirements. The recurring enterprise risk list, drawn from Checkmarx's review of MCP security incidents and controls, includes over-privileged agent access, indirect prompt injection through external content, tool poisoning and "rug pull" attacks (malicious instructions hidden in tool metadata that the user does not see but the model reads), credential sprawl across ungoverned servers, and audit blind spots. Microsoft has published specific guidance on protecting against indirect prompt injection in MCP. Empirical client testing has found client-side enforcement uneven, with some clients implementing strong guardrails and others more susceptible to cross-tool poisoning, which reinforces the point that client capability must be verified rather than assumed. The recommended pattern across these sources is a governed central registry: tools registered once, with access policies applied consistently, rather than ad-hoc point-to-point connections that no one is tracking.

What should a leader do now?

The right posture is deliberate adoption rather than either a moratorium or a rush. MCP is a real standard with cross-vendor support, but it moves the integration problem into infrastructure you own and must secure. A sequenced approach:

Inventory the N-by-M problem you actually have. Count the AI applications in use or planned and the internal systems they need to reach. If that number is small and static, bespoke integrations may still be cheaper. If it is growing, MCP's build-once economics start to pay off.
Start with read-only resources before action-taking tools. Exposing scoped, read-only context through resource primitives captures much of the value with far less risk than granting model-controlled tools that can write to systems.
Stand up a governed registry, not point-to-point sprawl. Register servers centrally, apply least-privilege scopes, and require human-in-the-loop approval for any tool with side effects. Treat every remote server as production infrastructure with authentication, logging, and monitoring.
Verify client capabilities and enforcement, per client. Confirm which primitives each host supports and how it handles consent and tool approval, because enforcement varies.
Adopt the official security requirements as non-negotiable. Forbid token passthrough, prohibit session-based authentication, minimize scopes, and validate origins. Treat the 2025-06-18 best-practices document as a baseline, and Microsoft's indirect-injection guidance as required reading for anyone connecting servers to external content.
Keep function calling and MCP in their lanes. Use function calling for in-application logic and MCP to distribute reusable integrations. Do not rip out working function-calling code to "move to MCP"; the two coexist.

MCP is best understood as one layer in a larger agent stack. It standardizes how models reach systems; your orchestration, evaluation, and cost controls still sit above it, and the same design discipline that governs an agent platform applies here.

What are the risks and open questions?

Several honest uncertainties remain, and a leader should hold them in view rather than assume the standard is fully settled.

The protocol is young and still evolving. The current revision referenced throughout the specification is dated 2025-06-18, the Streamable HTTP transport already replaced an earlier HTTP-plus-SSE transport, and some primitives such as Tasks are experimental. Expect further revisions, and design for version negotiation.
Uneven client support undercuts portability in practice. "Build once, integrate everywhere" holds only for the capabilities a given client actually implements. The promise is directional, not yet uniform.
Security depends on correct operation, not the protocol alone. The specification forbids the dangerous patterns, but the documented incidents show that misconfigured servers and weak clients are where real exposure occurs. The protocol raises the ceiling; it does not guarantee your floor.
Governance tooling is still maturing. Platforms surface some observability, for example Copilot Studio's runtime view of which server and tool was invoked, but centralized policy, discovery, and audit across many servers largely remain something enterprises must assemble themselves today.
Adoption scale is impressive but self-reported. Figures such as roughly 97 million monthly SDK downloads and around 10,000 active servers in the first year signal momentum, but attribute them as ecosystem claims rather than independently audited metrics.

None of these are reasons to avoid MCP. They are reasons to adopt it the way you would adopt any new piece of infrastructure that sits close to your data: with scoped pilots, explicit security requirements, and governance planned from the first server rather than retrofitted after the tenth.