DynoTable
Fortgeschritten7 Min. Lesezeit

DynamoDB MCP for Cursor

Cursor can query your DynamoDB tables from the editor — read the schema, run a Query against real data, and propose edits — once you give it a server to call. This guide covers the mcp.json config, the project-vs-global choice, how to confirm the tools loaded, and how to avoid the default pattern that puts AWS access keys in a config file in your repo.

The short version: point Cursor at DynoTable running as a local MCP server and there are no keys in mcp.json at all. For how that compares to AWS's official server and the community npm/PyPI ones, see the DynamoDB MCP server overview.

What Cursor can do once it's connected

  • Read your real schema — tables, key schema, indexes, and the attributes that actually appear in items, so its generated code matches your data instead of a guess.
  • Run queries while it writes code — Query, Scan, GetItem and PartiQL against the live table, so it can check its own assumptions before handing you a function.
  • Aggregate — counts and group-bys DynamoDB has no native answer for.
  • Propose edits — landing in a reviewable staging area rather than in your table.

The obvious payoff for an editor agent is the first one: most bad DynamoDB code comes from the model inventing a key schema.

Before you start

  1. Install DynoTable — download it and add the AWS profile you want Cursor to see.
  2. Turn the MCP server on — Settings → MCP Server. Off by default, bound to 127.0.0.1 only.
  3. Expose a profile — that profile's MCP section → Expose via MCP. The connection is hard-bound to one profile's credentials and region.

Copy the endpoint (with the real port) from the profile's MCP section.

Add the server to mcp.json

Cursor reads MCP servers from two files, and which one you pick matters more here than usual:

  • .cursor/mcp.json in the project — scoped to that repo, and committed unless you ignore it.
  • ~/.cursor/mcp.json in your home directory — global, every project, never committed.

For a 127.0.0.1 server, use the global file:

{
  "mcpServers": {
    "dynotable-prod": {
      "url": "http://127.0.0.1:<port>/mcp?profile=prod"
    }
  }
}

The presence of url (rather than command) is what selects the HTTP transport — DynoTable speaks streamable HTTP, which is what Cursor recommends for remote servers and which reconnects on its own if the server restarts.

?profile=prod pre-selects the profile in DynoTable's approval prompt. It's a hint; you still approve the connection in the app.

If you're wiring up a server that does need credentials

Cursor interpolates ${env:NAME} in both url and headers, so a server that needs a token can read it from your environment instead of sitting in the file:

{
  "mcpServers": {
    "some-remote-server": {
      "url": "https://example.com/mcp",
      "headers": {"Authorization": "Bearer ${env:MY_SERVICE_TOKEN}"}
    }
  }
}

Use that for any MCP server whose config would otherwise contain a secret. A raw AWS_SECRET_ACCESS_KEY pasted into mcp.json is the single most common way DynamoDB credentials end up in a git history.

Enable it in Cursor and approve it

Open Cursor Settings → MCP (or Tools & Integrations, depending on your version). The server should appear with its tool list. If it's toggled off, turn it on — Cursor disables new servers until you acknowledge them.

The first time it connects, DynoTable shows a consent prompt naming the client and asking for a scope:

  • Read only — schema, queries, item reads. No changes.
  • Read & stage — plus staging changes for review. Never a direct write.
  • Full access — plus opening views, filters and exports. Writes still go through staging.

Start at Read only. Scope is re-checked per call, so narrowing it applies immediately.

Verify it actually loaded

In the MCP settings pane, an active server lists its tools. That list is the real signal — a server can show as "connected" and still expose nothing if no profile is exposed on the DynoTable side.

Then ask the agent something only your data can answer: "list the tables in this profile and their key schemas." If it answers from the table rather than hedging, the tools are live.

Why not put AWS keys in mcp.json?

Because that file is read by an agent that also reads untrusted content. An MCP tool result — a row, a document, a fetched page — can carry instructions. That's , and against a write-capable server holding your AWS keys it acts on your tables directly.

There's a second, duller risk that bites more often: .cursor/mcp.json is a project file, and project files get committed. Keys in that file are keys in your git history.

Routing through DynoTable avoids both:

  • No credentials in the config. The file holds a loopback URL. DynoTable owns the AWS profiles and makes the calls; Cursor never sees a key.
  • No direct write tool. Not gated — absent. At Read & stage the worst a steered agent achieves is a diff card you read before committing.

Troubleshooting

The server doesn't appear in settings. Wrong file or invalid JSON — Cursor skips a file it can't parse, silently. Validate the JSON and confirm you edited ~/.cursor/mcp.json.

It appears but is red / disconnected. DynoTable isn't running, the MCP server is off, or the port changed. Re-copy the endpoint from Settings → MCP Server.

Connected, zero tools. No profile is exposed in DynoTable, or the connection was approved at a scope that exposes nothing you're asking for.

Tools listed but never used. You're not in Agent mode, or the request didn't need them. Ask something table-specific.

Edits changed nothing in DynamoDB. Expected — they're staged. Open DynoTable's staging area and commit.

FAQ

How do I connect Cursor to DynamoDB?

Install DynoTable, turn on its MCP server under Settings → MCP Server, expose the AWS profile you want Cursor to see, then add that endpoint to ~/.cursor/mcp.json under mcpServers with a url field. Enable the server in Cursor's MCP settings and approve the connection in DynoTable at the scope you want.

Where does Cursor store MCP server config?

In .cursor/mcp.json inside a project for project-scoped servers, or ~/.cursor/mcp.json in your home directory for global ones. Use the global file for a loopback server, because the project file is committed and the port is per-machine.

Can Cursor write to my DynamoDB tables?

Not directly, through DynoTable — there is no commit tool to call. The agent can stage a change at Read & stage or Full access, but it lands as a reviewable diff in the app and is written only when you commit it. A community MCP server holding write-capable AWS keys can write directly.

Do I need to put AWS credentials in mcp.json?

Not with DynoTable — the config holds only a loopback URL, and DynoTable makes the AWS calls itself. If you use a server that does need a secret, reference it as ${env:NAME} so the value stays in your environment rather than in a committed file.

Why is my MCP server connected but no tools show up?

Almost always because no profile is exposed on the DynoTable side, or the connection was approved at a scope that exposes nothing you're asking for. Check Expose via MCP on the profile, then re-check the approved scope in the MCP pane.

Product names are trademarks of their respective owners; referenced for identification only. Cursor config format verified 2026-07-27.

Aktualisiert