A Model Context Protocol enterprise deployment standardizes three things between your AI hosts and your systems: how a host discovers what a server offers, how messages travel, and how a client gets the right to call a protected resource. Policy stays with you. The current specification (2026-07-28) says on its Tools page: "For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations." In the MCPTox benchmark (2025), built on "45 live, real-world MCP servers and 353 authentic tools," tool poisoning succeeded against o1-mini in 72.8% of cases, while the highest refusal rate was less than 3%. The protocol gives you an interface and a warning. The gateway, identities and tool review are yours.
What Model Context Protocol Enterprise Deployments Standardize
A Model Context Protocol enterprise deployment is a set of MCP servers, each exposing one system's tools, resources and prompts over a standard JSON-RPC interface, that any approved AI host in the company can discover and call through its own MCP client, with authorization, logging and ownership handled outside the protocol by the enterprise.
The architecture page names three participants. The host "acts as the container and coordinator" and "Enforces security policies and consent requirements." Each client "Communicates with exactly one server." By design, enforced by the host, "Servers should not be able to read the whole conversation, nor 'see into' other servers." The current revision (2026-07-28) states that "MCP is a stateless protocol"; earlier revisions, still widely deployed, used sessions.
Anthropic introduced the Model Context Protocol on November 25, 2024, noting that "Every new data source requires its own custom implementation." On December 9, 2025, the project joined the Agentic AI Foundation under the Linux Foundation, "co-founded by Anthropic, Block and OpenAI." A revision date marks "the last date backwards incompatible changes were made," per the versioning page.
This text is about the wire between an agent and your systems: what the protocol standardizes, what it leaves to you, and how to deploy it so a security review passes. Whether a given step deserves an agent at all is a separate question, which we cover in where an agent earns a step in the first place. If you want the tool layer designed and built rather than explained, that is the tool layer we build around production agents.
Three Primitives, Two Transports, One Control Model
Each primitive has a different decision maker. Tools "are designed to be model-controlled." Resources "are designed to be application-driven, with host applications determining how to incorporate context." Prompts "are designed to be user-controlled," which "refers to who decides when the prompt is used, not who authors its content." A database server, in the architecture overview, exposes query tools, a schema resource and a few-shot prompt. Three decision makers need three access policies.
The transports page defines stdio as "newline-delimited messages over the standard streams of a client-launched subprocess" and Streamable HTTP as "an HTTP POST to a single MCP endpoint." The Streamable HTTP section is normative: "Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks," and local servers "SHOULD bind only to localhost (127.0.0.1)." Enterprises run Streamable HTTP in production; stdio stays on developer workstations.
Clients offer elicitation, so a server can ask the user for input. The 2026-07-28 changelog deprecates Roots, Sampling and Logging and adds server/discover. Agent-to-agent communication is a separate protocol; this text stays on agent-to-system.
MCP vs Function Calling vs RAG: Different Layers, Not Rivals
In a Model Context Protocol enterprise setup the model never talks to the protocol. It talks to its own tool-calling interface, and the host translates. OpenAI's function calling guide: "When the model calls a function, you must execute it and return the result." Anthropic's tool use documentation says the model "returns a structured call that your application runs." Each provider defines that model-to-application contract.
MCP sits behind that contract. The host "fetches available tools from all connected MCP servers and combines them into a unified tool registry that the language model can access," per the overview, then hands the model that list in its native tool format. RAG is a retrieval pattern, not a protocol, and a retrieval service can be exposed as an MCP tool or resource. Retrieval design is covered in retrieval over documents at production scale.
| Question | Native function calling | MCP | RAG |
|---|---|---|---|
| Who defines the contract | The model provider, per API | An open specification (AAIF, Linux Foundation) | Your application; no protocol |
| Who talks to whom | Model to your application | Host application to one or many servers | Application to an index or search layer |
| How capabilities are discovered | Hard-coded in the request | Listed at runtime (tools, resources, prompts) | Not applicable; retrieval is a step you code |
| Who decides when it runs | The model | Tools: the model; resources: the application; prompts: the user | The application, usually every turn |
| Where authorization lives | Your code | OAuth 2.1 at the transport, policies at the gateway | Your code and the index permissions |
| What it does not solve | Reuse across hosts and systems | Whether the tool description is honest | Taking actions in systems |
Three layers, usually stacked: retrieval exposed as an MCP tool, called through the model's native tool calling.
Deploying MCP in the Enterprise: Identity, Gateway, Registry
The authorization specification opens with "Authorization is OPTIONAL for MCP implementations." Stdio implementations "retrieve credentials from the environment." When authorization is used over HTTP, "A protected MCP server acts as an OAuth 2.1 resource server" and the client acts as the OAuth client. Servers MUST implement Protected Resource Metadata (RFC 9728), clients MUST implement Resource Indicators (RFC 8707), and servers MUST check that each access token names them as audience: "MCP servers MUST NOT accept or transit any other tokens." Clients SHOULD request minimal scopes and step up through a WWW-Authenticate challenge. The security best practices name token passthrough an anti-pattern and list "wildcard or omnibus scopes" as a common mistake. Your identity provider is the authorization server.
A Model Context Protocol enterprise gateway is where policy becomes enforceable regardless of who wrote the server. As of Microsoft's current documentation, Azure API Management can expose a managed REST API as an MCP server and apply rate limits, JWT validation and IP filtering. It "doesn't support MCP resources or prompts." AWS documents AgentCore Gateway as managing "both inbound authentication (verifying agent identity) and outbound authentication (connecting to tools) in a single service."
The official MCP Registry, in preview as of this writing, lists publicly accessible servers with DNS-verified namespaces. It "does not support private servers" and recommends you "host your own private MCP registry." A private registry records each server's owner, version and scope. Without one, the third team builds a third server for the same ERP.
The Security Risks That Come With the Tool Layer
Every Model Context Protocol enterprise server adds a place where text written by someone else reaches the model as an instruction. Invariant Labs, the team that first described tool poisoning in April 2025, described an attack in which "malicious instructions are embedded within MCP tool descriptions that are invisible to users but visible to AI models." In a rug pull, "a malicious server can change the tool description after the client has already approved it." In shadowing, one server's description changes how the agent treats a trusted tool elsewhere.
MCPTox ran 1,348 malicious test cases against 20 LLM agents, and its authors report that stronger models were more susceptible, since the attack exploits instruction following. In a study of 1,899 open-source MCP servers (Hasan et al., 2025), "7.2% of servers contain general vulnerabilities, and 5.5% exhibit MCP-specific tool poisoning."
Tool results are a second channel. OWASP LLM01:2025: "Indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files." OpenAI's MCP guide warns that "A malicious server can exfiltrate sensitive data from anything that enters the model's context." Then permissions: OWASP LLM06:2025 says to "Limit the permissions that LLM extensions are granted to other systems to the minimum necessary."
The Tools specification says "clients MUST consider tool annotations to be untrusted unless they come from trusted servers," and should "Show tool inputs to the user before calling the server" and "Log tool usage for audit purposes." OpenAI asks for approval by default and offers require_approval and allowed_tools. Anthropic's MCP connector can "allowlist specific tools, or denylist unwanted tools." Invariant Labs: "Clients should pin the version of the MCP server and its tools." Our rule: a tool description is code, so it gets review and a version.
When MCP Is the Right Layer, and When It Is Not
Our rules, not a standard. Use MCP when several hosts must reach several systems and the agent picks the tool at runtime. Use native function calling when one application has a few fixed actions and one model provider. Use retrieval when the question is about documents and nothing should change. Use a plain API when no model sits in the decision loop. One MCP server covers one system domain with a named owner.
Two limits shape the design. Anthropic's note on code execution with MCP observes that "Most MCP clients load all tool definitions upfront directly into context," an argument for a registry and allowed_tools. Tool names are unique only per server, so aggregators "SHOULD implement a disambiguation strategy such as prefixing tool names with a server identifier." Local stdio servers, the best practices warn, "run with the same privileges as the client," so they stay off production.
A Rollout Order We Use, and Where to Start
- Read-only servers first.
- An identity per agent, with minimal scopes and step-up on demand.
- A gateway before the first tool that writes.
- A private registry before a third team ships its own server.
- Write tools behind human approval.
- Tool descriptions in the repository, reviewed and pinned.
None of this is exotic. A Model Context Protocol enterprise rollout fails the same way an API program fails: unowned endpoints, shared keys and nobody reading the contract.
At DS Stream we build MCP servers for a client's systems in the client's own cloud, behind their identity provider and gateway, with a private registry and review of tool descriptions. Once the wiring is boring, the agent is the easy part. Bring us the first system you want an agent to read from.
FAQ
What does a Model Context Protocol enterprise deployment consist of?
One MCP server per system, MCP clients inside approved hosts (one client per server), Streamable HTTP behind a gateway, OAuth 2.1 from your identity provider, and a private registry naming each server's owner. The protocol provides interface and discovery; policy is yours.
Is MCP a replacement for function calling?
No. Function calling is the contract between a model and your application, defined by the model provider. MCP is the contract between the host and your systems, translated by the host into native tool calls. One application with a few fixed actions does not need MCP.
How do you protect MCP servers against tool poisoning?
Version, review and pin tool descriptions, as Invariant Labs recommends. Show tool inputs before a call, treat annotations as untrusted, limit tools with allowed_tools, and require approval for writes. In MCPTox (2025), attacks succeeded against o1-mini in 72.8% of cases, so do not rely on the model refusing.
Does MCP require OAuth?
No. Authorization is optional. Over HTTP, implementations SHOULD follow the OAuth 2.1 profile, with RFC 9728 metadata, RFC 8707 resource indicators and no passthrough of foreign tokens. Stdio servers use credentials from the environment.
