DynamoDB MCP for Claude Code
Claude Code can read your DynamoDB schema, run reads against your tables and propose edits once you give it an MCP server to call.
Below: the exact command, the scope to register it at, the login step, how to confirm the tools loaded, and which credentials the agent ends up holding.
Point Claude Code at DynoTable running as a local MCP server and DynoTable
never passes your AWS keys to the agent. Claude Code's own shell can still read ~/.aws,
so block that too. Not installing DynoTable? Jump to
the read-only profile setup. The
DynamoDB MCP server overview compares all the options.
What Claude Code can do once it's connected
- Discover tables and schema: the table list, key schema, indexes, and the attributes that actually appear in your items.
- Read data: PartiQL
SELECT(run as a Query when theWHEREpins the partition key, otherwise as a Scan),GetItemand item counts. Results come back capped to a small sample. There is no rawQueryorScantool. - Aggregate: counts, sums and group-bys through Workbench SQL, which DynamoDB can't do natively.
- Propose edits: they land in a reviewable staging area, not in your table. You commit.
Before you start
- Install DynoTable: download it and add the AWS profile you want the agent to see.
- Expose that profile: open its MCP section and turn on Expose via MCP. A
connection is bound to one profile's credentials and region, so an agent wired to
devcan't seeprod. With nothing exposed, every connection is refused. - Turn the MCP server on in Settings → MCP. It is off by default and binds to
127.0.0.1only, so nothing off your machine can reach it.
The profile's MCP section then shows the connect command with the real port.
Add the server to Claude Code
Run this in your project, substituting the port and profile slug from that pane:
claude mcp add --transport http dynotable-prod "http://127.0.0.1:<port>/mcp?profile=prod"--transport http matters: DynoTable speaks MCP over streamable HTTP. Leave it off
and Claude Code registers the URL itself as a stdio command (with a warning), which
fails to start.
Quote the URL: zsh treats an unquoted ? as a glob.
The ?profile=prod suffix pre-selects that profile in DynoTable's approval prompt. You
still confirm the connection in the app.
Which scope to register it at
Claude Code writes the server to one of three places, and the default is fine here:
| Scope | Flag | Written to | Use it when |
|---|---|---|---|
| Local (default) | none | ~/.claude.json, under this project's path | Trying it out |
| User | --scope user | ~/.claude.json, for every project | You want it in every project |
| Project | --scope project | .mcp.json at the project root | Never, for this |
Don't use --scope project. That file is committed, so it pushes a
127.0.0.1:<port> server your teammates don't run: Claude Code asks each of them to
approve it, then fails to connect.
Ports are also per-machine. Keep it local or user:
claude mcp add --scope user --transport http dynotable-prod "http://127.0.0.1:<port>/mcp?profile=prod"Log in and approve the connection
DynoTable's endpoint is OAuth-protected, so a new server shows Needs authentication.
Inside a Claude Code session, run /mcp, pick dynotable-prod and authenticate.
From your shell, claude mcp login dynotable-prod does the same. Your browser opens and
DynoTable shows a consent prompt naming the client.
Grant Read only to start. Read & stage adds staged edits; Full access adds opening views, filters and exports. What each allows, and why none of them is a direct write, is on the overview's scopes section.
Two things to know before you pick:
- A grant can't be narrowed in place. The MCP pane offers Revoke and Revoke all; a revoked client fails on its next request. To change scope, revoke it and approve the reconnect at the scope you want.
- Without an active plan or trial, DynoTable clamps every connection to Read only and hides the Workbench SQL tool, whatever you granted.
Verify it actually loaded
claude mcp listThis prints each server with a health status: Connected, Needs authentication
or Failed to connect. claude mcp get dynotable-prod adds the scope it was written
to.
If dynotable-prod isn't listed, the add went to local scope in a different directory,
and claude mcp get can't see it from here either. Re-run the add in this directory,
or with --scope user.
Then, inside a Claude Code session:
/mcpThat shows the live status and the tools the server exposed.
What to ask it
The useful prompts are the ones that need your data:
- "What tables are in this profile, and what are their key schemas?"
- "Find every ticket for account
acmein the last 30 days and summarize the status breakdown." - "This
Queryreturns nothing. Read the table's key schema and tell me why." - "Count items per
statusintickets." (An aggregate DynamoDB has no native answer for.) - "Set
statustoclosedon these three items." This stages three diffs for you to review and writes nothing until you commit.
Ask for the key schema before data questions. An agent that knows the partition key can pin it, so its reads run as Queries instead of full-table Scans.
Leave Claude Code's per-call approval on for this server rather than adding an allow rule, so you see each statement before it runs. The cost section covers the other controls.
Why not give Claude Code AWS credentials?
A server that holds an AWS key gives the agent's process the full IAM power of that key, with no review step in front of it.
An MCP tool result is untrusted input: a row, a document or a web page can carry instructions. That's prompt injection, and against write-capable credentials it can act on your tables.
Through DynoTable, the agent gets no key over MCP and no write tool, so the most a steered agent can do at Read & stage is stage a diff you read. The overview covers the full model.
Keep Claude Code out of your AWS files
Your keys still live in ~/.aws, and Claude Code's Bash tool reads most of your machine
by default, credential files included. Turn on its sandbox and deny the directory, then
deny the file tool too, since a sandbox entry doesn't stop the Read tool. In
~/.claude/settings.json:
{
"permissions": {
"deny": ["Read(~/.aws/**)"]
},
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"allowUnsandboxedCommands": false,
"autoAllowBashIfSandboxed": false,
"credentials": {
"files": [{"path": "~/.aws", "mode": "deny"}]
}
}
}The sandbox runs on macOS, Linux and WSL2. On Linux and WSL2, install bubblewrap and
socat first. If the sandbox can't start, Claude Code runs commands unsandboxed by
default; failIfUnavailable: true makes it refuse to start instead. On native Windows
the sandbox doesn't run, so with that key Claude Code won't start: run it inside WSL2, or
leave out the sandbox block there (the Read deny still applies).
allowUnsandboxedCommands: false stops Claude from retrying a blocked command outside
the sandbox. Turning the sandbox on also auto-approves sandboxed Bash commands;
autoAllowBashIfSandboxed: false keeps the per-command prompt.
Local MCP servers run outside the sandbox, so a stdio server still reads its profile. Details are in Anthropic's sandboxing docs.
Without DynoTable: a read-only profile
If you run another DynamoDB MCP server, make its credentials read-only: an AWS profile
for a role with the managed AmazonDynamoDBReadOnlyAccess policy (the
overview shows the profile
block). Pass the profile name, not keys:
claude mcp add --env AWS_API_MCP_PROFILE_NAME=dynamodb-readonly --env READ_OPERATIONS_ONLY=true \
--transport stdio aws-api -- uvx awslabs.aws-api-mcp-server@latestThat's the AWS API MCP Server, which reads AWS_API_MCP_PROFILE_NAME; most other
servers take AWS_PROFILE. Keep an option such as --transport between the last --env
and the server name, or the CLI reads the name as another KEY=value pair. Everything
after -- starts the server.
A write the agent attempts is refused by the server's read-only filter, and IAM denies it if anything gets past.
Troubleshooting
claude mcp list doesn't show it. You added it at local scope from a different
directory. Re-run with --scope user.
Needs authentication. Run /mcp and authenticate, or claude mcp login dynotable-prod.
Failed to connect, or the login ends in access denied. In order: is DynoTable running, is the server on in Settings → MCP, is a profile exposed (Expose via MCP), is the port still the live one, and did you approve the consent prompt?
Connected, but it can't stage. The connection was approved at Read only, or your plan has lapsed and DynoTable clamped it to Read only. Check the scope in the MCP pane's Connected clients list.
No Workbench SQL or aggregates. Your plan or trial has lapsed. A Read only grant keeps Workbench SQL; only the lapsed plan hides it.
It sees the wrong tables. The connection is bound to whichever profile you approved,
regardless of the ?profile= hint. Revoke it in the MCP pane and reconnect.
Nothing works after an update. Restart Claude Code; it loads the tool list when the session starts.
FAQ
How do I connect Claude Code to DynamoDB?
In DynoTable, turn on Expose via MCP for the profile you want and turn the server on
in Settings → MCP. Run the claude mcp add command from that profile's MCP section,
authenticate with /mcp, and approve the connection.
Which scope should I use for claude mcp add?
Use local (the default) or --scope user. Avoid --scope project, because it writes to
a committed .mcp.json and would push a loopback port your teammates don't run.
Does Claude Code need my AWS access keys?
No. DynoTable makes the DynamoDB calls with your profile and never passes the keys to
Claude Code. The keys still sit in ~/.aws, so sandbox Claude Code's shell away from
them. Other servers need credentials: give them a read-only profile name, not raw keys.
Can Claude Code write to my DynamoDB tables?
Not directly through DynoTable: it can stage a change, which is written only when you commit it in the app. A server holding write-capable AWS credentials can write directly; a read-only IAM profile makes that write fail. The overview compares the servers.
Related
- DynamoDB MCP server: the options compared: scopes, the security model, read cost and the read-only path for any server.
- Same setup for Cursor and Codex.
- MCP server docs: full setup, consent and the security model.
- Staging: how proposed writes are reviewed and committed.
- Query DynamoDB with AI: the in-app assistant, if you don't want an external agent at all.
- Prefer to write the request yourself? The
DynamoDB Expression Builder generates the
KeyConditionExpression/FilterExpressionin your browser. - Download DynoTable to connect Claude Code without handing it your keys.
Product names are trademarks of their respective owners; referenced for identification only. Claude Code command syntax verified 2026-10-09.