DynamoDB MCP 伺服器：安全連接 Claude Code、Cursor 與 Codex

Model Context Protocol（MCP）讓你終端機或編輯器中的 AI 代理 — Claude Code、Cursor、Codex、VS Code Copilot — 能呼叫外部工具，而非靠猜測。把其中一個指向 DynamoDB，代理就能讀取你的結構描述、執行真實查詢並提議編輯，而不必由你把表格傾印貼進聊天視窗。

問題在於你交給它什麼。把代理接上 DynamoDB 的多數做法，都會把你的原始 AWS 憑證和對表格的直接寫入權限交給代理的 MCP 伺服器行程。那正是資安研究人員警告的模式：一個可被遭污染的工具結果或被注入提示的文件操控的代理，手握能在正式環境 DeleteItem 的金鑰。本指南兩者都涵蓋 — 安全路徑與原始路徑 — 讓你能審慎地選擇。

有 DynamoDB MCP 伺服器嗎？

是的，而且不只一個。AWS 發布了一個官方版本，著重於資料建模；社群 npm 和 PyPI 伺服器則提供即時的唯讀或讀寫存取。DynoTable 也能作為本機 MCP 伺服器。真正的選擇不在於有沒有，而在於你給代理多大的權限：唯讀伺服器風險相對可控；持有你 AWS 金鑰的可寫入伺服器才是風險所在。

想讓代理讀取並推理你的 DynamoDB？ 有幾個 MCP 伺服器能做到；其中僅讀取的那些相當安全。
想讓代理變更資料？ 別把你的金鑰和一條直接寫入路徑交給它。把寫入路由經過一個審查步驟，由人類來提交。那就是下方 DynoTable 採用的模型。

安全做法：DynoTable 作為 MCP 伺服器

DynoTable 是一個桌面 DynamoDB 用戶端，能扮演一個本機 MCP 伺服器。外部代理連接它，並取得 DynoTable 內建助手所用的那套相同的受關卡工具集 — 但附帶兩項獨立伺服器所不提供的保證：

你的 AWS 憑證絕不會抵達代理。 DynoTable 持有你的 AWS 設定檔；代理對話的對象是 DynoTable，而非 AWS。代理行程中沒有任何東西能讀到你的金鑰。
代理無法直接寫入 DynamoDB。 它提議的每一項變更都會落入 DynoTable 的暫存提交視窗，供你審查並提交。代理提議；你提交。

此外：它預設關閉、每個連線都以你選定的範圍逐用戶端核准、endpoint 為 僅限回送（loopback）（127.0.0.1，絕不會從你機器之外觸及），且任何用戶端皆 可撤銷。

啟用它並連接一個用戶端

在設定 → MCP 伺服器中開啟伺服器。DynoTable 會繫結一個回送埠並顯示確切的連接指令。endpoint 是 http://127.0.0.1:<port>/mcp（從面板複製真實的埠號）。

在你的專案中執行 MCP 面板裡的指令：

claude mcp add --transport http dynotable http://127.0.0.1:<port>/mcp

將它加入 .cursor/mcp.json（專案）或 ~/.cursor/mcp.json（全域）：

{
  "mcpServers": {
    "dynotable": {
      "url": "http://127.0.0.1:<port>/mcp"
    }
  }
}

將它加入 .vscode/mcp.json（Copilot 代理模式）：

{
  "servers": {
    "dynotable": {
      "type": "http",
      "url": "http://127.0.0.1:<port>/mcp"
    }
  }
}

將它加入 ~/.codex/config.toml：

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

在 opencode.json 的 mcp 之下加入它：

{
  "mcp": {
    "dynotable": {
      "type": "remote",
      "url": "http://127.0.0.1:<port>/mcp",
      "enabled": true
    }
  }
}

用戶端第一次連接時，DynoTable 會顯示一則應用程式內的同意提示，指出該用戶端並詢問要授予哪個範圍 — 或拒絕：

僅讀取 — 結構描述、查詢、item 讀取。沒有變更。
讀取與暫存 — 上述一切，再加上暫存變更供你審查（絕不會直接寫入）。
完整存取 — 上述一切，再加上開啟檢視、篩選與匯出。即使在此，寫入仍會經過暫存。

完整的設定、範圍與安全模型詳見 MCP 伺服器文件。

其他選項（及其取捨）

這些都可行，但在把其中一個指向正式環境表格之前，先讀一下取捨。

AWS 官方的 DynamoDB MCP 伺服器 — 用於建模，而非即時操作

AWS 在 awslabs/mcp 中發布了一個官方的 dynamodb-mcp-server。截至 2026-06-12，它偏向資料建模與設計指引 — 結構描述設計、針對 DynamoDB Local 驗證、成本估算 — 而非對你正式環境表格的即時讀寫。對於即時資料層存取，AWS 引導使用者改用其通用 AWS API MCP Server，它會以你設定的 AWS 憑證執行 AWS API/CLI 呼叫。那意味著代理的伺服器行程持有全權金鑰，影響範圍廣泛，且沒有 DynamoDB 專屬的審查步驟。（在仰賴此項之前，先到 awslabs repo 確認當前的工具集 — 這些伺服器會變動。）

社群 npm/PyPI 伺服器 — 好一點是僅讀取，差一點是原始金鑰

npm 和 PyPI 上有好幾個社群 DynamoDB MCP 伺服器；有些開放完整的表格/item 操作，有些則刻意僅供讀取。共通之處是：

你的 AWS access key 與 secret 存在伺服器的環境中（.env 或用戶端設定），帶有那些金鑰完整的 IAM 權限。
沒有逐連線同意、沒有範圍、也沒有寫入暫存 — 那些僅讀取的伺服器只是靠省略寫入工具來保護你，而非靠設計。

一個僅讀取的社群伺服器，是讓代理探索一個表格的合理、低風險方式。把一個具寫入能力的伺服器交付你的正式環境金鑰，才是有風險的模式。

把 DynamoDB 存取權交給 AI 代理安全嗎？

這完全取決於路徑。對一個非敏感表格的讀取存取是低風險的。寫入存取才是關鍵問題 — 而安全的答案是：絕不同時把你的憑證和一條直接寫入路徑交給一個自主代理。要嘛讓它維持僅讀取，要嘛把每一項變更路由經過一個由人類核准的審查步驟。DynoTable 採取後者：代理從不持有你的金鑰、也從不寫入 DynamoDB；由你從暫存視窗提交。

MCP 代理能寫入我的 DynamoDB 表格嗎？

用一個原始的、具寫入能力的伺服器：能，而且是直接寫入 — 那就是風險所在。用 DynoTable：不能，無法直接寫入。在「讀取與暫存」或「完整存取」下，代理能暫存一項變更，但它會以一個可審查的差異呈現在應用程式中，而且只有當你提交時才會被寫入。

我要如何將 Claude Code 與 DynamoDB 搭配使用？

執行 DynoTable 的 MCP 伺服器（設定 → MCP 伺服器），接著在你的專案中 claude mcp add --transport http dynotable http://127.0.0.1:<port>/mcp，以你想要的範圍核准連線，並重新載入 Claude Code。它就能讀取你的結構描述、執行查詢並暫存編輯 — 而且全程從不持有你的 AWS 憑證。相同的模式也適用於 Cursor、VS Code Copilot、Codex 與 OpenCode（設定如上）。