Codex 向けの DynamoDB MCP

Codex は、呼び出せる MCP サーバーを与えれば、あなたの DynamoDB のスキーマを読み取り、テーブルにクエリを実行できます。Codex は MCP を JSON ではなく TOML で設定します。そして、ほとんどのセットアップが行き詰まるのはこの違いです — TOML のテーブル名は snake_case の mcp_servers であり、他のあらゆるクライアントが使う mcpServers キーではありません。

このガイドでは、設定そのもの、トランスポートのルール、設定しておく価値のあるタイムアウト、そして AWS 認証情報をエージェントの環境に置かずに接続する方法を扱います。選択肢の比較については、DynamoDB MCP サーバーの概要を参照してください。

接続すると Codex に何ができるか

実際のスキーマの読み取り — テーブル、キースキーマ、インデックス、そしてアイテムに実際に現れる属性。
クエリの実行 — ライブのデータに対する Query、Scan、GetItem、PartiQL。自分自身の前提を検証できます。
集計 — DynamoDB がネイティブには実行できない件数とグループ化。
編集の提案 — あなたのテーブルにではなく、レビュー可能なステージングエリアへ。

始める前に

DynoTable をインストールする — ダウンロードして、Codex に見せたい AWS プロファイルを追加します。
MCP サーバーをオンにする — 設定 → MCP サーバー。デフォルトではオフで、 127.0.0.1 にバインドされます。
プロファイルを公開する — そのプロファイルの MCP セクション → MCP 経由で公開。接続はそのプロファイルの認証情報とリージョンに厳密に固定されます。

そのペインから endpoint と実際のポートをコピーしてください。

`config.toml` にサーバーを追加する

Codex は MCP サーバーを ~/.codex/config.toml から読み取ります。

[mcp_servers.dynotable-prod]
url = "http://127.0.0.1:<port>/mcp?profile=prod"

エントリはこれだけです。動くかどうかを決めるのは 3 つのポイントです。

テーブル名は mcp_servers — snake_case です。 mcpServers ではありません。Codex は認識できないテーブルを黙って無視するため、camelCase のキーはエラーも出さず、サーバーも生みません。設定が正しく見えるのに Codex が何も認識しないなら、まずここを確認してください。

トランスポートを選ぶのは url です。 Codex はどのキーが存在するかでトランスポートを決めます。command なら stdio、url なら streamable HTTP です。両者は排他的で — url、 bearer_token_env_var、http_headers は、command を持つテーブルに同居できません。 DynoTable は HTTP なので、書くのは url だけです。

?profile=prod はヒントであって、認可ではありません。 DynoTable の承認プロンプトでプロファイルを事前選択するだけで、接続の承認はやはりアプリ内で行います。

設定しておく価値のある任意のオプション

[mcp_servers.dynotable-prod]
url = "http://127.0.0.1:<port>/mcp?profile=prod"
startup_timeout_sec = 30
tool_timeout_sec = 60
enabled = true

DynamoDB で効いてくるのは tool_timeout_sec です。大きなテーブルに対する Scan は短いデフォルト値を超えることがあり、実際には単に遅いだけのクエリが、ツールのエラーとして表面化します。us-east-1 のオンデマンドでは、そのスキャンは評価したアイテムごとに結果整合性で 4 KB あたり 0.5 RCU を課金します — 1 KB の行が入った 100 MB のテーブルなら、フィルターが効く前におよそ 25,000 RCU です。大きなテーブルで Codex がタイムアウトを報告したら、接続が壊れていると決めつける前に、この値を上げたうえで料金計算ツールでその読み取りの単価を確かめてください。

enabled = false は、ブロックを削除せずにサーバーを一時停止しておく、きれいな方法です。

プロジェクトスコープの設定

Codex は信頼済みのプロジェクトについて、プロジェクトディレクトリの .codex/config.toml も読み取ります。リポジトリを共有しているなら、ループバックのサーバーをそこに置かないでください — ポートはマシンごとに異なり、チームメイトは DynoTable を動かしていません。これは ~/.codex/config.toml に留めましょう。

接続を承認する

初回接続時に、DynoTable が接続してくるクライアントの名前を示し、スコープを求める同意プロンプトを表示します。

読み取り専用 — スキーマ、クエリ、アイテムの読み取り。変更はなし。
読み取り＆ステージング — 加えて、あなたが確認するための変更のステージング。直接の書き込みは決してありません。
フルアクセス — 加えて、ビューを開く、フィルター、エクスポート。書き込みはやはりステージングを経由します。

まずは読み取り専用から始めましょう。スコープは呼び出しのたびに再チェックされるため、狭める変更は即座に効きます。

実際に読み込まれたかを確認する

config.toml を編集したら Codex を再起動してください — ファイルは起動時に読み込まれるため、セッションの途中での編集は何も変えません。そのうえで、あなたのデータにしか答えられないことを尋ねます。「このプロファイルのテーブルと、それぞれのキースキーマを一覧してください。」

曖昧で一般論的な答えが返ってきたら、ツールは読み込まれていません。下のチェックリストを順に潰してください。

なぜ Codex に AWS 認証情報を渡してはいけないのか?

標準的なパターン — AWS のアクセスキーとシークレットを保持する MCP サーバー — は、エージェントのプロセスにそれらのキーの IAM 権限をフルに渡してしまい、DynamoDB 固有のレビューステップは存在しません。

リスクは悪意あるモデルではありません。MCP のツール結果が信頼できない入力であることです。行、ドキュメント、取得したページには命令が含まれうります。それがプロンプトインジェクションであり、あなたのキーを保持する書き込み可能なサーバーに対しては、そのままあなたのテーブルに作用します。

DynoTable を経由すれば:

あなたの AWS 認証情報がエージェントに届くことは決してありません。 DynoTable がプロファイルを保持して呼び出しを行うため、Codex のプロセス内のどこからもキーは読み取れません。
直接書き込むツールは存在しません。 ゲートされているのではなく — _そもそも無い_のです。読み取り＆ステージングでの最悪の結末は、あなたがレビューする差分カードが 1 枚できることです。

トラブルシューティング

Codex がサーバーをまったく認識しない。 順に確認します。テーブル名は mcp_servers（snake_case）ですか、編集後に Codex を再起動しましたか、そして TOML は妥当ですか?

サーバーは定義されているのに起動しない。 url と同じテーブルに command キーがないか確認してください — 両者は排他的です。enabled が false になっていないかも確認しましょう。

接続はできるが、クエリでタイムアウトする。 tool_timeout_sec を上げてください。大きな Scan は遅いのであって、壊れているのではありません。

接続はできたが、ツールがゼロ。 DynoTable でプロファイルが 1 つも公開されていないか、要求している内容を何も公開しないスコープで接続が承認されています。

編集しても DynamoDB が変わらない。 想定どおりです — ステージングされています。ステージングエリアからコミットしてください。

よくある質問

Codex を DynamoDB に接続するには?

DynoTable をインストールし、設定 → MCP サーバーでサーバーをオンにし、Codex に見せたい AWS プロファイルを公開してから、~/.codex/config.toml に [mcp_servers.dynotable] テーブルを追加し、そのペインに表示された endpoint を指す url を書きます。Codex を再起動し、希望するスコープで DynoTable 内の接続を承認してください。

Codex は MCP サーバーをどこで設定するのか?

~/.codex/config.toml で、サーバーごとに [mcp_servers.dynotable] という 1 つの TOML テーブルを使います。Codex は信頼済みのプロジェクトディレクトリにある .codex/config.toml も読み取りますが、ポートはマシンごとに異なるため、ループバックのサーバーはホームディレクトリのファイルに置くべきです。

config.toml に書いた MCP サーバーを Codex が認識しないのはなぜか?

最も多い原因はテーブル名です。mcpServers ではなく、snake_case の mcp_servers でなければなりません。Codex は認識できないテーブルをエラーなしに無視します。次に多い 2 つの原因は、ファイルを編集して Codex を再起動していないことと、command を持つテーブルに url キーを置いていることです。

リモートの MCP サーバーでは url と command のどちらを使うのか?

DynoTable のような streamable HTTP のサーバーには url を使います。Codex はどちらのキーが存在するかでトランスポートを選び — command なら stdio、url なら HTTP — 両者は同じテーブルに書けません。

Codex は私の DynamoDB テーブルに書き込めるか?

DynoTable を経由する限り、直接には書き込めません — 呼び出せるコミット用のツールが存在しないからです。読み取り＆ステージングまたはフルアクセスでは、エージェントは変更をステージングし、それはアプリ内でレビュー可能な差分として現れ、あなたがコミットしたときにのみ書き込まれます。書き込み可能な AWS キーを保持するコミュニティの MCP サーバーは、直接書き込めます。