DynoTable
Intermediate8 min read

DynamoDB MCP for Claude Code

Claude Code can read your DynamoDB schema, run real queries against your tables, and propose edits — if you give it a server to call. This guide covers the connection end to end: the exact command, the scope decision Claude Code makes you take, how to confirm the tools actually loaded, and the part most setups get wrong — what credentials the agent ends up holding.

The short version: point Claude Code at DynoTable running as a local MCP server and your AWS keys stay in DynoTable, not in the agent. If you'd rather compare that against AWS's official server and the community npm/PyPI ones, the DynamoDB MCP server overview does that head to head.

What Claude Code can do once it's connected

With the server connected, Claude Code stops guessing at your data model and starts reading it:

  • Discover tables and schema — table list, key schema, indexes, and the attributes that actually appear in your items (not the ones you meant to write).
  • Run real queries and scans — Query, Scan, GetItem, and PartiQL, with the results fed back into its reasoning instead of into your clipboard.
  • Aggregate — counts, sums and group-bys that DynamoDB itself can't do natively.
  • Propose edits — which land in a reviewable staging area, not in your table.

That last one is the whole design. The agent proposes; you commit.

Before you start

You need three things:

  1. DynoTable installed — download it and add the AWS profile you want the agent to see.
  2. The MCP server turned on — Settings → MCP Server. It is off by default. It binds to 127.0.0.1 only, so nothing off your machine can reach it.
  3. A profile exposed — open that profile's MCP section and turn on Expose via MCP. A connection is hard-bound to one profile's credentials and region, so an agent wired to dev can never see prod.

The profile's MCP section shows the exact connect command, including 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, not stdio. Leave it off and Claude Code will try to run dynotable-prod as a command and fail.

The ?profile=prod suffix pre-selects which profile you're asking for in DynoTable's approval prompt. It's a hint, not an authorization — 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 probably not what you want for a database connection:

ScopeFlagWritten toUse it when
Local (default)noneyour user config, scoped to this projectTrying it out
User--scope user~/.claude.jsonYou want it in every project
Project--scope project.mcp.json at the project rootNever, for this

Don't use --scope project. That file is committed, and it would push a 127.0.0.1:<port> server your teammates don't run — their Claude Code will try to connect on every session and fail. Ports are also per-machine. Keep this one local or user:

claude mcp add --scope user --transport http dynotable-prod "http://127.0.0.1:<port>/mcp?profile=prod"

Approve the connection

The first time Claude Code connects, DynoTable — not Claude Code — shows a consent prompt naming the client and asking which scope to grant:

  • Read only — schema, queries, item reads. No changes of any kind.
  • Read & stage — the above, plus staging changes for you to review. Still never a direct write.
  • Full access — the above, plus opening views, filters and exports. Writes still go through staging even here.

Start at Read only. You can revoke or re-approve a client at any time from the MCP pane, and the scope is re-checked on every call — so narrowing it takes effect immediately, not at the next reconnect.

Verify it actually loaded

Two checks, in order:

claude mcp list

This lists every configured server and which scope it resolved from. If dynotable-prod isn't there, the add wrote to a different scope or a different project directory.

Then, inside a Claude Code session:

/mcp

That shows live connection status and the tools the server exposed. A server that is listed by claude mcp list but shows as failed under /mcp is a running problem — DynoTable isn't up, the port moved, or the connection was never approved.

What to ask it

The useful prompts are the ones that need your data, not DynamoDB trivia:

  • "What tables are in this profile, and what are their key schemas?"
  • "Find every order for customer c#4182 in the last 30 days and summarize the status breakdown."
  • "This Query returns nothing — read the table's key schema and tell me why."
  • "Count items per status in orders." (An aggregate DynamoDB has no native answer for.)
  • "Set status to cancelled on these three items." — which stages three diffs for you to review, and writes nothing until you commit.

Claude Code is good at the first four and safe at the fifth precisely because the commit step is yours.

Why not just give Claude Code AWS credentials?

Because the failure mode is unbounded. The usual advice — run an MCP server that holds an AWS access key and secret — gives the agent's process the full IAM power of those keys, with no DynamoDB-specific review step in front of it.

The problem isn't that the model is malicious. It's that an MCP tool result is untrusted input. A row, a document, or a web page the agent reads can carry instructions. That's , and a successful one against a write-capable server holding your keys can act on your tables directly.

Routing through DynoTable removes both halves of that:

  • Your AWS credentials never reach the agent. DynoTable holds the profiles; Claude Code talks to DynoTable, not to AWS. Nothing in the agent's process can read your keys.
  • There is no direct write tool. Not permission-gated — absent. The most a compromised agent can do at Read & stage is propose a diff you'll read.

Troubleshooting

claude mcp list doesn't show it. You added it at local scope from a different directory. Re-run with --scope user.

Listed, but /mcp shows it failed. In order: is DynoTable running, is Settings → MCP Server still on, is the port in the URL still the live one, and did you approve the connection in the app?

Connected, but no tools. The connection was approved at a scope that doesn't expose what you're asking for, or no profile is exposed. Check Expose via MCP on the profile.

It connected but 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. Reload the client — Claude Code caches the tool list for the session.

FAQ

How do I connect Claude Code to DynamoDB?

Install DynoTable, turn on its MCP server under Settings → MCP Server, expose the AWS profile you want the agent to see, then run claude mcp add --transport http with the endpoint shown in that profile's MCP section. Approve the connection in DynoTable at the scope you want, and Claude Code can read your schema and query your tables without ever holding your AWS credentials.

Can Claude Code write to my DynamoDB tables?

Not directly, through DynoTable. There is no commit tool to call — at Read & stage or Full access the agent can stage a change, but it appears as a reviewable diff in the app and is written only when you commit it. A community MCP server configured with write-capable AWS keys is a different story: that one can write to your tables directly.

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 holds your AWS profiles and makes the DynamoDB calls itself, so the keys stay in DynoTable's process. Claude Code talks only to the local MCP endpoint. Community MCP servers generally do require the keys in the agent's environment.

Is it safe to give Claude Code access to production DynamoDB?

Read access to a non-sensitive table is low risk. Write access is the real question, because an MCP tool result is untrusted input and a prompt injection can steer the agent. Keep the connection read-only, or route every change through a human review step so a steered agent can only propose a diff you read.

Product names are trademarks of their respective owners; referenced for identification only. Claude Code command syntax verified 2026-07-27.

Updated