Tag: artificial-intelligence

Building a Discovery-First MCP for Optimizely CMS – Part 1 of 4

This post kicks off a four-part series on how we’re evolving the Optimizely Model Context Protocol (MCP).

The project is still in beta and open source, but it’s already capable of something new: connecting to any Optimizely SaaS CMS, discovering its schema in real time, and generating valid queries without a predefined map.

You can explore the code here: Optimizely CMS MCP on GitHub.

Here’s what’s coming in this series:

  • Part 2: How the discovery and caching layers work under the hood
  • Part 3: Handling Visual Builder’s complex composition hierarchy
  • Part 4: The roadmap — multi-tenant architecture, remote MCP, and potential AI-driven use cases

Why we need a Discovery-First MCP

When I first introduced MCP in Playing with MCP: An Experimental Server for Optimizely CMS, it was a proof of concept — a single interface that let AI or automation layers query content through Optimizely’s Graph and Content APIs.

It worked well for the starter template, but not for the real world.
Every Optimizely CMS ends up with its own set of content types, naming conventions, and nested structures. Once you leave the template, assumptions start to break.

The goal of this rebuild is simple: stop assuming and start discovering.

Instead of teaching MCP what a CMS should look like, we’ve made it capable of learning what it actually is.

The Core Idea

At its core, the new MCP does five things:

  1. Discovers all available types and fields through GraphQL introspection.
  2. Analyses those structures to understand relationships and possible intent mappings.
  3. Generates GraphQL queries dynamically based on what it finds.
  4. Caches discoveries so repeated requests are instant.
  5. Adapts automatically when the schema changes.

This makes MCP schema-aware instead of schema-dependent.

Architectural Overview

The MCP sits between AI interfaces and the Optimizely CMS, handling both retrieval and content creation through the appropriate APIs.

Discovery Layer — learns the content model via GraphQL introspection.
Mapping Engine — interprets structures and field relationships.
Query Generator — builds queries and mutations from the live schema.
Content Operations — uses the Content API for creating or updating entries with full context awareness.
Cache & State — stores schema data for fast reuse.

This design makes MCP both schema-aware and schema-adaptive: it can read and write intelligently to any Optimizely CMS without knowing its shape ahead of time.

Visual Builder Discovery

Visual Builder is where discovery gets interesting.
Its pages aren’t flat content types — they’re trees of components:

Each component introduces its own schema.
Teaching MCP to navigate that structure meant dynamic fragment generation and recursive introspection — topics we’ll dig into in Part 3.

What next

Part 2, I’ll explain how MCP discovers and caches schema data efficiently, keeps queries fast, and avoids re-introspection every request.

Later in the series, we’ll look at what’s next on the roadmap — including multi-tenant “remote MCP”, and potential use cases like AI-driven data migration between systems such as Sitecore and Optimizely.

Playing with MCP: An Experimental Server for Optimizely CMS

I’ve been tinkering with something experimental: an MCP server for Optimizely CMS.

MCP, or Model Context Protocol, is a way for AI tools to talk to external systems. It’s not a REST API, and it’s not GraphQL either. Think of it more like a common “protocol wrapper” that lets AI assistants discover what a server can do — what data it exposes, what actions it supports — and then call those capabilities in a structured way.

Here’s the catch: MCP isn’t really built to run over HTTP like most APIs we’re used to. Right now it’s more about local connections (stdio, sockets). That’s fine for experiments, but it does mean it’s not drop-in ready for cloud deployments.

That said, I think if MCP evolves to run reliably over HTTP, we’ll start to see some very cool “public MCP” layers: imagine subscribing to a SaaS tool, dropping your API key into your AI desktop, and instantly being able to query and manage your data. We’re not there yet, but it’s worth exploring.

What I built

This MCP server sits in front of Optimizely CMS and combines two APIs:

  • Graph API – to query content and inspect content types.
  • Content Management API – to create, update, publish, and manage content.

So instead of juggling multiple APIs, the MCP server gives you a single entry point that AI assistants can plug into.

Out of the box, the server supports:

  • Fetching content with different auth methods (keys, OAuth, HMAC, etc.)
  • Managing versions and workflows
  • Exploring content type schemas
  • Handling multiple languages
  • Adding a caching layer for performance

It’s built in TypeScript with runtime validation, so it’s fairly solid — but for now it’s still experimental.

Potential Use Cases

For developers

  • Connect the MCP server to something like Cursor or VS Code.
  • Debugging headless builds becomes easier:
    “What’s the Graph data for this URL?”
    “Show me the schema for this content type.”

For marketers

  • Imagine asking your AI assistant questions like:
    “How many published pages use this content type?”
    “Which pieces of content are waiting for approval?”
    “Show me the graph data behind this article.”

Where this could go

Right now, this is a side experiment. It’s not production-ready, and MCP itself is still finding its footing. But I see a possible future where MCP servers can be hosted over HTTP, sitting in front of APIs like Optimizely’s Graph and Content Management APIs.

That would open up some powerful use cases: SaaS vendors offering public MCP endpoints, customers connecting their own AI desktops/agents with nothing more than an API key, and assistants becoming first-class clients of CMS platforms.

Try it out

he code is open source here: https://github.com/first3things/optimizely-cms-mcp

Clone it, run it locally, and see what you can do. If you’ve got thoughts on where MCP should head — especially around HTTP exposure and public access — I’d love to hear them.