DynamoDB MCP 伺服器：Claude Code、Cursor、Codex

Model Context Protocol (MCP) 讓你終端或編輯器中的 AI 智慧體 —— Claude Code、Cursor、Codex、VS Code Copilot —— 能夠呼叫外部工具，而不是靠猜。把其中一個指向 DynamoDB，智慧體就能讀取你的 schema、執行真實查詢並提議編輯，而無需你把表的轉儲貼上到聊天裡。

問題在於你交給它什麼。把智慧體接入 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 僅環回（127.0.0.1，永遠無法從你機器之外訪問），而且任何用戶端都可撤銷。

啟用它並連線一個用戶端

在設定 → MCP Server 中開啟伺服器。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 會顯示一個應用內同意提示，指出該用戶端並詢問要授予哪個作用域 —— 或拒絕：

僅讀取 —— schema、查詢、item 讀取。不做改動。
讀取並暫存 —— 以上一切，外加暫存改動供你審閱（絕不直接寫入）。
完全訪問 —— 以上一切，外加開啟檢視、設定篩選和匯出。即便在此，寫入仍然經過暫存。

完整的設定、作用域和安全模型見 MCP 伺服器文件。

唯讀 — 架構、查詢、項目讀取。沒有變化。
閱讀和暫存 — 上面的內容，加上暫存更改供您檢視（絕不是直接的寫）。
完全訪問 — 上述內容，加上開啟的檢視、過濾器和匯出。 仍然寫即使在這裡也經過staging。

完整的設定、範圍和安全模型位於 MCP server docs 中。

智慧體查詢在 DynamoDB 上的成本

一個對生產表下 Scan 的 MCP 智慧體，燒的是真金白銀的 RCU。在 us-east-1 的按需模式下，DynamoDB 對每一個被檢查的項目按最終一致每 4 KB 計 0.5 個 RCU——讀取之後才套用的過濾條件並不會減少計量的容量。一張 200 MB、行大小 2 KB 的表，跑完一整遍的量級是 50,000 個 RCU。請只授予唯讀作用域，先問結構再問資料，並在定價計算器裡給探索性讀取估個價。

其他選項（以及它們的權衡）

這些方式都行得通，但在把其中一個指向生產表之前，請先讀一讀權衡。

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

AWS 在 awslabs/mcp 中釋出了一個官方的 dynamodb-mcp-server。截至 2026-06-12，它面向的是資料建模與設計指導 —— schema 設計、針對 DynamoDB Local 的校驗、成本估算 —— 而非針對你生產表的實時讀/寫。對於實時資料平面訪問，AWS 指引使用者使用其通用 AWS API MCP Server，它以你配置的 AWS 憑據執行 AWS API/CLI 呼叫。這意味著智慧體的伺服器程序握有全權金鑰，影響範圍廣泛，且沒有 DynamoDB 專屬的審閱步驟。（在依賴它之前，請在 awslabs 倉庫上核實當前的工具集 —— 這些伺服器會變。）

社群 npm/PyPI 伺服器 —— 好的話唯讀，壞的話裸露金鑰

npm 和 PyPI 上有幾個社群版 DynamoDB MCP 伺服器；有些暴露完整的表/item 操作，另一些則刻意做成唯讀。共同點在於：

你的 AWS 訪問金鑰和密文存在伺服器的環境裡（.env 或用戶端配置），握有這些金鑰的全部 IAM 權能。
沒有按連線的同意、沒有作用域、也沒有寫入暫存 —— 唯讀的那些只是靠省略寫入工具來保護你，而非靠設計。

一個唯讀的社群伺服器，是讓智慧體探索一張表的合理、低風險的方式。把你的生產金鑰交給一個有寫入能力的伺服器，才是那個有風險的模式。

針對具體用戶端的配置——包括它的 scope 規則、驗證命令，以及該用戶端特別容易踩的坑——都有專門的指南：

Claude Code——claude mcp add 命令、該用哪個 --scope 註冊，以及如何用 claude mcp list 和 /mcp 驗證。
Cursor——mcp.json 的項目級與全域性之分、為什麼環回地址的伺服器不該寫進會被提交的檔案，以及給確實需要金鑰的伺服器用的 ${env:}。
Codex——mcp_servers 的 snake_case 陷阱、用 url 還是 command 選擇傳輸方式，以及值得調高的超時設定。

給 AI 智慧體 DynamoDB 訪問權安全嗎？

這完全取決於路徑。對一張非敏感表的讀取訪問風險很低。寫入訪問才是問題所在 —— 而安全的答案是：永遠不要同時把你的憑據和一條直接寫入路徑都交給一個自主智慧體。要麼讓它保持唯讀，要麼讓每一項改動都經過一個由人批准的審閱步驟。DynoTable 採用後者：智慧體既不持有你的金鑰，也絕不寫入 DynamoDB；你從暫存視窗提交。

MCP 智慧體能寫入我的 DynamoDB 表嗎？

用一個有寫入能力的原始伺服器：能，直接寫入 —— 這就是風險所在。用 DynoTable：不能，無法直接寫入。在“讀取並暫存”或“完全訪問”下，智慧體可以暫存一項改動，但它會在應用中呈現為一個可審閱的 diff，只有在你提交時才會寫入。

我該如何把 Claude Code 與 DynamoDB 一起用？

執行 DynoTable 的 MCP 伺服器（設定 → MCP Server），然後在你的項目裡執行 claude mcp add --transport http dynotable http://127.0.0.1:<port>/mcp，以你想要的作用域批准連線，並重新載入 Claude Code。隨後它就能讀取你的 schema、執行查詢並暫存編輯 —— 而絕不持有你的 AWS 憑據。同樣的模式適用於 Cursor、VS Code Copilot、Codex 和 OpenCode（配置見上文）。

Claude Code 指南完整講解了 scope 與驗證；Cursor 和 Codex 也各有一份。