DynoTable

MCP サーバー

Model Context Protocol (MCP) は、AI エージェントが 外部のツールやデータソースと対話できるようにするオープンな標準です。DynoTable は MCP サーバーとして動作できます — そのため、ターミナルやエディタで動くエージェント（Claude Code、Cursor、Codex など）が、スキーマや結果をチャットにコピー＆ペーストで往復させること なく、あなたの DynamoDB テーブルを直接扱えます。

接続すると、エージェントは組み込みアシスタントが使うのと同じゲート付き ツールキットを得ます — スキーマの読み取り、クエリと単一アイテム読み取りの実行、確認用の変更 のステージング、ビューを開く操作、エクスポート — をすべて、ローカルのループバック専用 HTTP endpoint 経由で行います。エージェントはあなたのテーブルを発見し、クエリし、編集を提案 しますが、あなたの AWS 認証情報を保持することは決してありません。

これはデフォルトでオフです。オンにすること、そして個々の接続はすべて、明示的にあなたの 管理下にあります — 下記のセキュリティを参照してください。

サーバーを有効にする

設定 → MCP サーバーを開いてオンにします。DynoTable は 127.0.0.1 にバインドした サーバー（ループバック専用 — 他のマシンから到達できません）を起動し、その接続コマンドを 表示します。

設定 → MCP サーバー: ローカルのループバックポートで動作しているサーバーと、接続済みクライアントの一覧およびそのアクセスレベルが表示されます。
設定 → MCP サーバー: ローカルのループバックポートで動作しているサーバーと、接続済みクライアントの一覧およびそのアクセスレベルが表示されます。

プロファイルを公開する

サーバーはオンになっていますが、プロファイルを公開するまで、どのエージェントも接続 できません。設定でプロファイルの MCP セクションを開き、MCP 経由で公開をオンに します。公開された各プロファイルは独自の接続コマンドを得ます — そのため、プロファイル ごとに 1 つの接続を構成できます（例えば dynotable-dev と dynotable-prod）。それぞれ そのプロファイルの認証情報とリージョンに厳密に隔離されます。接続は、紐づけられたプロファイル のデータしか見ることがありません。

AWS バックエンドのプロファイルもローカル（DynamoDB-Local）のプロファイルも公開 できます。ローカルプロファイルを公開すると、エージェントが MCP 経由であなたのローカルの シード済みテーブルを操作できます — 開発に便利です。（同じポート上の 2 つのローカル プロファイルは同じローカルデータベースを共有するため、同じテーブルを見ます。）

MCP 経由で公開をオンにしたプロファイルの MCP セクション — プロファイルごとの接続ブロックに、クライアントに追加する endpoint が表示されます。
MCP 経由で公開をオンにしたプロファイルの MCP セクション — プロファイルごとの接続ブロックに、クライアントに追加する endpoint が表示されます。

クライアントを接続する

DynoTable は streamable HTTP で MCP を話すため、MCP 対応のエージェントなら何でも 接続できます。公開された各プロファイルは、その MCP セクションに独自の接続コマンドを 表示します — そこからコピーしてください。コマンドは http://127.0.0.1:<port>/mcp?profile=<slug> を指します。?profile=<slug> は、どの プロファイルを使いたいかを DynoTable に伝え、承認プロンプトで事前選択します（あくまで ヒントであり — それでもあなたが確認します）。サーバー名にプロファイルのスラッグを使う （例えば dynotable-prod）ことで、2 つのプロファイルの接続を区別できます。

下記の例ではスラッグとして prod を使っています。あなたのプロファイルのスラッグと、設定に 表示される実際のポートに置き換えてください。

プロジェクト内でこれを実行します — プロファイルの MCP セクションに表示される正確なコマンドです:

claude mcp add --transport http dynotable-prod "http://127.0.0.1:<port>/mcp?profile=prod"

2 つ目のプロファイルを接続するには、そのプロファイルのコマンド（独自のスラッグ）で繰り返し ます。接続したら、クライアントを再起動またはリロードして新しいサーバーを取り込ませます。

接続を承認する

クライアントが初めて接続すると、DynoTable はアプリ内に同意プロンプトを表示します。 接続してくるクライアントの名前を示し、その接続が紐づくプロファイルを選ばせ （?profile= ヒントから事前選択され、公開済みのプロファイルに限定されます）、スコープ の付与 — または拒否 — を求めます。あなたが承認するまで、何も公開されません。

アプリ内の同意プロンプト: 接続してくるクライアントがアクセスを要求し、あなたは 3 つのスコープのいずれかを付与するか、拒否します。
アプリ内の同意プロンプト: 接続してくるクライアントがアクセスを要求し、あなたは 3 つのスコープのいずれかを付与するか、拒否します。

スコープ

スコープは、その接続がどのツールを見て使えるかを決めます。スコープは累積的で、各段階は 前の段階を含みます:

  • 読み取り専用 — スキーマの読み取り、クエリの実行、アイテムの読み取り。変更はなし。
  • 読み取り＆ステージング — 読み取り専用のすべて、加えてあなたが確認してコミットする ための変更のステージング（エージェントが DynamoDB に直接書き込むことはなく、 ステージングを経由します）。
  • フルアクセス — 上記のすべて、加えてビューを開く、フィルターを設定する、結果を エクスポートする。書き込みはやはりステージングを経由します — フル アクセスでも、エージェントは DynamoDB に直接書き込めません。

接続は、あなたがプロンプトで承認したプロファイルに紐づきます — その認証情報とリージョン は接続の存続期間を通じて固定されるため、ちょうどそのプロファイルのデータを読み取り（書き込み をステージング）します。プロンプトに表示されるクライアント名は、接続してくるエージェントの 自己申告なので、本当のゲートは名前ではなく、あなたが承認するプロファイルとスコープです。

承認したプロファイルが MFA を使う場合、エージェントはワンタイムコードを自身のセッション 内で直接尋ねられます — DynoTable に戻る必要はありません。（SSO 経由でサインインする プロファイルは、引き続き DynoTable でそのサインインを完了します。）

接続を管理する

承認したクライアントはすべて設定 → MCP サーバーに一覧表示されます。いつでもどれでも 取り消せます — 取り消されたクライアントは次のリクエストで遮断されます。プロファイルの公開 を解除すると、その接続も即座に取り消されます。 サーバーをオフにすると、完全に停止します。

セキュリティ

  • ループバック専用。 サーバーは 127.0.0.1 にバインドします。マシンの外からは何も 到達できません。
  • デフォルトでオフ、接続ごとに承認。 サーバーを有効化し、かつあなたが選んだスコープで その接続を承認するまで、どのエージェントもアクセスできません。
  • 認証情報はローカルに留まる。 接続はこのマシン上の既存の AWS プロファイル （AWS に接続）を使います。認証情報がエージェントに送られることは ありません。
  • 接続ごとに 1 つのプロファイル。 各接続は、あなたが承認した単一のプロファイルに固定 されます — 他のプロファイルのテーブルや認証情報に到達することは決してありません。
  • 書き込みは確認を経る。 フルアクセスでも、変更はあなたがコミットするために ステージングされます — エージェントが独力で DynamoDB に書き込むことは できません。
  • 取り消し可能。 いつでもクライアントを取り消すか、サーバーをオフにできます。

更新日