Optimizely Remote MCP Server: What AI Can (and Can't) Do With Your Experiments

Optimizely has just released a Remote MCP Server for Experimentation, and our team has been testing it from day one. The headline is simple: any AI assistant that supports the Model Context Protocol - Claude, ChatGPT, Cursor, and others - can now talk directly to your Optimizely experimentation data without local servers, manual API keys, or custom plumbing. For experimentation teams already considering how to embed AI into daily workflows, this is a meaningful shift.

This article walks through what the Remote MCP Server is, how to set it up, what it can do today, and where it still requires a human in the loop. The findings are based on hands-on testing against a live Optimizely Sandbox project.

What is Optimizely's Remote MCP Server for Experimentation?

The Model Context Protocol (MCP) is the emerging standard for how AI tools connect to external services. It is what lets a model like Claude reach beyond its own knowledge and read, query, or modify data in a third-party system in a structured way.

Optimizely already offered a local MCP server, which required developers to run the bridge themselves. The new Remote MCP Server is hosted by Optimizely directly. Anyone with an Optimizely Experimentation login can point their AI client at a single endpoint and authenticate via OAuth. From that point on, the AI assistant has read and limited write access to projects, experiments, variations, metrics, and traffic allocation - subject to the usual user permissions.

In practical terms, this collapses a class of work that previously required either custom API code or manual clicks in the Optimizely UI.

The documented approach in Optimizely's setup guide uses a direct URL transport. On Mac with Claude Desktop, that did not work cleanly during our testing. Both of the following produced errors:

claude mcp add --transport http optimizely-exp https://exp.mcp.opal.optimizely.com/mcp

{
  "mcpServers": {
    "optimizely": {
      "url": "https://exp.mcp.opal.optimizely.com/mcp"
    }
  }
}

Claude Desktop returned a "Some MCP servers could not be loaded" error on launch.

The fix is straightforward. Use the mcp-remote npm package as a bridge in your claude_desktop_config.json instead:

{
  "mcpServers": {
    "optimizely": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://exp.mcp.opal.optimizely.com/mcp"
      ]
    }
  }
}

After restarting Claude Desktop, a browser window opens for OAuth with your Optimizely credentials and prompts you to select the project to connect. From there, the integration is live.

We started with a deliberately simple prompt: "list my Optimizely projects". After approving the tool action, Claude returned a clean, structured table.

We then drilled into the Niteco Sandbox project to see all experiments at once - status, type, traffic allocation, last modified - in a single response.

Going one level deeper, we asked Claude to summarise a running A/B test called "Metrics Setup". Claude returned an overview, traffic split, full metric results, and a set of key takeaways - including flagging a deliberately broken traffic allocation we had set up to test how the AI would react.

Two things stood out. First, Claude correctly identified that the traffic split was unintentionally skewed (none on the Original and all on Variation #1) and flagged it as worth investigating. Second, it correctly noted that the sample size was too small for any of the lift figures to be statistically significant - a guardrail that matters when AI summaries can otherwise be taken at face value.

Next, we asked Claude to fix the traffic split. It pulled the experiment entity template, confirmed exactly what it was about to change, and applied a 50/50 split when given the go-ahead.

The change registered immediately on the experiment as a draft. In Optimizely's UI, the Traffic Allocation tab showed a "CHANGED" tag next to it.

This is where the test ran into its first real wall. Claude reported the change as live, but it had only modified the draft. Nothing had actually been published to visitors. When asked to publish the experiment so the change would go live, the available MCP tools did not include a dedicated publish action.

The conclusion: the final click that pushes a change to the snippet or CDN, the one that actually exposes it to real visitors, is reserved for the Optimizely UI. To go live, a person still needs to open the experiment in Optimizely and click Publish Experiment.

This is a deliberate design choice rather than a missing feature. AI assistants can read everything, summarise everything, and modify draft state, but they cannot ship changes to production traffic on their own. For most enterprise experimentation programmes, that is the correct trade-off today. It would be a sensible enhancement for Optimizely to expose publish as a project-level setting in future, so teams that want full AI control can opt in.

Optimizely's Remote MCP Server is most useful right now for the work that surrounds running experiments rather than the publish step itself:

• Reporting and summarisation. Pulling experiment results, lift percentages, and statistical context into a single readable summary, on demand, in any AI client.
• Anomaly detection. Surfacing skewed traffic, broken metrics, or experiments that have been left running past their useful life.
• Cross-project visibility. Inspecting experiment status across multiple projects in one prompt, without clicking through the UI.
• Draft setup and clean-up. Adjusting variation weights, audiences, and metric configuration as drafts before a human approves and publishes.

For experimentation teams running programmes at scale, this collapses a meaningful amount of weekly reporting and admin overhead. It also lowers the barrier for non-technical stakeholders to query experiment data conversationally rather than through dashboards.

To understand how AI-native workflows are reshaping experimentation more broadly, read How AI Is Transforming Experimentation.

Connecting an AI assistant to Optimizely is the easy part. Designing experimentation workflows that actually use it well, with the right governance, prompt patterns, and integration points, is where most teams need a partner.

Niteco is the world's largest Optimizely partner with 70+ Opal Certified specialists, and was named Optimizely's AI Innovator Partner of the Year and Preferred Opal AI Partner for APJ in 2026. Our team also took the Grand Prize at Optimizely's Opal Tools Hackathon for an AI-Powered Experimentation Strategist agent built natively in Opal.

That experience translates into three practical engagements for teams adopting MCP-driven experimentation:

1. Opal Foundations. Standard agent enablement for experimentation reporting and content variation, deployed in around four weeks.
2. Opal Accelerator. Custom agentic solutions, including MCP-connected workflows, designed and deployed in around eight weeks.
3. Opal Enterprise. Full agentic workflow design across the experimentation lifecycle, with strategic roadmap and 24/7 support.

If your team is evaluating whether to build on top of Optimizely's Remote MCP Server, or wants to understand where AI agents can responsibly take work off your experimentation team's plate, we can help you scope it.

Talk to Niteco about AI-native experimentation