Cursor 向けの DynamoDB MCP

Cursor は、呼び出せる MCP サーバーを与えれば、エディタからあなたの DynamoDB テーブルにクエリを実行できます。

このガイドでは、mcp.json の設定、プロジェクトとグローバルの選択、サーバーの有効化と承認、そしてリポジトリ内の設定ファイルに AWS のアクセスキーを置くのを避ける方法を扱います。

ローカルの MCP サーバーとして動作する DynoTable に Cursor を向ければ、 mcp.json にキーは一切入りません。DynoTable はキーを Cursor に渡さず、キーは AWS の設定ファイルに留まります。DynoTable をインストールしない場合は、読み取り専用プロファイルのセットアップを参照してください。すべての選択肢の比較は DynamoDB MCP サーバーの概要にあります。

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

エディタのエージェントが書くまずい DynamoDB コードの多くは、でっち上げたキースキーマから始まります。サーバーを接続すれば、Cursor は関数を書く前に実際のスキーマ（テーブル、キースキーマ、インデックス、アイテムに現れる属性）を読み取ります。

DynoTable を通せば、ライブのテーブルに対して PartiQL の SELECT、GetItem、アイテム数のカウントを実行し、Workbench SQL で集計し、レビュー可能なステージングエリアに編集をステージングすることもできます。

生の Query ツールや Scan ツールはなく、PartiQL の結果は少量のサンプルに制限されて返ります。

始める前に

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

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

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

Cursor は MCP サーバーを 2 つのファイルから読み取ります:

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

127.0.0.1 のサーバーには、グローバルのファイルを使います。DynoTable のスニペットは ~/.cursor/mcp.json を指定しているので、そこに貼り付けます:

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

（command ではなく）url キーが HTTP トランスポートを選び、DynoTable は streamable HTTP を話します。?profile=prod は DynoTable の承認プロンプトでプロファイルを事前選択します。接続の承認はやはりアプリ内で行います。

token が必要なサーバー

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

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

設定にシークレットが含まれてしまうあらゆる MCP サーバーで、この書き方を使ってください。プロジェクトの mcp.json に生の AWS_SECRET_ACCESS_KEY を貼り付ければ、git の履歴に残ります。

有効化して接続を承認する

Cursor のサイドバーの Customize からサーバーを有効にします（古いビルドでは Cursor Settings → MCP または Tools & Integrations）。

DynoTable の endpoint は OAuth で保護されているので、初回接続時に Cursor がブラウザでのログインを開き、DynoTable がクライアント名を示す同意プロンプトを表示します。

まずは読み取り専用を付与しましょう。読み取りとステージとフルアクセスについては概要のスコープの節で説明しています。

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

有効なプランまたはトライアルがない場合、DynoTable はすべての接続を読み取り専用に制限し、 Workbench SQL ツールを非表示にします。

Cursor のデフォルトの Auto-review 実行モードでは、MCP ツールの呼び出しを承認するのはあなたではなく分類器です。このサーバーには Allowlist 実行モードを使い、そのツールを許可リストに入れないでおけば、呼び出しのたびにまずあなたに確認が来ます。読み取り専用スコープが止めるのは書き込みであってテーブル全体のスキャンではなく、承認の際に各ステートメントを確認できます。その他の制御はコストの節にあります。

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

ツールはチャットの Available Tools の下に表示されます。サーバーが失敗する場合は、Output パネル（Cmd+Shift+U）を開いて MCP Logs を選ぶと、接続と認証のエラーを確認できます。そのうえで、あなたのデータにしか答えられないことをエージェントに尋ねます: 「このプロファイルのテーブルと、それぞれのキースキーマを一覧してください。」

言葉を濁さずテーブルの内容から答えたなら、ツールは生きています。

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

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

プロジェクトの mcp.json はコミットもされるので、そのファイルの中のキーは git 履歴の中のキーになります。

DynoTable を経由すれば、ファイルが保持するのはループバックの URL だけで、エージェントは MCP 経由でキーを受け取らず、書き込みツールもありません。読み取りとステージでは、操られたエージェントにできるのは、あなたが読む差分をステージングすることだけです。それでもキーは ~/.aws にあり、Cursor のエージェントターミナルはそれを読めます。

~/.cursor/sandbox.json に "readBoundary": "workspace" を設定してください（Cursor 3.23 以降）。するとサンドボックス内のターミナルコマンドはワークスペースの外を読めなくなり、エージェントはそこにあるファイルを読む前に確認を求めます。この制限はサンドボックス内のコマンドにしか効きません。 Cursor のデフォルトの Auto-review 実行モードでは、サンドボックス外での再実行を承認するのはあなたではなく分類器なので、Allowlist 実行モード（Settings → Agents → Approvals & Execution）を使ってそれらがあなたに回ってくるようにします（実行モード）。全体のモデルは概要で説明しています。

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

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

{
  "mcpServers": {
    "dynamodb-ro": {
      "command": "<server command>",
      "args": ["<server args>"],
      "env": {"AWS_PROFILE": "dynamodb-readonly"}
    }
  }
}

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

トラブルシューティング

サーバーが表示されない。 ファイルが違うか、JSON が不正です。JSON を検証し、編集したのが ~/.cursor/mcp.json であることを確認してください。

接続に失敗する、またはログインがアクセス拒否で終わる。 Output パネルの MCP Logs を確認します。原因は、DynoTable が起動していない、MCP サーバーがオフ、プロファイルが 1 つも公開されていない、あるいはポートが変わった、のいずれかです。プロファイルの MCP セクションから endpoint をコピーし直してください。

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

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

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

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

よくある質問

Cursor を DynamoDB に接続するには?

DynoTable で、使いたいプロファイルを公開し（MCP 経由で公開）、設定 → MCP でサーバーをオンにします。endpoint を ~/.cursor/mcp.json の mcpServers の下に url として追加します。

Cursor でサーバーを有効にし、求められたらログインし、DynoTable で接続を承認してください。

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

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

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

いいえ。DynoTable なら、設定が保持するのはループバックの URL だけです。別のサーバーなら、読み取り専用のプロファイル名を env（AWS_PROFILE）で渡し、token は ${env:NAME} として参照して、値が環境に留まるようにします。

MCP サーバーに DynamoDB のツールが表示されないのはなぜか?

ログインがアクセス拒否で終わったなら、DynoTable でプロファイルが 1 つも公開されていないか、サーバーがオフです。MCP 経由で公開をオンにして再接続してください。

ツールは読み込まれるのにステージングがない場合、接続は読み取り専用です。あなたがそう付与したか、プランが失効したためです。Workbench SQL がない場合は、プランまたはトライアルが失効しています。

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

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