MCP対応CMS比較：公式サーバーで何ができる？

Contentful、Sanity、Strapi、microCMS、genko.meは公式のコンテンツ操作用MCPサーバーを提供しています。WordPressには公式MCP Adapterがあり、WordPress.comにはホスト型サーバーがあります。ただし、公式対応でも公開・スキーマ変更・画像アップロードの範囲は異なります。microCMSのホスト型MCPはベータ版です。

CMSのMCPサーバーは何を比較すればよいですか？

まず「公式ドキュメントを検索するMCP」と「自分のCMSデータを操作するMCP」を区別します。仕様を調べられるだけでは、記事を保存できることにはなりません。

次の表は各社の公式ツール一覧に基づきます。「記載なし」は公式サーバーがないという意味ではなく、確認した標準ツールにその操作が載っていないという意味です。独自実装やプラグインで追加できる可能性とは分けています。

MCPはClaude専用ではありません。Claude Code、Codex、Cursorなどで使えますが、接続先が求めるHTTP方式、OAuth、カスタムヘッダーへの対応をクライアントごとに確認します。

各CMSの公式MCPでできることと接続方法

Contentful：コンテンツモデルも操作する場合

公式ガイドには、エントリの作成・更新・公開、コンテンツタイプの変更、アセット操作が掲載されています。ホスト型の接続先はhttps://mcp.contentful.com/mcp、認証はOAuth 2.1です。対象space・environmentへのMCPアプリ導入と設定も必要で、ユーザー権限とアプリの許可リストが適用されます。

ローカル版はnpx @contentful/mcp-serverで起動し、Management APIのPATを使います。こちらはPATの権限が境界です。既定のspace指定だけをアクセス制限と考えないでください。

Sanity：コンテンツとスキーマを一緒に扱う場合

Sanity公式MCPはhttps://mcp.sanity.ioへ接続します。OAuthが既定で、Bearer APIトークンも使えます。npx sanity@latest mcp configureで対応クライアントへ設定できます。

ドキュメントの検索・作成・変更・公開に加え、スキーマの取得・デプロイ・編集、アセットのアップロードを提供します。ただしMCP経由の検証ではカスタム検証ルールがスキップされます。スキーマを扱えることと、Studioの検証をすべて再現できることは別です。

Strapi：自分のインスタンス内で運用する場合

Strapi公式MCPは5.47.0以降の組み込み機能です。サーバー設定でmcp.enabledを有効にして再起動し、自分のStrapiの/mcpへ接続します。認証はAdmin tokenをBearerヘッダーで渡します。

コンテンツの取得・作成・更新に対応し、Draft & Publishを有効にしたモデルでは下書き・公開・公開終了を扱えます。5.54.0以降はMedia Libraryの一覧やメタデータ・フォルダー管理もありますが、新規ファイルは管理画面かUpload APIで追加します。コンテンツモデルからツールが生成されることは、モデル自体を変更できるという意味ではありません。

WordPress：WordPress.comとAdapterを分ける

WordPress.com公式サーバーはhttps://public-api.wordpress.com/wpcom/v2/mcp/v1へOAuth 2.1で接続します。アカウントのMCPアクセスを有効にして使い、Jetpack接続の自前サイトも同じサーバーの対象です。ツール一覧ではposts.createは既定で下書き、posts.updateはstatus: publishなら即時反映です。メディア作成もあります。

独立した自前サイトには公式MCP Adapterという経路もあります。HTTPまたはWP-CLIのSTDIOでWordPressのAbilitiesを公開する仕組みです。HTTPの既定パスは/wp-json/mcp/mcp-adapter-default-serverで、認証・権限はtransportと各Abilityで管理します。公式接続例はHTTPプロキシでApplication Passwords、STDIOでは--user指定を使います。Adapterだけで全操作が揃うとは考えず、公開するAbilitiesを確認します。

microCMS：文書検索専用MCPと取り違えない

公式microCMS MCPはベータ版のホスト型で、接続先はhttps://mcp.microcms.io/mcp/{サービスID}です。APIキーをAuthorization: Bearerヘッダーで渡し、OAuthには対応していません。

読み取りに加え、下書き作成、公開状態変更、予約設定、メディア操作があります。公開で作成するツールと下書きで作成するツール、公開内容を更新するツールと下書き専用の更新ツールが別なので、名前まで確認します。API定義の取得はできますが、スキーマ変更はツール一覧にありません。Document MCP Serverは公式資料の検索・取得用で、用途が異なります。

genko.me：原稿の下書きと公開権限を分ける場合

genko.meのMCPはhttps://genko.me/mcpへのOAuth付きStreamable HTTP接続です。CLIはClaude Code、Codex、Cursor、VS Code向け設定を用意しています。

create_draft・update_draftで保存し、publish_entry・schedule_entryで公開・予約します。公開中の原稿へのupdate_draftは未公開の変更になり、discard_changesで破棄できます。これは公開後の履歴復元とは異なります。

編集には編集者以上とmcp:write、公開・予約にはさらにmcp:publishが必要です。メディア操作はありますが、アップロードにはプランの容量・ファイル上限が適用されます。スキーマを変更するMCPツールは掲載されていません。

AIエージェントへ公開を任せる前の確認

CMS選びでは、次の順に小さく試すと判断できます。これは運用例で、どのCMSにも同じ承認機能があるという意味ではありません。

1. 読み取りだけで接続する。 対象サイト、環境、API、言語、フィールドを取得し、想定外の範囲へアクセスできないか確認します。

2. 試験用の下書きを1件作る。 保存結果を読み直し、本文、参照、画像、公開状態を確認します。「更新」が公開中の記事に即時反映されるかも調べます。

3. 公開を別の承認にする。 原稿ID、変更差分、言語、公開時刻を人が確認します。「下書きだけ」というプロンプトに加え、トークンやロールでも操作を制限します。

4. 監査と復旧を試す。 操作者、対象ID、変更前後、実行時刻を何で追えるか確認します。履歴・監査・復元の有無と利用条件は個別に調べ、必要なら変更前データを別に保存します。

5. 公開後のサイトも確認する。 CMSの成功応答と、サイト側のキャッシュ更新・ビルド完了を分けて扱います。応答が途切れた場合は、再作成前に既存データを調べます。

公開終了、過去版の復元、未公開変更の破棄は違う操作です。画像やスキーマの削除まで同じ手順で戻せると仮定せず、復旧対象を決めます。

既存のContentfulやSanityでモデル管理まで必要なら、その公式MCPを試す理由があります。自前運用が要件ならStrapiやWordPress Adapterが候補です。microCMSで運用が安定しているなら、公式MCPの権限とベータ条件を検証してから移行の要否を判断できます。genko.meも下書き・公開・メディア操作を求める場合の選択肢ですが、モデル変更までMCPに任せる用途には合いません。

具体的な入稿手順はClaudeからCMSへ下書き・公開する方法、アプリ実装との役割分担はAIエージェントとCMSの連携を参照してください。

よくある質問

公式MCPサーバーがあれば記事を公開できますか？

文書検索専用なら公開できません。コンテンツ操作用でも、公開ツールと必要な権限の両方が必要です。ツール一覧と認証後の実際の許可範囲を確認します。

CodexやCursorでもCMSのMCPを使えますか？

対応クライアントで使えます。Claude専用ではありません。サーバーが要求するtransport、OAuth、Bearerヘッダーと、クライアント側の対応を照合してください。

AIには下書きだけを作らせられますか？

下書き用ツールを選び、公開権限を制限する構成を検討します。書き込み権限だけで即時公開の操作まで可能かは製品ごとに異なるため、テスト用データで確認します。

MCPでCMSのスキーマも変更できますか？

ContentfulとSanityには関連ツールがあります。今回のStrapi、WordPress.com、microCMS、genko.meの標準一覧では、同等のモデル定義変更は確認できません。API定義を読めることだけで変更可能とは判断しません。