Optimizely CMS 用の Discovery-First MCP の構築 – パート 1/4 – Johnny Mullaney

この投稿は、Optimizely Model Context Protocol (MCP) をどのように進化させているかを説明する 4 部構成のシリーズの始まりです。

プロジェクトはまだ ベータ版 そして オープンソースですが、すでに Optimizely SaaS CMS に接続し、そのスキーマをリアルタイムで検出し、事前定義されたマップなしで有効なクエリを生成するなど、何か新しいことが可能になっています。

ここでコードを調べることができます。 GitHub 上の CMS MCP を最適化する。

このシリーズの内容は次のとおりです。

• パート 2: ディスカバリー層とキャッシュ層が内部でどのように機能するか
• パート 3: Visual Builder の複雑な構成階層の処理
• パート 4: ロードマップ — マルチテナント アーキテクチャ、リモート MCP、および潜在的な AI 主導のユースケース

Discovery-First MCP が必要な理由

私が初めて MCP を導入したとき MCP で遊ぶ: Optimizely CMS の実験用サーバー、これは概念実証であり、AI またはオートメーション レイヤーが Optimizely の Graph API と Content API を通じてコンテンツをクエリできるようにする単一のインターフェイスです。

スターター テンプレートではうまく機能しましたが、現実の世界ではうまく機能しませんでした。
すべての Optimizely CMS は、最終的に独自のコンテンツ タイプ、命名規則、およびネストされた構造のセットを持ちます。テンプレートから離れると、前提が崩れ始めます。

この再構築の目標は単純です。 思い込みをやめて発見を始めましょう。

MCP に CMS とは何かを教える代わりに すべき どうやら、私たちはそれができるようにしました それが実際に何なのかを学ぶことです。

核となるアイデア

新しい MCP はその中核として次の 5 つのことを行います。

1. 発見する GraphQL イントロスペクションを通じて利用可能なすべての型とフィールド。
2. 分析 これらの構造は、関係と考えられるインテント マッピングを理解するために使用されます。
3. 生成します GraphQL は、検出した内容に基づいて動的にクエリを実行します。
4. キャッシュ 発見されるため、繰り返しのリクエストは瞬時に行われます。
5. 適応する スキーマが変更されると自動的に変更されます。

これによりMCPが作成されます スキーマ対応 の代わりに スキーマに依存します。

アーキテクチャの概要

MCP は AI インターフェイスと Optimizely CMS の間に位置し、両方を処理します。 検索 そして コンテンツ制作 適切な API を通じて。

ディスカバリー層 — GraphQL イントロスペクションを通じてコンテンツ モデルを学習します。
マッピングエンジン — 構造とフィールドの関係を解釈します。
クエリジェネレータ — ライブスキーマからクエリとミューテーションを構築します。
コンテンツ運営 — Content API を使用して、完全なコンテキスト認識でエントリを作成または更新します。
キャッシュと状態 — 高速再利用のためにスキーマ データを保存します。

この設計により、MCP は両方の機能を実現します。 スキーマ対応 そして スキーマ適応型: 事前に形状を知らなくても、Optimizely CMS に対してインテリジェントに読み書きできます。

ビジュアルビルダーの発見

Visual Builder では、発見が興味深いものになります。
そのページはフラットなコンテンツ タイプではなく、コンポーネントのツリーです。

各コンポーネントは独自のスキーマを導入します。
MCP にその構造をナビゲートするように教えることは、動的なフラグメント生成と再帰的イントロスペクションを意味します。このトピックについては後で詳しく説明します。 パート 3。

次に何をするか

パート 2MCP がどのようにスキーマ データを効率的に検出してキャッシュし、クエリを高速に保ち、リクエストごとの再イントロスペクションを回避するかを説明します。

このシリーズの後半では、ロードマップの次の内容について見ていきます。 マルチテナント「リモート MCP」、および次のような潜在的なユースケース AI を活用したデータ移行 Sitecore や Optimizely などのシステム間。