DynamoDB MCP server: connect Claude Code, Cursor & Codex safely
The Model Context Protocol (MCP) lets an AI agent in your terminal or editor — Claude Code, Cursor, Codex, VS Code Copilot — call external tools instead of guessing. Point one at DynamoDB and the agent can read your schema, run real queries, and propose edits, without you pasting table dumps into a chat.
The catch is what you hand it. Most ways to wire an agent to DynamoDB give the
agent's MCP server process your raw AWS credentials and direct write access to
your tables. That is exactly the pattern security researchers warn about: an agent that
can be steered by a poisoned tool result or a prompt-injected document, holding keys
that can DeleteItem in production. This guide covers both — the safe path and the raw
path — so you can choose deliberately.
Is there a DynamoDB MCP server?
Yes — several. AWS publishes an official one geared toward data modeling, and community npm and PyPI servers expose live read or read/write access. DynoTable also acts as a local MCP server. The real choice isn't whether one exists, but how much power you hand the agent: read-only servers are reasonably safe; write-capable ones holding your AWS keys are the risk.
- Want an agent to read and reason over DynamoDB? Several MCP servers do this; the read-only ones are reasonably safe.
- Want an agent to change data? Don't give it your keys and a direct write path. Route writes through a review step so a human commits them. That's the model DynoTable uses, below.
The safe way: DynoTable as an MCP server
DynoTable is a desktop DynamoDB client that can act as a local MCP server. An external agent connects to it and gets the same gated toolkit DynoTable's built-in assistant uses — but with two guarantees the standalone servers don't offer:
- Your AWS credentials never reach the agent. DynoTable holds your AWS profiles; the agent talks to DynoTable, not to AWS. Nothing in the agent's process can read your keys.
- The agent can't write to DynamoDB directly. Every change it proposes lands in DynoTable's staged commit window for you to review and commit. Agents propose; you commit.
Plus: it's off by default, every connection is approved per-client at a scope you
choose, the endpoint is loopback-only (127.0.0.1, never reachable off your
machine), and any client is revocable.
Enable it and connect a client
Turn the server on in Settings → MCP Server. DynoTable binds a loopback port and
shows the exact connect command. The endpoint is http://127.0.0.1:<port>/mcp (copy the
real port from the pane).
Run the command from the MCP pane in your project:
claude mcp add --transport http dynotable http://127.0.0.1:<port>/mcpAdd it to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):
{
"mcpServers": {
"dynotable": {
"url": "http://127.0.0.1:<port>/mcp"
}
}
}Add it to .vscode/mcp.json (Copilot agent mode):
{
"servers": {
"dynotable": {
"type": "http",
"url": "http://127.0.0.1:<port>/mcp"
}
}
}Add it to ~/.codex/config.toml:
[mcp_servers.dynotable]
url = "http://127.0.0.1:<port>/mcp"Add it under mcp in opencode.json:
{
"mcp": {
"dynotable": {
"type": "remote",
"url": "http://127.0.0.1:<port>/mcp",
"enabled": true
}
}
}The first time a client connects, DynoTable shows an in-app consent prompt naming the client and asking which scope to grant — or deny:
- Read only — schema, queries, item reads. No changes.
- Read & stage — the above, plus staging changes for you to review (never a direct write).
- Full access — the above, plus opening views, filters, and exports. Writes still go through staging even here.
The full setup, scopes, and security model live in the MCP server docs.
The other options (and their trade-offs)
These work, but read the trade-off before pointing one at a production table.
AWS's official DynamoDB MCP server — modeling, not live ops
AWS publishes an official dynamodb-mcp-server in
awslabs/mcp. As of 2026-06-12 it is oriented toward
data modeling and design guidance — schema design, validation against DynamoDB
Local, cost estimation — rather than live read/write against your production tables. For
live data-plane access AWS points users to its general AWS API MCP Server, which
runs AWS API/CLI calls with your configured AWS credentials. That means the agent's
server process holds full-power keys with a broad blast radius and no DynamoDB-specific
review step. (Verify current tool sets on the awslabs repo before relying on this —
these servers change.)
Community npm/PyPI servers — read-only at best, raw keys at worst
There are several community DynamoDB MCP servers on npm and PyPI; some expose full table/item operations, others are deliberately read-only. The common thread:
- Your AWS access key and secret live in the server's environment (
.envor client config), with the full IAM power of those keys. - There's no per-connection consent, no scopes, and no write-staging — the read-only ones protect you only by omitting the write tools, not by design.
A read-only community server is a reasonable, low-risk way to let an agent explore a table. Giving a write-capable one your production keys is the risky pattern.
Is it safe to give an AI agent DynamoDB access?
It depends entirely on the path. Read access on a non-sensitive table is low-risk. Write access is the question — and the safe answer is to never give an autonomous agent both your credentials and a direct write path. Either keep it read-only, or route every change through a review step a human approves. DynoTable does the latter: the agent never holds your keys and never writes to DynamoDB; you commit from the staging window.
Can an MCP agent write to my DynamoDB tables?
With a raw write-capable server: yes, directly — that's the risk. With DynoTable: no, not directly. At Read & stage or Full access the agent can stage a change, but it appears as a reviewable diff in the app and is only written when you commit it.
How do I use Claude Code with DynamoDB?
Run DynoTable's MCP server (Settings → MCP Server), then
claude mcp add --transport http dynotable http://127.0.0.1:<port>/mcp in your project,
approve the connection at the scope you want, and reload Claude Code. It can then read
your schema, run queries, and stage edits — without ever holding your AWS credentials.
The same pattern works for Cursor, VS Code Copilot, Codex, and OpenCode (configs above).
Related
- MCP server docs — full setup, scopes, consent, and the security model.
- AI tools — the gated toolkit external agents get, and how each action is permissioned.
- Staging — how proposed writes are reviewed and committed.
- The PartiQL vs SQL gap an agent hits on DynamoDB, and the honest roundup of DynamoDB GUI clients.
- Prefer to assemble a single request by hand? The
DynamoDB Expression Builder generates the
FilterExpression/KeyConditionExpressionin your browser — no agent, no SQL. - Download DynoTable and connect your first agent in under a minute.
Product names are trademarks of their respective owners; referenced for identification only. Competitor and AWS server details verified 2026-06-12 — re-check the upstream repos before relying on them.