Cloudflare MCPサーバー一覧 — WorkersやR2をClaudeから操作する

Cloudflareの公式MCPサーバーは2系統あります。1つは全APIをsearchとexecuteのコード実行で扱うCloudflare API MCPサーバー(mcp.cloudflare.com)、もう1つはWorkers・R2周辺・観測性・Radarなど製品ごとに分かれた専用サーバーです。どちらもOAuthで接続でき、Claude Codeからはclaude mcp add1行で登録できます。

迷ったときの目安は次のとおりです。複数製品をまたぐ探索や設定変更はAPI MCP、ログの調査やドキュメント参照のように用途が決まっているなら専用サーバーです。

Cloudflare API MCPサーバーとは — 2,500超のエンドポイントを少ないトークンで扱う

Cloudflare API MCPサーバーは、DNS・Workers・R2・Zero TrustなどCloudflare APIの全エンドポイント(2,500超)を、エンドポイントごとのツール定義なしで扱えるサーバーです。方式は「search-and-executeのCode Modeパターン」と呼ばれます。モデルがOpenAPI仕様とCloudflare APIクライアントの型表現に対するJavaScriptを書き、そのコードが隔離されたDynamic Workerのサンドボックスで実行されます。

ここで押さえておきたいのは、searchもexecuteも自然言語を受け取るツールではなく、JavaScriptのコードを受け取るツールという点です。

READMEにはツールが3つ載っています。searchとexecuteに加えて、Cloudflareの開発者ドキュメントを検索するdocsです。ツール数はREADMEがdocsを含む3つ、公式ドキュメントのページが2つと数えています。

GraphQL Analytics APIも別のツールは要りません。READMEの例では、executeのコードからcloudflare.request()でパス/client/v4/graphqlにPOSTし、zoneTagで1つのゾーンに絞り、日次のリクエスト数や転送バイト数といった集計をクエリで引いています。

必要なトークン量は、同じREADMEの比較表で並べるとはっきりします。

トークンの消費を抑える設計は、MCP全般の課題でもあります。ツール定義をどう減らすかはMCPのトークンオーバーヘッドを抑える設定にまとめています。

Cloudflare API MCPサーバーへの接続手順

エンドポイントはhttps://mcp.cloudflare.com/mcpです。MCPクライアントの設定ファイルには、Cloudflareのドキュメントでは次の形で書かれています。

{
  "mcpServers": {
    "cloudflare-api": {
      "url": "https://mcp.cloudflare.com/mcp"
    }
  }
}

Claude CodeではHTTPトランスポートを指定してclaude mcp addで追加します。

claude mcp add --transport http cloudflare-api https://mcp.cloudflare.com/mcp

接続するとCloudflareへリダイレクトされ、OAuthで認可したうえで、エージェントに付与する権限を選びます。READMEはこのOAuthを推奨の方法として挙げています。

APIトークンで渡す(CI/CD・自動化向け)

ブラウザー操作を挟めない環境では、CloudflareのAPIトークンを発行し、AuthorizationヘッダーのBearerトークンとして渡します。ユーザートークンとアカウントトークンの両方が使えます。Claude Code v2.1.287のclaude mcp add --helpには、ヘッダーを付ける-H, --headerオプションがあります。

claude mcp add --transport http --scope project cloudflare-api \
  https://mcp.cloudflare.com/mcp \
  --header "Authorization: Bearer <API_TOKEN>"

空の設定ディレクトリでこのコマンドを実行すると、プロジェクト直下の.mcp.jsonに次の内容が生成されました。typeがhttpで書き込まれ、トークンは平文のままheadersに入ります。

{
  "mcpServers": {
    "cloudflare-api": {
      "type": "http",
      "url": "https://mcp.cloudflare.com/mcp",
      "headers": {
        "Authorization": "Bearer <API_TOKEN>"
      }
    }
  }
}

コマンドの出力側ではヘッダーの値が[REDACTED]と表示されますが、.mcp.jsonのファイルには実トークンが残ります。--scope projectで作ると、このファイルをリポジトリにコミットしてしまう事故が起こりえます。トークンはコミット対象のファイルに書かず、--scope local(既定)で登録するか、環境変数を使う運用という選択肢があります。

READMEにはトークン利用時の条件が2つあります。アカウントトークンには「Account Resources : Read」権限を含めると、サーバーがアカウントIDを自動検出できます。ユーザートークンでは自動検出されないため、executeにaccount_idを渡します。また、Client IP Address Filteringを有効にしたAPIトークンはサポートされていません。

URLのクエリで挙動を切り替える

READMEには、接続URLに付けるクエリパラメーターが2つ載っています。

docsツールはCode Modeを切っても使えます。

/sseのURLは使えるのか

新規接続では/mcpを使います。docsでは、過去の/sseのURLは同じStreamable HTTPハンドラーのエイリアスとして残り、非推奨のHTTP+SSEトランスポートは提供されないと説明されています。mcp-server-cloudflareのREADMEには、SSEとしてのGET /sseに410 Goneが返るとあります。SSEを強制しているクライアントは、Streamable HTTPか自動判定に切り替えます。

製品別MCPサーバー一覧 — 用途が決まっているときの専用サーバー

製品別のサーバーは、サブドメインごとにエンドポイントを持ちます。Cloudflareのドキュメントのサーバー一覧は次の16件です。

URLは機械的な命名ではありません。Digital Experience Monitoringはdex、Cloudflare One CASBはcasbと略されます。また、Agents SDK Documentationだけは.mcp.を含まないagents.cloudflare.com/mcpです。AI Searchは製品名が旧AutoRAGから変わった一方で、サブドメインはautoragのままです。

ドキュメントとGitHubで一覧が違う

現在のGitHubリポジトリ(mcp-server-cloudflare)のREADMEと、Cloudflareのドキュメントでは、サーバーの顔ぶれが一致していません。

Audit Logsの専用サーバーは、プルリクエスト#492で非推奨になりました。説明によれば、移行期間中はauditlogs_by_account_idが動き続け、ルートのサーバー一覧とserver.jsonからはURLの掲載をやめています。Audit Logs v2 API自体は非推奨ではなく、後継はCloudflare API MCPサーバーです。?codemode=falseで使えるエンドポイントツールget_accounts_logs_auditが、同じGET /accounts/{account_id}/logs/auditを呼びます。

Claude Codeプラグインとしてまとめて導入する

CloudflareはMCPサーバー群に、コンテキスト用のスキルとスラッシュコマンドを束ねた「Cloudflare Skillsプラグイン」を配布しています。Agent Skills標準に対応するClaude Code・OpenCode・OpenAI Codex・Piで使えます。Claude Codeではプラグインマーケットプレイスから入れます。

/plugin marketplace add cloudflare/skills

プラグインを使わずスキルだけを入れる場合は、npx skills add https://github.com/cloudflare/skillsか、リポジトリのクローンを各エージェントのスキルディレクトリへコピーします。置き場所は次のとおりです。Claude Codeが~/.claude/skills/。Cursorが~/.cursor/skills/、OpenCodeが~/.config/opencode/skills/、OpenAI Codexが~/.codex/skills/、Piが~/.pi/agent/skills/です。Cursorでは、Marketplaceのほかに「Settings → Rules → Add Rule → Remote Rule (Github)」でcloudflare/skillsを指定する方法もあります。

プラグイン経由でMCPサーバーが自動登録される挙動は、プラグインに同梱されたMCPサーバーの仕組みで扱っています。

どちらを選ぶか — 状況別の切り分け

選ぶ軸は、依頼がどの製品にまたがるかと、エージェントに渡す権限の幅です。

権限の話では、mcp-server-cloudflareのissue #485では、第三者がこう問いかけています。本番のDNSを変えるような大きな操作を、トークンの権限以外の何が止めるのか、という問いです。このissueはコメントが付いていない提案型の投稿です。障害調査のような用途では、読み取り専用のトークンで始めて変更系の権限を後から足す、という選択肢があります。

デプロイ基盤側のMCPサーバーと比べたいときは、Vercel MCPサーバーの使い方とNetlify MCPサーバーの使い方が参考になります。

接続でつまずきやすい事例

GitHubのissueには、クライアントごとに症状が出た事例があります。

Copilot CLIでは、mcp.cloudflare.comの認証と初期化までは進みます。その後MCP error -32603: Subscription limit reachedでツールが読み込まれず、再認証しても同じ結果だと報告されています(cloudflare/mcp#249)。原因はCode Modeのサーバーがtools.listChangedを宣言しながらsubscriptions/listenを拒否していたことで、メンテナーがサーバー側の不具合と確認しています。修正のプルリクエストcloudflare/mcp#250がマージされ、issueはクローズされました。

ChatGPT用のCloudflareプラグインでは、OAuthが成功しcloudflare-apiのMCPも表示されます。それでもツールが1つも公開されないという報告があります(mcp-server-cloudflare#503)。こちらはオープンのままです。

まとめ — 最初の接続を決める基準

最初の接続はOAuthで足ります。トークンの種類と置き場所を決める必要が出るのは、CIなどブラウザーを使えない環境へ移すときです。