Our Blogs

Quick answer: The Model Context Protocol (MCP) is an open standard that lets AI applications connect to your systems through one consistent interface instead of a bespoke integration per model and per tool. An MCP server wraps a system you already run — an ERP, a data warehouse, a ticketing platform — and exposes it as tools, resources and prompts that any MCP-capable AI host can discover and call. For enterprises, the value is not novelty: it is replacing an N×M integration problem with an N+M one, and doing it behind an authorization model you control.

Most enterprise AI programmes do not stall on model quality. They stall at the point where the agent needs to read a real record from a real system and write something back. That work is integration work, it is unglamorous, and until recently every team rebuilt it from scratch for every model vendor they tried.

This guide is for CTOs, enterprise architects and heads of platform in the US and UK. It covers what MCP actually is at the wire level, what changed in the 2026 specification, where it earns its place against a plain REST API, four patterns for wrapping legacy systems, the security rules you cannot skip, and a realistic rollout sequence.

What is the Model Context Protocol?

MCP is an open-source standard for connecting AI applications to external systems — data sources, tools and workflows. It defines a JSON-RPC 2.0 based protocol so that any compliant AI host can discover what a system offers and invoke it, without the host knowing anything about that system in advance.

The usual analogy is a universal port: build the connector once, and every compliant device can use it. The commercial translation is blunter. If you have five AI surfaces (a coding assistant, an internal chat assistant, a customer-facing agent, a BI copilot, a vendor’s product) and twelve systems worth connecting, the bespoke approach is sixty integrations. The MCP approach is seventeen, and the twelve server-side ones are reusable the next time a new AI surface appears.

The three participants

• MCP host — the AI application itself, which coordinates one or more clients.
• MCP client — a connection manager inside the host; one client per server, each holding a dedicated connection.
• MCP server — the program that exposes your system. It can run locally next to the host, or remotely on your own infrastructure. “Server” describes the role, not the location.

In an enterprise deployment the servers are almost always remote and run by you, inside your network, behind your identity provider. That is the whole point: the AI vendor changes, the servers do not.

Two layers, and why the distinction matters

MCP separates a data layer — the JSON-RPC protocol, capability discovery and the core primitives — from a transport layer that handles connection, framing and authorization. Two transports are defined: stdio for local process communication, and Streamable HTTP for remote servers, using HTTP POST with optional Server-Sent Events and standard HTTP authentication, with OAuth recommended for obtaining tokens.

Architecturally this is the good news for enterprises: the authorization story sits in the transport layer where your existing identity infrastructure already lives. You are not being asked to invent a new trust model.

The primitives

Servers expose three things:

• Tools — executable functions the AI can invoke: run a query, create a ticket, post a journal entry. Discovered with tools/list, executed with tools/call, each described by a JSON Schema for its inputs.
• Resources — contextual data the AI can read: a database schema, a document, an API response.
• Prompts — reusable interaction templates, including few-shot examples for using your tools correctly.

Clients can expose elicitation, which lets a server ask the user for more information or confirm an action mid-flow. That one matters more than it sounds: it is the protocol-level hook for human approval on a risky operation.

What changed in the 2026 specification

If your team evaluated MCP in 2025 and shelved it, the protocol has moved. Protocol version 2026-07-28 brings changes that specifically affect how you would operate it at scale.

• MCP is now a stateless protocol. Every request carries the protocol version, client capabilities and client identity in its _meta field, so a server can process each request on its own. For anyone who has tried to run sticky sessions across a load balancer, this is the single most consequential change — MCP servers now scale horizontally like any other stateless HTTP service.
• Discovery is explicit. Servers must implement a server/discover request returning supported versions and capabilities. Responses are cacheable, carrying ttlMs and cacheScope hints, so a tool catalogue need not be re-fetched on every call.
• Notifications are opt-in subscriptions. Clients open a long-lived subscriptions/listen stream naming the event types they want; servers acknowledge the subset they will honour. Delivery is explicitly best-effort across reconnects, so clients should still poll for freshness.
• Sampling and logging are deprecated. New implementations integrate directly with LLM provider APIs rather than asking the client for completions, and log to stderr or OpenTelemetry. If a vendor’s MCP server still depends on sampling, that is a maintenance signal worth asking about.
• A Tasks extension exists for long-running work. Servers can return a durable handle so clients poll for status and retrieve the result later — the right shape for a batch job, a report build or anything in an ERP that takes minutes rather than milliseconds.

Statelessness plus cacheable discovery plus durable task handles is, in aggregate, the protocol growing up into something you can put behind a load balancer and an API gateway without apologising for it.

MCP, REST APIs, and plain function calling: when does MCP earn its place?

MCP does not replace your APIs. It is a layer in front of them designed for a consumer that reasons rather than follows a fixed script. Be honest about when that matters.

• A plain REST API is enough when one application calls one system in a deterministic sequence you wrote. Adding MCP buys nothing.
• Vendor-specific function calling is enough when you have committed to one model vendor for one use case and expect that to hold. The cost appears later, when it does not hold.
• MCP earns its place when several AI surfaces need the same systems, when the set of available tools changes at runtime, when you need one consistent audit and authorization story across every AI-initiated action, or when you want the freedom to swap model vendors without rewriting integrations. Most enterprises hit at least two of those within a year.

The deciding question is not technical elegance. It is whether you expect to connect more than one AI surface to more than one system — because that is the point where the N×M arithmetic starts working against you.

Four patterns for putting MCP in front of legacy systems

Nobody’s hardest integration target is a modern microservice. It is the twenty-year-old system of record that the business runs on. These four patterns cover most of what we see in practice, roughly in order of effort.

1. Wrap an existing API

The system already exposes REST or SOAP. The MCP server becomes a thin translation layer: each meaningful operation becomes a tool with a precise JSON Schema and a description written for a reasoning model rather than a developer. Days of work, not weeks. Resist the temptation to auto-generate one tool per endpoint — a hundred thinly-described tools performs far worse than fifteen well-described ones.

2. The read-only resource server

Expose schemas, reference data, documentation and reports as resources with no write tools at all. This is the right first production deployment for a regulated enterprise: genuinely useful, and the blast radius is bounded by construction. It also surfaces your data-quality problems early, while they are still cheap to fix.

3. The database or warehouse server

Expose the schema as a resource, parameterised queries as tools, and a prompt containing worked examples of correct usage. Never expose raw SQL execution to an agent in production. Use views, row-level security and a service account scoped to exactly what the use case needs, and pair it with your existing analytics layer rather than building a parallel one.

4. The modernization-surface adapter

For mainframes, green-screen systems and ERPs with no usable programmatic interface, the MCP server sits on top of whatever integration surface exists — a message queue, a batch file drop, a database replica, an integration bus. This is the expensive one, and the honest framing is that it is an application modernization project that happens to have an AI consumer. The upside is that the integration surface you build is reusable by everything else, not just the agent. ERP estates frequently land here.

Across all four, the single highest-leverage design decision is tool granularity. A tool should map to a business operation a person would recognise — “create purchase requisition”, not “POST /v2/documents”. Models select tools from their descriptions, so the description is production code, not documentation.

The security rules you cannot skip

MCP’s own specification is unusually direct about attack vectors. These are drawn from it, translated into what a security review will actually ask you.

1. Never pass tokens through

An MCP server must not accept tokens that were not explicitly issued for it. Accepting a token minted for another service and forwarding it downstream is called token passthrough, and it is explicitly forbidden. It breaks audience validation, destroys your audit trail (the downstream system logs the wrong identity), and turns your server into a proxy for data exfiltration if a token is ever stolen. Validate the audience claim on every request.

2. Implement per-client consent, or inherit the confused deputy problem

If your MCP server proxies a third-party API using a static client ID while letting clients register dynamically, an attacker can exploit a leftover consent cookie to have an authorization code redirected to their own server — no consent screen shown. The mitigation is a registry of approved client IDs per user, checked before forwarding to the third party, with exact-match redirect URI validation, single-use state values stored only after consent is approved, and consent cookies using the __Host- prefix with Secure, HttpOnly and SameSite=Lax.

3. Treat state handles as identifiers, never as authentication

Because the protocol is stateless, servers that need multi-request state mint a handle — a workflow ID, a cart ID — returned to the client and passed back as a tool argument. Possession of that handle must never be treated as proof of identity. Bind handles server-side to the authenticated user (key them as user_id:handle, where the user ID comes from the verified token and not from the client), generate them with a secure random source, and expire them.

4. Defend against SSRF during discovery

MCP clients fetch URLs supplied by servers during OAuth metadata discovery. A hostile server can point those at internal addresses — cloud metadata endpoints at 169.254.169.254, internal admin panels, localhost services. Require HTTPS outside loopback, block private and link-local IP ranges, validate redirect targets at every hop, and route server-side client deployments through an egress proxy. Do not hand-roll IP validation; encoding tricks defeat custom parsers.

5. Minimise scopes deliberately

Publishing every possible scope in scopes_supported and granting them all up front produces exactly the token you least want stolen. Start with a minimal, low-risk read and discovery scope, and elevate incrementally through targeted WWW-Authenticate challenges when a privileged operation is first attempted. Avoid wildcard or omnibus scopes entirely, and log elevation events with correlation IDs.

6. Govern local servers as installed software

A local MCP server is a binary executing on an employee’s machine with that user’s privileges, often installed through a one-click flow. Treat it as software distribution: an internal registry of approved servers, consent dialogs showing the exact command before execution, sandboxing, and restricted filesystem and network access. One-click installation of arbitrary community servers on developer laptops is the most likely way MCP enters your estate ungoverned.

7. Treat tool descriptions and tool output as untrusted input

A tool description is text that steers a model’s behaviour, and tool results are text a model reads and acts on. Anything a third-party server can write into either is an injection surface. Pin and review the servers you connect, re-review when a tool list changes, and keep destructive operations behind explicit human approval using elicitation rather than trusting the model to ask.

Governance: the part that decides whether this scales

The protocol has grown enterprise-specific extensions — notably an Enterprise-Managed Authorization extension for centralised access control through an identity provider, and an OAuth client credentials extension for machine-to-machine flows. Both exist because the first question every enterprise asks is “who approved this agent doing that?”

What to stand up alongside your first servers:

• An internal registry of approved MCP servers, with an owner and a review date for each.
• Authorization routed through your existing IdP, not per-server credentials.
• Full audit logging of every tool call: which agent, acting for which user, with which scopes, against which system, with what result.
• A tool-change review gate, since a server can legitimately change its own tool list at runtime.
• A deprecation path. Protocol versions move; servers pinned to an old version become a liability.

This is ordinary platform governance applied to a new client type, and it is why MCP work usually belongs with your platform team rather than inside a single product squad. If that team does not exist yet, augmenting it is faster than forming it.

A 90-day rollout that survives a security review

Days 1–20: pick the boring use case

Choose one system and one high-frequency, low-risk question people ask of it — “what is the status of order X”, “which contract covers this customer”. Build a read-only resource server. No writes. Get it through security review now, while the surface is small, because that review is the real long pole and it only gets harder once writes are involved.

Days 21–50: add bounded tools and real authorization

Add three to five tools that perform actual operations, wired to your IdP with per-user scopes, audience validation and full audit logging. Keep every write behind elicitation-based confirmation. Measure tool selection accuracy — how often the model picks the right tool for a real request — and rewrite the descriptions that lose. This is where most of the quality work actually lives.

Days 51–90: second system, second surface

Connect a second system, and connect the first server to a second AI host. That second connection is the whole thesis of MCP, and it is the moment the investment either proves itself or does not. Stand up the registry, the audit dashboard and the version policy in the same window — governance retrofitted later never quite catches up.

Anything promising a fleet of autonomous agents across the enterprise in a quarter is selling a demo. One governed server, two consumers, and a security sign-off is a genuinely good quarter.

Build, buy, or partner

• Buy the servers for systems whose vendors publish and maintain them. Review the auth model before connecting, and confirm they are on a current protocol version.
• Build the servers for your systems of record and your proprietary data. The tool design encodes your business operations, which is not something a generic connector models well — this is enterprise software engineering, not configuration.
• Partner when the constraint is the combination of skills. MCP work sits across protocol implementation, identity and OAuth, legacy integration, and MLOps. Few in-house teams hold all four, and agentic framework development is usually faster to buy in for the first two servers and then take in-house.

What to measure

• Tool selection accuracy — the share of requests where the model chose the correct tool
• Tool call success rate, and the error taxonomy behind the failures
• p95 latency per tool, since an agent may chain several calls per turn
• Human intervention rate on write operations
• Number of AI surfaces served per MCP server — the reuse ratio that justifies the whole approach
• Time to connect a new system, tracked release over release; it should fall sharply after the third server
• Scope elevation events, and how many were denied
• Audit completeness: the percentage of tool calls with a full actor, scope and result trail

The reuse ratio is the one to put in front of a CFO. A server used by one assistant is an integration. A server used by four is a platform.

Frequently asked questions

What is the Model Context Protocol in simple terms?

MCP is an open standard that lets AI applications connect to external systems through one consistent interface. You build an MCP server that exposes a system as tools, resources and prompts, and any MCP-compatible AI application can then discover and use it without custom integration work for that specific pairing.

Is MCP a replacement for REST APIs?

No. MCP typically sits in front of existing APIs rather than replacing them. The difference is the consumer: a REST API is designed for a developer who reads documentation at build time, while an MCP server is designed for a model that discovers capabilities at runtime and selects among them from their descriptions.

Is MCP secure enough for enterprise use?

The protocol specifies a workable security model — OAuth-based authorization, mandatory audience validation, and an explicit prohibition on token passthrough — but security depends on implementation. The non-negotiables are validating that tokens were issued for your server, binding state handles to authenticated users, per-client consent on any proxy server, SSRF protections during discovery, and minimal scopes elevated only on demand.

Can MCP connect to legacy systems like mainframes or old ERPs?

Yes, but through whatever integration surface already exists — a message queue, a database replica, an integration bus or a batch interface. MCP does not create access that isn’t there. For systems with no usable programmatic interface, building that surface is a modernization project in its own right, with the benefit that the result is reusable beyond the AI use case.

Do we need to run MCP servers ourselves?

For your own systems and data, yes — running them inside your network behind your identity provider is what keeps control on your side when AI vendors change. Vendor-published servers for third-party SaaS are reasonable to consume directly, provided you review their authorization model and protocol version first.

How long does it take to build an MCP server?

A thin wrapper over a well-documented existing API is days of work. A production server with IdP-backed authorization, scope management, audit logging and carefully designed tools is typically four to eight weeks for the first one, and substantially faster afterwards because the authorization and observability scaffolding is reused.

What changed in the 2026-07-28 MCP specification?

The protocol became stateless, with every request carrying its own version, capabilities and identity metadata, which lets servers scale horizontally. Discovery is now an explicit, cacheable server/discover request; change notifications became opt-in subscription streams; sampling and logging were deprecated in favour of direct LLM APIs and standard telemetry; and a Tasks extension was added for long-running operations.

Does MCP lock us into a particular AI vendor?

It does the opposite, which is the main reason enterprises adopt it. Because the protocol is open and supported across many AI applications, the servers you build remain usable when you change model providers. The integration investment sits on your side of the boundary rather than inside a vendor’s proprietary function-calling format.

Where to start

Pick the system your people ask the most questions about, and expose it read-only. You will learn more about your data quality, your authorization model and your tool-description discipline in six weeks of that than in six months of architecture review — and you will have cleared the security path before the stakes rise.

DRC Infotech builds and governs MCP servers for enterprises in the US, UK and Europe — from AI strategy and roadmap through AI agent development, enterprise AI development and custom LLM work. If you are mapping this onto an industry, see our guides to agentic AI in manufacturing and agentic commerce in retail, or the broader AI software development lifecycle.

Thinking about your first MCP server? Book a 30-minute architecture call and we will help you pick the system to start with, size the integration surface, and map the authorization model to your IdP — no obligation.

Sources

• Model Context Protocol — official documentation and architecture overview, modelcontextprotocol.io
• MCP Specification, protocol version 2026-07-28 — statelessness, discovery, subscriptions, deprecations and the Tasks extension
• MCP Security Best Practices — confused deputy, token passthrough, SSRF, state handle hijacking, local server compromise and scope minimisation
• MCP Authorization specification, including the Enterprise-Managed Authorization and OAuth Client Credentials extensions