このガイドでは、Codexに接続する価値のある10のMCPサーバーと、他のリストによく登場するが含めるべきでない3つのサーバーを取り上げます。最初はBright Data MCPで、Codex単独では埋められないギャップを埋めます：自己防御するページからライブウェブを読み取ることです。以下を学べます：
- 2026年のCodexにおけるMCPサポートの実際の動作、変更点、および多くのガイドが今も間違えていること。
- 各サーバーの正確なTOMLとともに、その場所を勝ち取った10のサーバー。
- 各サーバーが何か作業を行う前にかかるコスト。
- スキップすべき人気サーバーと、そのうち2つが単なる好みではなくセキュリティ上の問題である理由。
方法論についての注記です。このカテゴリのほとんどのリストはその点が曖昧だからです。ここに掲載したすべてのベンダーの認証情報を取得できたわけではないため、このガイドは10件すべてをエンドツーエンドで実行したとは主張しません。以下のすべての設定ブロックはベンダー自身のドキュメントまたはリポジトリから取得したもので、ツール数は実行時のtools/list結果ではなくドキュメント記載の数であり、Codex向けの手順をまったく公開していないベンダーについてはその旨を明記しています。
10のサーバーを一目で確認
| # | サーバー | Codexへの追加機能 | トランスポート |
|---|---|---|---|
| 1 | Bright Data MCP | アンブロッキングスクレイピング、マルチエンジン検索、100以上のプラットフォームからの構造化データ | リモートHTTP |
| 2 | Context7 | 2つのツールのコストでバージョン正確なライブラリドキュメント | 両方 |
| 3 | GitHub MCP Server | Issue、プルリクエスト、Actions、コード検索 | 両方 |
| 4 | Chrome DevTools MCP | 実際のブラウザからのパフォーマンストレース、コンソール、ネットワーク | stdio |
| 5 | Serena | 言語サーバー経由のシンボルレベルのナビゲーションとリファクタリング | stdio |
| 6 | Sentry | スタックトレースとともに本番環境で実際に壊れたもの | リモートHTTP |
| 7 | Postgres MCP Pro | クエリプラン、インデックスチューニング、ワークロード分析 | stdio |
| 8 | Playwright | アクセシビリティツリーを通じたブラウザの操作 | stdio |
| 9 | Figma | スクリーンショットの代わりにデザインコンテキスト | リモートHTTP |
| 10 | Linear | コピーアンドペーストなしのチケット | リモートHTTP |
2026年のCodexにおけるMCPサポートの実態
まずここから始めましょう。このトピックで現在上位に表示されているガイドの多くは、2025年以降存在しないバージョンのCodexを説明しているからです。よく見かける主張は、Codexはstdioのみを話し、リモートMCPサーバーに接続できないというものです。それは約5週間だけ真実でした。Streamable HTTPサポートは2025年10月3日のCodex 0.44.0でリリースされ、もともとゲートしていたexperimental_use_rmcp_clientフラグはその年の12月の0.77.0で完全に削除されました。そのフラグを設定するよう指示している記事はno-opを説明しており、いくつかのベンダーのドキュメントページも追いついていません。
Codexが今日サポートするのはstdioとStreamable HTTPで、ベアラートークン、Client ID Metadata DocumentsとDynamic Client Registrationを含む完全なMCP OAuth、および信頼できるファーストパーティサーバー向けのChatGPTセッション認証です。同様に知っておく価値があるのは、サポートしていないもの：SSEトランスポートもWebSocketトランスポートもありません。SSEエンドポイントのみを公開するサーバーには前面にstdioブリッジが必要で、これがClaude Codeのチュートリアルからコピーした設定がCodexで失敗する最も一般的な理由です。
サーバーは~/.codex/config.tomlの[mcp_servers.<name>]の下、またはCodexが信頼できるプロジェクトのみで読み込むプロジェクトレベルの.codex/config.tomlに置きます。1つのファイルがCLI、IDE拡張機能、ChatGPTデスクトップアプリを提供します。トランスポートは宣言ではなく推論されます：サーバーにcommandを与えるとstdioで実行され、urlを与えるとHTTPで実行されます。設定するtypeフィールドはありません。
# stdio
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
# remote HTTP, token from the environment
[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"CLIはTOMLを手動で編集せずに同じ作業をカバーします。codex mcp add <name> -- <command>でstdioサーバーを登録し、codex mcp add <name> --url <url>でリモートサーバーを登録し、codex mcp login <name>でOAuthフローを実行します。セッション内で/mcpを実行すると実際に接続されたものが一覧表示され、サーバーが何もしていないように見えるときに最初に確認すべきものです。
追加するすべてのサーバーは作業前にコストがかかる
これが機能するCodexのセットアップと遅いものを分ける部分であり、他のリストにはほぼ完全に欠けています。Codexはセッションが開くと、モデルがそのツールを呼び出すかどうかに関わらず、有効なすべてのMCPサーバーを起動します。2026年9月に提出されたOpenAIのIssueはこれを明確に述べています：Codexはローカルセッションが開かれると有効なすべてのMCPサーバーを初期化して起動し、そのサーバーのツールが使用されない場合でも同様です。10個のサーバーは、すべてのセッション開始時に10個のプロセスまたはハンドシェイクを意味し、それぞれのツール定義がセッション全体のコンテキストを占有します。
ツール数は計算を明確にします。公式GitHubサーバーは約88のツールをドキュメント化し、Playwrightは約71、Chrome DevToolsは57、Notionは35です。これら4つを一緒にインストールすると、プロンプトを書く前にモデルは約250のツール定義から選択することになります。Codexには、ほとんどのガイドが言及しない3つのレバーがあり、それらが有用なサーバーとコストのかかるものの違いです。
[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/"
# trim the surface to the toolsets you actually use
enabled_tools = ["search_code", "get_pull_request", "list_issues"]
# reads run unattended, writes stop and ask
default_tools_approval_mode = "writes"
# a chatty tool cannot blow up the context window
[mcp_servers.github.tools.search_code]
output_token_limit = 25000enabled_toolsは許可リストで、disabled_toolsはその後に適用される拒否リストです。default_tools_approval_modeはauto、prompt、writesまたはapproveを取り、writesはほとんどの人が実際に求める設定です：読み取り専用ツールは無人で実行され、状態を変更するものは停止して確認を求めます。tools.<tool>.output_token_limitは1つのツールが返せるものを制限します。Figma自身のドキュメントには、デザインコンテキスト呼び出しが351,000トークン以上を返すと記録されており、Claude Codeが環境変数でそれに答えるのに対し、Codexはここでツールごとに答えます。
これらより先に2つのデフォルトが問題になります。Codexはサーバーの起動に10秒、ツール呼び出しごとに60秒を許可します。npxまたはuvxでインストールされたサーバーは、コールドキャッシュでは通常それ以上かかり、失敗は静かです：セッションは1つのサーバーからツールが0件と報告して続行します。r/codexのある開発者は2025年11月にWindows上でSerena、Context7、Playwrightを試した後、この経験を正確に描写しました：インストールガイドはconfig.tomlを開いてスニペットを追加するだけのように見せており、何か基本的なことを見逃したと思わせます。通常見逃しているのはstartup_timeout_secだけです。
Codexサンドボックスがカバーしないもの
Codexにはサンドボックスとネットワーク許可リストがあり、両方が接続するサーバーにも適用されると思いがちです。そうではありません。設定リファレンスは複数の箇所でこれを明確に述べています：ネットワークプロキシ機能はウェブ検索、アプリ、MCPやその他のホストツールをフィルタリングせず、実験的なネットワークドメインリストもウェブ検索、アプリ、MCPサーバーを制限しません。ドメイン許可リストはエージェント自身のシェルが到達できるものを制約します。MCPサーバーがエージェントの代わりに到達するものは制約しません。
これはMCPに反対する議論ではありません。各サーバーを独自の認証情報と影響範囲を持つものとして扱うべきという議論であり、上記の承認と許可リスト設定が他の場所よりもCodexでより重要な理由です。また、広く推奨されている2つのサーバーがランキングではなくこのガイドの末尾のインストール禁止セクションにある理由でもあります。
1. Bright Data MCP：ライブウェブをアンブロック
CodexはすでにURLを読み取ることができ、保護されていないドキュメントページではそれで十分です。ギャップは、ほとんどの商業的な作業が実際にターゲットとするサイトで開きます。小売業者、マーケットプレイス、求人ボード、ソーシャルプラットフォームは、ブラウザに提供するページとは異なるページを自動化クライアントに提供し、失敗はほとんど明確なエラーではありません。返され、パースされ、間違ったものを含むページであり、これは結果を自信を持って述べるエージェントにとって最悪の結果です。
Bright Data MCPはウェブデータスタック全体を1つのエンドポイントの背後に置きます：複数エンジンにわたる検索、ボット管理の背後にあるページからきれいなMarkdownを返すスクレイピング、100以上のプラットフォームからの構造化抽出、そしてページがインタラクションにのみ応答する場合のブラウザ自動化です。合計69のツールを公開しており、enabled_toolsでのトリミングが5分の価値があるサーバーの1つです。すべてのBright Dataアカウントには、月5,000リクエストがコストなしでカード不要で含まれており、実際のタスクで適切に評価するのに十分です。
[mcp_servers.brightdata]
url = "https://mcp.brightdata.com/mcp?pro=1"
bearer_token_env_var = "BRIGHTDATA_API_KEY"
startup_timeout_sec = 20
tool_timeout_sec = 120
default_tools_approval_mode = "auto"これらの設定のうち2つは意図的なものです。防御されたページのスクレイピングはCodexのデフォルトの60秒より長くかかることがあるため、tool_timeout_secを上げています。そして、ここのすべてのツールはシステムへの書き込みではなく、パブリックウェブへの読み取りなので、auto承認は安全であり、ブラウザ系サーバーを使うのを面倒にする呼び出しごとのプロンプト摩擦を取り除きます。ホストサーバーの場合はインストール不要です。stdioで実行したい場合のローカルパッケージは@brightdata/mcpです。
このセットアップの詳細版、実際のタスクをエンドツーエンドで実行する方法を含む場合は、CodexをBright Dataに接続するガイドをご覧ください。
2. Context7：インストールされているバージョンに一致するドキュメント
コーディングエージェントが午後を無駄にする最も一般的な方法は、2マイナーバージョン前に名前が変更されたAPIを自信を持って使用することです。Context7はライブラリを特定のバージョンに解決し、そのドキュメントを返します。これをまさに2つのツールで行います。代替が88のリストでは、その比率が全ての主張です。ここで最も安価で有用なサーバーであり、最初に追加すべきものです。
codex mcp add context7 -- npx -y @upstash/context7-mcp匿名で実行され、APIキーでレート制限が上がり、月1,000コールの無料ティアがあります。正直な注意点として、品質はライブラリによって異なります：開発者フォーラムで見つかる批判は、あまり人気のないパッケージについては同じ薄いMarkdownのスライスを繰り返し返すというものです。広く使用されているフレームワークでは、モデルのトレーニングカットオフより確実に優れており、それが重要なケースです。
3. GitHub MCPサーバー：仕事のもう半分
Codexはすでにディスク上のリポジトリの編集が得意です。見えないのはコードの周りにあるすべてのもの：失敗したActionsの実行、関数が奇妙に見える理由を説明するレビューコメント、実際の要件を説明するリンクされたIssueです。公式GitHubサーバーはそれを埋め、22のツールセットにわたる約88のツールがあるため、このリストでツールバジェットの管理が本当に必要な唯一のサーバーです。
GitHubはそれを行うコントロールを提供します：必要なグループのみをロードするための--toolsetsまたはGITHUB_TOOLSETS環境変数、個別選択のための--tools、そして書き込みアクセスを完全に削除する--read-onlyです。読み取り専用から始めてください。Invariant Labsがパブリックイシューからプライベートリポジトリへのプロンプトインジェクションルートを実証しており、GitHubは緩和策を出荷していますが、自身のドキュメントはロックダウンモードが認可の境界ではないと慎重に述べています。知っておく価値もあります：多くの開発者はgh CLIが同じカバレッジをより安価に提供することを発見しています。Codexはすでにシェルコマンドを実行できるからです。
4. Chrome DevTools MCP：ページが壊れている理由、動作ではなく
これはOpenAI自身のCodexドキュメントに登場しますが、他のほぼどこにも登場せず、このリストで最も過小評価されているサーバーとなっています。Playwrightとの区別は正確に理解する価値があります。競合ではないからです。Playwrightはアプリケーションを操作します：これをクリック、あれを入力、他を確認。Chrome DevTools MCPはアプリケーションを説明します：パフォーマンストレース、ソースマップされたコンソールエラー、ネットワークウォーターフォール、メモリを追跡するための13のヒープ検査ツール。Codexが動作するが遅いコードを書いた場合、これがその理由を教えるサーバーです。
57のツールをドキュメント化しており、--slimでかなり削減されます。定義上Chrome専用です。使用統計はデフォルトでGoogleに送信されるため、環境でそれが問題になる場合は--no-usage-statisticsを追加してください。
[mcp_servers.chrome_devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--slim", "--isolated", "--no-usage-statistics"]
startup_timeout_sec = 30実際には--isolatedフラグは任意ではありません。ブラウザ操作サーバーは、ブラウザプロファイルがすでに使用中というエラーでCodex下で失敗し、フルファイルシステムアクセスが付与されていても発生します。各セッションを使い捨てプロファイルに対して実行することが修正策であり、同じ理由で以下のPlaywrightにも適用されます。
5. Serena：テキスト検索ではなくシンボルレベルの編集
SerenaはMCPの背後に言語サーバーを置くため、エージェントは文字列ではなくシンボルで作業します。この関数へのすべての参照を見つける、プロジェクト全体でこのクラスの名前を変更する、ファイル全体ではなくこのメソッドの本体のみを読み取る。大規模なコードベースでは、これはgrepとは質の異なる操作であり、同じ答えに到達するために劇的に少ないトークンを消費します。
Codex固有の理由でここに載っています：Serenaは--context=codexモードを出荷しており、Codexがすでに持っているツールを複製する自身のツールを無効にします。これはこのガイドの残りが主張するコンテキスト衛生を、あなたに任せるのではなくベンダーが行うものです。
[mcp_servers.serena]
command = "uvx"
args = ["--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server", "--context", "codex"]
startup_timeout_sec = 60タイムアウトは意図的に余裕を持たせています。Serenaは初回実行時にプロジェクトをインデックス化し、10秒のデフォルトに引っかかる可能性が最も高いサーバーです。
6. Sentry：本番環境で実際に壊れたもの
スタックトレースをプロンプトに貼り付けることは機能します。エージェントがリリース、ブレッドクラム、頻度とともにIssueを自分でプルできると、より良く機能し、あなたがボトルネックになることを防ぎます。SentryのリモートサーバーはシンプルなStreamable HTTPとOAuthなので、codex mcp login sentryがセットアップ全体です。
他のリストが示唆していることとは異なる正確な点として：SentryのドキュメントにはClaude Code、Cursor、VS Codeのセットアップタブがありますが、Codex向けはありません。OpenAIはCodexドキュメントでそれを推奨しており、トランスポートは完全にサポートされているため機能しますが、Sentryの誰もCodexの手順を書いておらず、コピーアンドペーストのパスを期待すべきではありません。エンドポイントを/mcp/{org}/{project}にスコープすると、検出ツールが隠れてサーフェスが小さく保たれます。
7. Postgres MCP Pro：接続だけでなくクエリプラン
ほとんどのデータベースMCPサーバーはエージェントにSQLを実行する方法を提供します。これはSQLについて推論する方法を提供します。クエリプランを説明し、pg_stat_statementsに対してワークロードを分析して実際にコストがかかっているクエリを見つけ、エージェントがビルドする前にアイデアをテストできるよう仮想インデックスをシミュレートします。9つのツールでそれを行い、stdioで実行されるため、このリストのすべてのリモートOAuth失敗モードを回避します。
2つの正直な注意点があります。メンテナーはCodexの手順を公開していません。2026年1月以来オープンなリクエストが未回答のままですが、stdioブロックは自分で書くのは簡単です。そして、重要なものに向ける前に、--access-mode=restrictedでレプリカに向けてください。
8. Playwright：アプリケーションを操作する
Playwright MCPはピクセルではなくアクセシビリティツリーを通じてブラウザを操作し、スクリーンショットベースの自動化では得られない決定論的な動作を実現し、Chromium、Firefox、WebKitで動作します。エンドツーエンドテストと報告されたバグの再現には明らかなツールです。
8位にランクされているのは珍しいシグナルのためです：MicrosoftのREADMEは現在、コーディングエージェントをMCPサーバーから遠ざけ、Playwright CLIとスキルをよりトークン効率が高く高スループットエージェントに適したものとして推奨し、MCPを特殊なエージェントループ向けに位置付けています。ベンダーが自身のサーバーがユースケースに合わない形だと言う場合、それはランキングに属します。--isolatedを追加し、承認の摩擦を予期してください：コミュニティの支持が大きいオープンなIssueが、approval_policy = "never"でも毎回プロンプトが表示されると報告しており、サーバーのdefault_tools_approval_mode = "auto"で解決されます。
9. Figma：スクリーンショットの代わりにデザインコンテキスト
エージェントにPNGを渡してコンポーネントを求めると、おおよそ正しいものが生成されます。FigmaサーバーはPNGの代わりに変数、トークン、レイアウト制約、コンポーネント構造を渡し、出力が近似ではなくなります。OAuthを使用したリモートHTTP経由で29のツールをドキュメント化しています。
制約は実在し、計画を立てる前に確認する価値があります。DevまたはFullシートが必要です。Viewシートは月20回のツール呼び出しを取得します。Figmaは自身のカタログにあるクライアントへの接続を制限しており、Codexは現在そのリストにありますが、リストです。そして、このサーバーが最もoutput_token_limitを必要とします。Figmaのドキュメントには、単一のデザインコンテキストレスポンスが351,000トークン以上を返すと記録されています。
10. Linear：コピーアンドペーストなしのチケット
小さな定常的な負担を取り除く1行のセットアップ：codex mcp add linear --url https://mcp.linear.app/mcp、次にcodex mcp login linear。エージェントはIssue、受け入れ基準、コメントスレッドを直接読み取り、完了したらチケットを移動できます。
これはLinearのファーストパーティCodex統合とは異なることに注意してください。それは反対方向に実行されます。IssueでCodexに言及してクラウドタスクをディスパッチします。MCPサーバーはCLIまたはIDE拡張機能でのローカル作業用です。LinearのドキュメントでCodexがexperimental_use_rmcp_clientフラグに言及しているのを見た場合、無視してください。そのフラグは2025年12月以降存在しません。
インストールすべきでないもの
これら3つはほとんどの同様のリストに登場します。そのうち2つはセキュリティ上の問題で、1つは単に冗長であり、省くことでCodexのセットアップが悪化するのではなく改善されます。
- Filesystem MCP。 Codexにはすでに独自の承認システムによって管理されるネイティブファイルツールがあります。このサーバーを追加するとそれらが複製され、そのシステム外のプロセスにファイルアクセスが移動するため、より多くではなく少ない監視が得られます。また、ディスクを読み取るコンポーネントには望ましくないCVE-2025-53109とCVE-2025-53110のようなサンドボックスエスケープ脆弱性の履歴があります。
- Slack。 公式サーバーはDynamic Client Registrationを拒否し、ディレクトリ公開または内部Slackアプリを期待するため、Codex CLIは事実上除外されます。古いnpmパッケージは非推奨でデータ流出の勧告があります。人気のあるコミュニティ代替はブラウザセッションクッキーで認証し、ワークスペースポリシーに違反する可能性が非常に高いです。
- コミュニティAtlassianサーバー。 リモートコード実行につながる任意ファイル書き込みのCVE-2026-27825（評価9.1）と、別のSSRFの問題を抱えています。AtlassianのオフィシャルRovoサーバーが存在し、これらの問題はありません。
接続して動作確認する
サーバーを1つずつ追加し、次を追加する前に各サーバーを確認してください。起動時の失敗は静かだからです。セッション内で/mcpを実行して実際に接続されたものを確認してください。設定されているがそのリストにないサーバーは、ロードされたのではなく失敗しています。サーバーがない場合は、まずstartup_timeout_secを上げてください。10秒はコールドなnpxまたはuvxのダウンロードには十分ではありません。ツールは表示されるがCodexが呼び出さない場合、それは壊れた設定ではなく既知の動作です：プロンプトでサーバーまたはツールを一度名前で指定すると、使い始めます。
人々が午後を費やすもう2つのことがあります。プロジェクトレベルの.codex/config.tomlは信頼できるプロジェクトのみで読み込まれるため、あるディレクトリで動作する設定が別のディレクトリでは静かに何もしないことがあります。プラグインマニフェストを通じてサーバーを設定する場合、そこのOAuthフィールドはキャメルケースですが、config.tomlのすべてはスネークケースです。
よくある質問
CodexはリモートMCPサーバーをサポートしていますか？
はい。Streamable HTTPは2025年10月3日のCodex 0.44.0でリリースされ、ベアラートークンとCIMDおよびDynamic Client Registrationを含む完全なOAuthをサポートしています。かつてゲートしていたexperimental_use_rmcp_clientフラグは2025年12月の0.77.0で削除されたため、今もそれを設定するよう指示しているガイドは古いです。CodexはSSEまたはWebSocketトランスポートをサポートしていません。
CodexにはMCPサーバーをいくつインストールすべきですか？
希望より少なくすべきです。Codexはセッションが開くと有効なサーバーをすべて起動します。ツールが使用されるかどうかに関わらず、各サーバーのツール定義はセッション全体のコンテキストを消費します。ツールリストを絞った4つのサーバーは、そのままインストールした10個を上回るパフォーマンスを発揮します。enabled_toolsで各サーバーを絞り込み、時折しか必要ないサーバーにはenabled = falseを使用してください。
CodexでMCPサーバーにツールが表示されないのはなぜですか？
ほぼ常に10秒の起動タイムアウトが原因です。npxまたはuvx経由でインストールされたサーバーはコールドキャッシュでそれ以上かかることがあり、Codexはエラーではなくツールが0件と報告します。startup_timeout_secを30または60に上げて再試行してください。ブラウザ系サーバーの場合は--isolatedを追加してください。これにより、フルアクセスが付与されていても発生するプロファイルロックの失敗が解決されます。
CodexのサンドボックスはMCPサーバーのアクセスを制限しますか？
いいえ、これは広く誤解されています。Codexの設定リファレンスには、ネットワークプロキシはMCPやその他のホストツールをフィルタリングせず、実験的なネットワークドメインリストもMCPサーバーを制限しないと明記されています。ドメイン許可リストはエージェント自身のシェルを管理するものであり、接続されたサーバーが代わりにフェッチするものを管理するものではありません。すべてのサーバーが独自の認証情報と影響範囲を持つものとして扱ってください。
Codexはボットをブロックするウェブサイトをスクレイピングできますか？
単独ではできません。CodexはURLをフェッチできますが、ボット管理を持つサイトは自動化クライアントに異なるページを返し、失敗はエラーではなく通常サイレントです。Bright Data MCPは1つのエンドポイントの背後で、100以上のプラットフォームからのアンブロッキング、マルチエンジン検索、構造化抽出を処理し、月5,000リクエストが無料でカード不要です。
