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 服务器文档。

其他选项（以及它们的权衡）

这些方式都行得通，但在把其中一个指向生产表之前，请先读一读权衡。

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 权能。
没有按连接的同意、没有作用域、也没有写入暂存 —— 只读的那些只是靠省略写入工具来保护你，而非靠设计。

一个只读的社区服务器，是让智能体探索一张表的合理、低风险的方式。把你的生产密钥交给一个有写入能力的服务器，才是那个有风险的模式。

给 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（配置见上文）。