Cursor 向けの DynamoDB MCP

Cursor は、呼び出せる MCP サーバーを与えれば、エディタからあなたの DynamoDB テーブルにクエリを実行できます — スキーマを読み取り、実際のデータに対して Query を実行し、編集を提案する、といったことです。このガイドでは、mcp.json の設定、プロジェクトとグローバルの選択、ツールが読み込まれたかを確認する方法、そして AWS のアクセスキーをリポジトリ内の設定ファイルに置いてしまうデフォルトのパターンを避ける方法を扱います。

ローカルの MCP サーバーとして動作する DynoTable に Cursor を向ければ、mcp.json にキーは一切入りません。それが AWS の公式サーバーやコミュニティの npm/PyPI サーバーとどう比べられるかは、 DynamoDB MCP サーバーの概要を参照してください。

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

実際のスキーマの読み取り — テーブル、キースキーマ、インデックス、そしてアイテムに実際に現れる属性。生成されるコードが推測ではなく、あなたのデータに一致するようになります。
コードを書きながらクエリを実行 — ライブのテーブルに対する Query、Scan、GetItem、 PartiQL。関数をあなたに渡す前に、自分の前提を確かめられます。
集計 — DynamoDB がネイティブには答えを持たない件数とグループ化。
編集の提案 — あなたのテーブルではなく、レビュー可能なステージングエリアに着地します。

エディタで動くエージェントにとって明らかな見返りは 1 つ目です。まずい DynamoDB コードの多くは、モデルがキースキーマをでっち上げることから生まれます。

始める前に

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

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

`mcp.json` にサーバーを追加する

Cursor は MCP サーバーを 2 つのファイルから読み取ります。そしてどちらを選ぶかは、今回はいつも以上に重要です。

プロジェクト内の .cursor/mcp.json — そのリポジトリにスコープされ、ignore しない限り コミットされます。
ホームディレクトリの ~/.cursor/mcp.json — グローバルで、すべてのプロジェクトに効き、決してコミットされません。

127.0.0.1 のサーバーには、グローバルのファイルを使います。

{
  "mcpServers": {
    "dynotable-prod": {
      "url": "http://127.0.0.1:<port>/mcp?profile=prod"
    }
  }
}

HTTP トランスポートを選ぶのは、command ではなく url が存在することです — DynoTable は streamable HTTP を話します。これは Cursor がリモートサーバーに推奨しているもので、サーバーが再起動しても自力で再接続します。

?profile=prod は、DynoTable の承認プロンプトでプロファイルを事前選択します。あくまでヒントであり、接続の承認はやはりアプリ内で行います。

本当に認証情報が必要なサーバーを配線する場合

Cursor は url と headers の両方で ${env:NAME} を展開します。そのため、token が必要なサーバーは、それをファイルに置く代わりに環境から読み取れます。

{
  "mcpServers": {
    "some-remote-server": {
      "url": "https://example.com/mcp",
      "headers": {"Authorization": "Bearer ${env:MY_SERVICE_TOKEN}"}
    }
  }
}

設定にシークレットが含まれてしまうあらゆる MCP サーバーで、この書き方を使ってください。生の AWS_SECRET_ACCESS_KEY を mcp.json に貼り付けることこそ、DynamoDB の認証情報が git の履歴に残ってしまう最も多い経路です。

Cursor で有効にして承認する

Cursor Settings → MCP（バージョンによっては Tools & Integrations）を開きます。サーバーがツール一覧とともに表示されるはずです。オフになっていればオンにしてください — Cursor は、あなたが確認するまで新しいサーバーを無効にしておきます。

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

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

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

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

MCP 設定のペインでは、アクティブなサーバーが自身のツールを一覧します。本当のシグナルはその一覧です — DynoTable 側でプロファイルが 1 つも公開されていなければ、サーバーが「接続済み」と表示されていても、何も公開されていないことがあります。

そのうえで、あなたのデータにしか答えられないことをエージェントに尋ねます。 「このプロファイルのテーブルと、それぞれのキースキーマを一覧してください。」 言葉を濁さずテーブルの内容から答えたなら、ツールは生きています。

エージェントが探索するときの読み取りコスト

エージェントはキースキーマを知らないと、既定で Scan に走ります。us-east-1 オンデマンドでは、調べたアイテムごとに結果整合性で 0.5 RCU / 4 KB が課金されます — 1 KB 行の 50 MB テーブルなら、1回のフルパスでおよそ 12,500 RCU です。プロファイルを 読み取り専用 で公開し、スキーマの質問から始め、エージェントが提案する広い読み取りは承認前に料金計算機で線速換算してください。

なぜ AWS キーを `mcp.json` に置いてはいけないのか?

そのファイルを読むエージェントが、信頼できないコンテンツも読むからです。MCP のツール結果 — 行、ドキュメント、取得したページ — には命令が含まれうります。それがプロンプトインジェクションであり、あなたの AWS キーを保持する書き込み可能なサーバーに対しては、そのままあなたのテーブルに作用します。

もう 1 つ、より地味でありながら、より頻繁に牙をむくリスクがあります。.cursor/mcp.json はプロジェクトのファイルであり、プロジェクトのファイルはコミットされます。そのファイルの中のキーは、あなたの git 履歴の中のキーです。

DynoTable を経由すれば、その両方を避けられます。

設定に認証情報が入らない。 ファイルが保持するのはループバックの URL だけです。AWS プロファイルは DynoTable が持ち、呼び出しも DynoTable が行うため、Cursor がキーを目にすることはありません。
直接書き込むツールがない。 ゲートされているのではなく — _そもそも無い_のです。読み取り＆ステージングでは、操作されたエージェントが達成できる最悪のことは、あなたがコミット前に読む差分カードが 1 枚できることだけです。

トラブルシューティング

サーバーが設定に現れない。 ファイルが違うか、JSON が不正です — Cursor はパースできないファイルを黙ってスキップします。JSON を検証し、編集したのが ~/.cursor/mcp.json であることを確認してください。

表示はされるが、赤い／切断されている。 DynoTable が起動していない、MCP サーバーがオフ、あるいはポートが変わっています。設定 → MCP サーバーから endpoint をコピーし直してください。

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

ツールは一覧に出るが、一度も使われない。 Agent モードにいないか、そのリクエストがツールを必要としませんでした。テーブル固有のことを尋ねてみてください。

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

よくある質問

Cursor を DynamoDB に接続するには?

DynoTable をインストールし、設定 → MCP サーバーでサーバーをオンにし、Cursor に見せたい AWS プロファイルを公開してから、その endpoint を ~/.cursor/mcp.json の mcpServers の下に url フィールドとして追加します。Cursor の MCP 設定でサーバーを有効にし、希望するスコープで DynoTable 内の接続を承認してください。

Cursor は MCP サーバーの設定をどこに保存するのか?

プロジェクトスコープのサーバーはプロジェクト内の .cursor/mcp.json、グローバルなものはホームディレクトリの ~/.cursor/mcp.json です。ループバックのサーバーにはグローバルのファイルを使ってください。プロジェクトのファイルはコミットされ、ポートはマシンごとに異なるからです。

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

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

mcp.json に AWS 認証情報を書く必要はあるか?

DynoTable ならその必要はありません — 設定が保持するのはループバックの URL だけで、AWS の呼び出しは DynoTable 自身が行います。シークレットを必要とするサーバーを使う場合は、値がコミットされるファイルではなく環境に留まるよう、${env:NAME} として参照してください。

MCP サーバーは接続済みなのに、ツールが表示されないのはなぜか?

ほとんどの場合、DynoTable 側でプロファイルが 1 つも公開されていないか、要求している内容を何も公開しないスコープで接続が承認されているためです。プロファイルの MCP 経由で公開を確認し、そのうえで MCP ペインで承認済みのスコープを見直してください。