Codex 向けの DynamoDB MCP

Codex は、呼び出せる MCP サーバーを与えれば、あなたの DynamoDB のスキーマを読み取り、テーブルにクエリを実行できます。

Codex は MCP を TOML で設定し、そのテーブル名は snake_case の mcp_servers です。 Cursor が使う mcpServers キーではありません。サーバーがいつまでも現れない原因は、たいてい camelCase のキーです。

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

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

DynoTable を通して、Codex はあなたの実際のスキーマ（テーブル、キースキーマ、インデックス、アイテムに現れる属性）を読み取り、ライブのデータに対して PartiQL の SELECT、 GetItem、アイテム数のカウントを実行します。

集計は Workbench SQL で行い、編集はステージングエリアにステージングしてあなたがコミットするのを待ちます。生の Query や Scan のツールはなく、PartiQL の結果は小さなサンプルに制限されて返ります。

始める前に

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

プロファイルの MCP セクションから、endpoint と実際のポートをコピーしてください。

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

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

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

動くかどうかを決めるのは 3 つのポイントです。

テーブル名は snake_case の mcp_servers です。 Codex はそのテーブルからしかサーバーを読み取らないので、[mcpServers.dynotable-prod] というテーブルはサーバーを一切登録しません。設定が正しく見えるのに Codex が何も認識しないなら、まずここを確認してください。

トランスポートを選ぶのは url です。 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 = 300

tool_timeout_sec のデフォルトは、ツール呼び出し1回あたり 60 秒です。大きなテーブルに対する集計はそれより長くかかることがあり、実際には遅いだけの読み取りがツールのエラーとして表面化するので、この値を上げてください。

startup_timeout_sec（デフォルト 10 秒）は最初の接続を対象にします。DynoTable がまだ起動中なのに Codex があきらめてしまうなら、上げてください。

enabled = false は、ブロックを削除せずにサーバーを一時停止します。

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

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

ログインして接続を承認する

DynoTable の endpoint は OAuth で保護されています。config.toml を編集したら Codex を再起動し、次を実行します。

codex mcp login dynotable-prod

ブラウザが開き、DynoTable がクライアント名を示す同意プロンプトを表示するはずです。 Codex は streamable HTTP サーバー向けの OAuth を文書化していますが、DynoTable に対するこのログインはまだエンドツーエンドで実行されていません。失敗したら、代わりに Claude Code を通して接続してください。まずは読み取り専用 を許可しましょう。読み取りとステージ と フルアクセス は概要のスコープのセクションで扱います。

許可はその場で狭められません。MCP ペインの失効はクライアントの次のリクエストをブロックし、別のスコープにするには失効させてから再接続を承認することになります。

有効なプランかトライアルがなければ、DynoTable はすべての接続を読み取り専用に制限し、 Workbench SQL のツールを隠します。

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

Codex は config.toml を起動時に読み込むので、セッションの途中での編集は何も変えません。再起動とログインの後、codex mcp list（または TUI で /mcp）を実行して、有効なサーバーを確認します。そのうえで、あなたのデータにしか答えられないことを尋ねます。「このプロファイルのテーブルと、それぞれのキースキーマを一覧してください。」

曖昧で一般論的な答えが返ってきたら、ツールは読み込まれていません。

データについて質問する前にキースキーマを尋ねてください。そうすればエージェントはパーティションキーを把握し、その読み取りは Scan ではなく Query として実行されます。数字とその他の制御はコストのセクションにあります。

なぜ Codex に AWS 認証情報を渡さないのか？

AWS キーを保持するサーバーは、そのキーの IAM 権限をフルにエージェントのプロセスへ渡します。

MCP のツール結果は信頼できない入力です。行、ドキュメント、取得したページには命令が含まれることがあります。それがプロンプトインジェクションであり、書き込み可能な認証情報に対しては、あなたのテーブルに作用しえます。

DynoTable を経由すれば、エージェントは MCP 越しにキーを受け取らず、書き込みツールもないので、読み取りとステージで誘導されたエージェントにできるのは、あなたがレビューする差分をステージングすることだけです。全体のモデルは概要で扱います。

DynoTable があなたの認証情報を Codex に渡すことはありませんが、認証情報は ~/.aws に残っており、Codex はあなたのユーザーとしてシェルコマンドを実行します。Codex のパーミッションプロファイル（ベータ）を使えば、Codex が実行するコマンドによる ~/.aws の読み取りを拒否できます。 OpenAI のパーミッションのドキュメントを参照してください。

DynoTable を使わない場合: 読み取り専用のプロファイル

別の DynamoDB MCP サーバーには、キーではなく読み取り専用の AWS プロファイルを使います。マネージドポリシー AmazonDynamoDBReadOnlyAccess を持つロールです（プロファイルのブロックは概要にあります）。その名前を stdio サーバーに渡します。

[mcp_servers.dynamodb-ro]
command = "<server command>"
args = ["<server args>"]

[mcp_servers.dynamodb-ro.env]
AWS_PROFILE = "dynamodb-readonly"

設定が保持するのはシークレットではなくプロファイル名であり、エージェントが試みる書き込みはすべてアクセス拒否のエラーで失敗します。

トラブルシューティング

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

Codex がサーバーの設定エラーを報告する。 url と同じテーブルに command キーがないか確認してください。両者は排他的です。enabled が false になっていないかも確認しましょう。

ログインがアクセス拒否で終わる。 DynoTable でプロファイルが公開されていないか、MCP サーバーがオフか、同意プロンプトで拒否しています。プロファイルを公開し、 codex mcp login dynotable-prod をもう一度実行してください。

接続はできるが、クエリでタイムアウトする。 tool_timeout_sec を上げてください。

ステージングできない。 接続が読み取り専用で承認されたか、プランが失効して DynoTable が読み取り専用に制限しています。

Workbench SQL や集計がない。 プランかトライアルが失効しています。読み取り専用の許可でも Workbench SQL は使えます。

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

よくある質問

Codex を DynamoDB に接続するには？

DynoTable で使いたいプロファイルを公開し（MCP 経由で公開）、設定 → MCP でサーバーをオンにします。そのプロファイルの url を書いた [mcp_servers.dynotable-prod] テーブルを ~/.codex/config.toml に追加します。

Codex を再起動し、codex mcp login dynotable-prod を実行して、DynoTable で接続を承認してください。

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

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

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

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

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

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

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

DynoTable を通しては、直接には書き込めません。変更をステージングでき、それはあなたがアプリでコミットしたときにだけ書き込まれます。書き込み可能な AWS 認証情報を保持するサーバーは直接書き込めますが、読み取り専用の IAM プロファイルならその書き込みは失敗します。サーバーの比較は概要にあります。