For the past few years, most enterprise AI conversations have focused on models.

Which model is smartest?

Which model is fastest?

Which model has the largest context window?

Which model performs best on a particular benchmark?

Those questions matter, but they increasingly miss the more important issue.

The future of enterprise AI will not be determined solely by which model produces the best answer. It will be determined by whether that model can safely understand an organisation, access its systems and perform useful work.

That is why the Model Context Protocol, better known as MCP, may prove more significant than many individual model releases.

MCP is an open protocol designed to connect AI applications with external tools, systems and sources of information. It provides a standard way for an AI client to discover what capabilities are available, understand how to use them and exchange information with them.

The easiest analogy is that MCP could become something like USB-C for enterprise AI.

USB-C did not replace cameras, monitors, storage devices or phones. It standardised the way those devices connected.

MCP does not replace APIs, databases, CRMs, CMSs or business applications. It gives AI systems a more consistent way to interact with them.

The problem MCP is attempting to solve

Large language models are remarkably capable in isolation, but isolation is also their greatest limitation.

A model may understand how a content migration should work in theory. It does not automatically know:

• which content exists in your CMS;
• how that content is structured;
• who owns it;
• which pages are commercially important;
• which records contain personal data;
• which workflows require approval;
• or which API operation is permitted.

Without access to live business context, the model is effectively an exceptionally articulate outsider.

Organisations have attempted to solve this by building custom integrations between models and enterprise systems. One integration connects an assistant to Salesforce. Another accesses SharePoint. A third queries the CMS. A fourth creates tickets in Jira.

The result is familiar to enterprise architects: duplicated authentication logic, inconsistent schemas, brittle connectors and an expanding maintenance burden.

Every model-to-system combination becomes another bespoke integration.

MCP proposes a common interaction layer.

An MCP server can expose resources, reusable prompts and tools. Tools can allow an AI system to query databases, invoke APIs, perform calculations or take actions in external applications. The protocol also defines capability negotiation, lifecycle management and authorisation for HTTP-based connections.

In practical terms, an enterprise system can describe what it allows an AI agent to do rather than requiring every AI application to understand its proprietary implementation.

MCP does not replace APIs

It is tempting to describe MCP as the successor to REST, GraphQL or traditional APIs.

That is not quite right.

Traditional APIs remain the execution layer. They provide deterministic methods for retrieving or modifying data.

MCP operates above that layer.

It makes capabilities easier for an AI system to discover and use.

A conventional API may expose an operation such as:

POST /api/content/v3/items

An MCP tool could expose that operation as:

create_content_item

The tool definition could include a machine-readable description of the expected fields, permitted actions and response structure.

The underlying API still performs the work. MCP makes that API legible to an AI agent.

This distinction matters because enterprise organisations have already invested heavily in APIs. MCP does not require those investments to be discarded. It can provide an AI-native façade over them.

Why MCP matters to enterprise platforms

Enterprise software has historically been designed around human interfaces.

A CRM presents forms, dashboards and account views.

A CMS presents editing interfaces, content trees and publishing controls.

An ERP presents workflows for finance, procurement and supply-chain management.

AI agents introduce a new category of user.

That user does not necessarily need a visual interface. It needs:

• a description of available capabilities;
• structured inputs and outputs;
• identity and authentication;
• appropriate permissions;
• clear operational boundaries;
• and evidence of what happened.

MCP gives software vendors a way to present their platforms to that new user.

This has significant implications.

A CMS may no longer be consumed only through its editorial interface and delivery APIs. It may also expose governed tools through which an agent can find content, propose updates, translate records, initiate workflows or analyse performance.

A CRM may expose tools for finding opportunities, preparing account summaries or updating records.

A commerce platform may expose tools for checking inventory, investigating abandoned baskets or adjusting merchandising rules.

The strategic question for enterprise software vendors therefore becomes:

How effectively can your platform represent itself to an AI agent?

MCP and the CMS

CMS platforms are particularly well suited to MCP because their underlying assets are already highly contextual.

A mature CMS contains:

• content types and schemas;
• relationships between content;
• metadata and taxonomies;
• versions and publishing history;
• languages and markets;
• permissions;
• approval workflows;
• and channel-specific presentation rules.

That information is more valuable to an agent than a folder full of unstructured documents.

An MCP-enabled CMS could offer tools such as:

• find all content referring to a discontinued product;
• identify pages that have not been reviewed for two years;
• generate a localisation brief using the source content and market rules;
• create a draft campaign page from an approved template;
• submit an item for legal review;
• compare content performance against experimentation results;
• or explain which content dependencies would be affected by a proposed change.

The agent would not need direct database access. It would operate through controlled platform capabilities.

This is a much safer architectural pattern than granting a general-purpose AI unrestricted access to the content repository.

Security is the real enterprise test

The technical elegance of MCP is not enough on its own.

The protocol becomes valuable to enterprises only when identity, consent, authorisation and auditing are handled rigorously.

The MCP specification defines an authorisation framework for HTTP-based transports, while its security guidance identifies implementation risks and recommends defensive practices for server operators and developers.

However, implementing OAuth does not automatically make an agent secure.

Organisations still need to answer difficult questions:

• Does the agent act as itself or on behalf of a user?
• Are permissions evaluated for every tool invocation?
• Can an agent access information from another customer or business unit?
• Which actions require human approval?
• Can the agent write directly to production?
• Are tool inputs and outputs logged?
• How are prompt-injection attacks handled?
• What happens when an external tool returns malicious instructions?
• Can administrators revoke access immediately?

The secure implementation of MCP will matter more than simply claiming MCP compatibility.

A poorly governed MCP server could expose business-critical operations through an interface that agents can invoke at scale.

A well-designed implementation becomes a controlled, observable gateway into enterprise capabilities.

MCP will not eliminate integration work

Standards often create the impression that integration complexity will disappear.

It rarely does.

MCP can standardise how tools are described and invoked. It cannot automatically resolve:

• inconsistent customer identifiers;
• poor data quality;
• undocumented business rules;
• conflicting permission models;
• fragmented ownership;
• or legacy systems with unreliable APIs.

It simplifies connectivity, not organisational complexity.

Enterprises will still need strong data contracts, service ownership and governance.

The difference is that MCP could reduce the amount of bespoke plumbing required between AI clients and business systems.

From chatbots to operational systems

The first generation of enterprise AI was mostly conversational.

Ask a question.

Receive an answer.

The next generation is operational.

Find information.

Make a decision.

Use a tool.

Observe the result.

Continue the workflow.

That transition requires a standard way for models to interact with software.

OpenAI, for example, now describes enterprise agent platforms in terms of shared business context, systems of record, permissions and governed execution rather than model access alone.

This is the broader shift MCP represents.

AI is moving from being a feature embedded within software to becoming an actor that uses software.

What should enterprise architects do now?

Organisations do not need to expose every platform through MCP immediately.

They should begin by identifying a small number of high-value, low-risk capabilities.

Good early candidates include:

• read-only search;
• metadata retrieval;
• content classification;
• draft creation;
• reporting;
• knowledge discovery;
• and workflow initiation that still requires human approval.

Avoid beginning with irreversible actions such as financial transactions, production deletion or unrestricted content publishing.

Architects should also separate three concerns:

The business capability

What is the organisation allowing an agent to do?

The service implementation

Which API or internal service performs the work?

The agent interface

How is that capability represented through MCP?

Keeping these layers distinct makes it easier to change models, clients or protocols later.

The Optimizely opportunity

For platforms such as Optimizely, MCP presents an opportunity beyond simply adding another connector.

Optimizely already sits across content, experimentation, personalisation and digital experience workflows. Opal is evolving as an agent and orchestration layer spanning those capabilities, with contextual access to areas such as experimentation and CMS operations.

The strategically interesting possibility is not merely allowing an external assistant to retrieve Optimizely content.

It is exposing governed digital-experience capabilities that combine multiple products.

An agent might be able to:

1. identify an underperforming landing page;
2. analyse its content and experimentation history;
3. generate a revised variant;
4. create the content item;
5. configure an experiment;
6. route it for approval;
7. and report the eventual result.

That is far more valuable than a generic chatbot connection.

The differentiation would come from the depth of business context and the quality of the available tools, not from MCP compatibility alone.

Final thoughts

MCP is not glamorous in the way a new frontier model is glamorous.

It is infrastructure.

Infrastructure is rarely exciting until it becomes indispensable.

The long-term importance of enterprise AI will not be measured by how fluently a model can discuss a company. It will be measured by how safely and effectively that model can work within the company.

That requires standards for tools, context, permissions and execution.

MCP may not become the only standard in this space. It may evolve considerably, and enterprise implementations will still require careful architectural design.

But it addresses one of the defining problems of the agentic era:

How do we connect intelligent systems to the real capabilities of an organisation without rebuilding every integration from scratch?

That is why MCP may turn out to be one of the most consequential technologies in enterprise AI.

Not because it makes models more intelligent.

Because it makes their intelligence usable.