Model Context Protocol: the Integration Layer for Enterprise AI

The N×M integration problem

Before MCP, every AI application that needed enterprise context solved the same problem from scratch. A chat assistant that reads tickets, an IDE agent that queries the data warehouse, a support copilot that touches the CRM: each pairing meant a bespoke connector with its own auth handling, its own data shapes, its own failure modes. With N applications and M systems, you were on a path toward N×M integrations, each one owned by whichever team shipped it first and maintained by nobody in particular.

The Model Context Protocol attacks the multiplication itself. It standardizes the interface between AI applications and external systems, so each application implements the protocol once and each system exposes one server. N×M collapses to N+M. This is the same move ODBC made for databases and the Language Server Protocol made for editor tooling: agree on the wire contract, and clients and servers can be built independently and composed freely. Neither ODBC nor LSP was the most elegant possible design; both won because they were good enough, open, and adopted early by the tools that mattered. MCP is following the same trajectory.

Anthropic announced MCP as an open protocol in November 2024. Since then it has been adopted broadly across major AI vendors and developer tools, and as of mid-2026 it is the closest thing the industry has to a default integration layer for agentic applications. For an enterprise architect the appeal is plainly economic: a connector built once for a chat surface can be reused by IDE assistants and by agent workloads without rework, and the security review you invest in that connector amortizes across every surface that uses it.

The rest of this article covers what the specification actually says, where the trust boundaries sit, and how to adopt MCP with the discipline you would apply to any new class of production API.

Protocol anatomy: hosts, clients, servers

MCP defines three roles. The host is the AI application the user actually touches: a chat product, an IDE, an agent runtime. The host embeds one or more MCP clients, and the spec is strict about cardinality: each client maintains a stateful, one-to-one connection with exactly one MCP server. A host talking to five servers runs five clients. The server is the adapter in front of a capability: a filesystem, a ticketing system, a warehouse, an internal API.

All traffic between client and server is JSON-RPC 2.0: requests that expect responses, notifications that do not, and results or errors. There is no bespoke framing to learn; if your teams have ever debugged LSP traffic, MCP messages will look immediately familiar.

+---------------------- Host application ----------------------+
|  chat app, IDE, or agent runtime                             |
|                                                              |
|  +--------------+   +--------------+   +--------------+      |
|  | MCP client A |   | MCP client B |   | MCP client C |      |
|  +------+-------+   +------+-------+   +------+-------+      |
+---------|-----------------|-----------------|----------------+
          | JSON-RPC 2.0    |                 |
          v                 v                 v
   +--------------+   +--------------+   +--------------+
   | MCP server:  |   | MCP server:  |   | MCP server:  |
   | filesystem   |   | ticketing    |   | warehouse    |
   | stdio, local |   | HTTP, remote |   | HTTP, remote |
   +--------------+   +--------------+   +--------------+

Every connection begins with an initialize handshake in which both sides negotiate a protocol version and declare capabilities. The server states whether it offers tools, resources or prompts, and options such as list-change notifications; the client declares what it supports in return, such as handling requests that flow back from the server. Nothing is assumed: a client must not invoke a capability the server never declared. For an architect, this negotiation step is the useful hook. It makes a server's entire surface area enumerable at connect time, and anything enumerable can be logged, diffed and reviewed.

The three primitives: tools, resources, prompts

Everything an MCP server exposes falls into three primitives, and the specification is deliberate about who controls each one.

Tools are model-controlled: executable actions the model chooses to invoke mid-conversation, each described by a name, a natural-language description and a JSON Schema contract for its inputs. The invocation mechanics are the same tool-calling loop used elsewhere in the stack (see tool calling mechanics); what MCP adds is a standard way to discover and call tools across any server. Resources are application-controlled: URI-addressed context, such as a file, a record or a document, that the host application decides to place into the model's context. Prompts are user-controlled: named templates a person explicitly selects, typically surfaced as slash commands or menu entries.

The control axis is the security design point, not an implementation detail. A model-controlled primitive can be triggered by anything that influences the model, including text retrieved from outside your trust boundary, so tools need schema validation, least-privilege credentials and, for anything that writes, approval gates. Resources are safer by construction because the application chooses them, yet they still carry data into context and can smuggle in injected instructions. Prompts are the calmest of the three because a human is in the loop by definition. Build your review process around this asymmetry rather than treating "an MCP server" as one undifferentiated risk category.

Transports, sessions and lifecycle

The specification defines two transports. stdio runs the server as a local subprocess of the host, exchanging JSON-RPC over standard input and output. It is the natural fit for developer-machine capabilities: filesystem access, local git, build tooling. Streamable HTTP is the remote transport: the client sends JSON-RPC over HTTP and the server can stream responses and server-initiated messages back, typically via server-sent events. Remote transport is what makes shared, centrally operated servers possible, and it is the transport that matters for enterprise deployments.

A session moves through a defined lifecycle:

• Initialization. The client sends an initialize request carrying its protocol version and capabilities; the server responds with its own; the client confirms with an initialized notification. Version and capability mismatches surface here, not mid-task.
• Operation. Normal request and response traffic, plus notifications in both directions, such as a server announcing that its tool list has changed.
• Shutdown. Termination is handled at the transport layer: closing the streams or ending the subprocess for stdio, terminating the session for HTTP. Well-behaved hosts shut down cleanly rather than orphaning server processes.

The two transports carry sharply different trust assumptions, and conflating them is a common early mistake. A stdio server is code running with the user's local privileges; installing one is a software supply-chain decision, so it belongs under the same allowlisting and provenance controls as any other locally installed executable. A remote HTTP server is a network service: it must authenticate callers, authorize per-user, rate-limit, and log, and it can be placed behind your existing network controls. As a rule, prefer remote servers for anything shared or sensitive, and treat local stdio servers as developer tooling with an explicit approval path.

Authorization and the MCP threat model

For remote HTTP servers, the specification defines an OAuth 2.1-based authorization model: the MCP server acts as a resource server, access tokens are issued by an authorization server the deployer controls, and clients discover the authorization endpoints through protocol metadata. The details have been refined across spec revisions, so pin your implementation to a specific protocol version and track changes deliberately. Just as important is what the spec leaves out: it governs how clients authorize to the MCP server, and says nothing about how the server authenticates to the systems behind it. Downstream credential scoping stays entirely with the deployer, and that is where most real risk concentrates. An over-scoped service account sitting behind a beautifully secured MCP endpoint is still an over-scoped service account.

The threat model has four recurring shapes. Tool poisoning: a malicious or compromised server ships tool descriptions crafted to steer model behavior. Prompt injection via tool results: data returned by a legitimate tool contains instructions the model then follows. Confused deputy: a server or gateway exercises its own broad authority on behalf of an attacker-influenced request. Over-broad scopes: connectors granted admin-level access because narrow scopes were inconvenient to provision.

The mitigations are unglamorous and effective: least-privilege credentials per server, per-user credential pass-through instead of shared service accounts where feasible, human approval on consequential actions, egress restrictions on server workloads, and a log line for every tool call with its arguments and results. The broader containment patterns are covered in guardrails and sandboxing.

Enterprise patterns: gateways, registries, governance

The pattern that separates production deployments from pilots is a central MCP gateway: a service that terminates client connections, enforces authentication and authorization against your identity provider, applies rate limits, and emits audit logs, before proxying traffic to backend servers. It plays the same role for connectors that a model gateway plays for inference: one choke point where policy is enforced consistently, so individual server teams do not each reimplement auth and logging, and security gets a single place to look.

The second pattern is an internal server registry: a catalog of approved servers with an owner, declared scopes, data classification, and review status for each entry. New servers enter through a review process that checks credential scoping, tool descriptions and injection handling before listing. The registry turns "can I use this connector?" from a Slack thread into a lookup, and it is the mechanism that stops teams from installing arbitrary community servers against production data.

The payoff arrives as connector reuse. The same ticketing server should serve your chat assistant, your IDE integration and your autonomous agents; if it does not, you have standardized the protocol without capturing the economics. Reuse across surfaces is the metric that justifies the gateway and registry investment.

None of this is exotic. It is API management, applied to a new class of API whose consumer happens to be a language model.

A 90-day adoption playbook

Treat MCP as a platform capability with a deliberate rollout, not a hackathon artifact that escapes into production. A 90-day arc is realistic for a first wave.

1. Days 0 to 30: prove the plumbing, read-only. Stand up one server against a low-risk system: an internal knowledge base or ticket search is ideal. Expose only read tools and resources, wire it into a single host surface, and measure answer quality, latency and failure modes. Resist the urge to add write actions; the goal is operational confidence, not capability.
2. Days 30 to 60: writes behind approvals, gateway online. Add the first write-capable tools, every one gated by human approval in the host. Stand up the gateway with identity-based access and full call logging, define the downstream credential scoping model, and move the pilot server behind it.
3. Days 60 to 90: institutionalize. Launch the registry with an ownership model and a security review checklist covering scopes, data classification, tool description review and injection testing. Publish a paved-road server template and developer enablement docs, then onboard a second and third server to prove the review process scales.

Measure connector reuse above all else: the number of distinct surfaces consuming each server. If every new AI project still builds bespoke integrations after the quarter, you have deployed a protocol without changing your economics. Secondary metrics worth tracking are approval rejection rates on write actions (a proxy for how well-scoped your tools are), tool error rates, and elapsed time to onboard a new server through review.

MCP is small enough to read in an afternoon and consequential enough to reorganize how integration work is owned. The durable win is not the protocol itself; it is that standardization lets you centralize authorization, audit and review in one place. To see the moving parts live, the Agent Studio in the Lab runs agents against real tool servers.