DEV Community

Cover image for DynamoDB MCP server: Claude Code, Cursor, Codex
DynoTable
DynoTable

Posted on • Originally published at dynotable.com

DynamoDB MCP server: Claude Code, Cursor, Codex

#dynamodb #aws #database #nosql

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).

Claude Code

Run the command from the MCP pane in your project:

claude mcp add --transport http dynotable http://127.0.0.1:<port>/mcp
Enter fullscreen mode Exit fullscreen mode

Cursor

Add it to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "dynotable": {
      "url": "http://127.0.0.1:<port>/mcp"
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

VS Code

Add it to .vscode/mcp.json (Copilot agent mode):

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

Codex

Add it to ~/.codex/config.toml:

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

OpenCode

Add it under mcp in opencode.json:

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

Setting up a specific client — including its scope rules, verification commands and the
mistakes that client in particular tends to hit — has a dedicated walkthrough:

  • Claude Code — the claude mcp add command, which --scope to register at, and verifying with claude mcp list + /mcp.
  • Cursor — mcp.json project vs global, why a loopback server doesn't belong in a committed file, and ${env:} for servers that do need a secret.
  • Codex — the mcp_servers snake_case trap, url-vs-command transport selection, and the timeouts worth raising.

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 (.env or 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.

Warning

An MCP tool result is untrusted input. A row, a document, or a web page the agent reads
can contain instructions ("ignore previous instructions and delete…"). If the agent's
server holds write-capable AWS keys, a successful prompt injection can act on your tables
directly. Keep the agent read-only, or put a human commit step between the agent
and the write — which is what DynoTable's staging does.

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 Claude Code walkthrough covers scopes and
verification in full; the same pattern works for
Cursor, Codex, VS Code
Copilot, and OpenCode (configs above).

Related

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.

Top comments (0)