DynamoDB-MCP-Server: Claude Code, Cursor, Codex

Das Model Context Protocol (MCP) lässt einen KI-Agenten in deinem Terminal oder Editor — Claude Code, Cursor, Codex, VS Code Copilot — externe Tools aufrufen, statt zu raten. Richte einen auf DynamoDB, und der Agent kann dein Schema lesen, echte Abfragen ausführen und Änderungen vorschlagen, ohne dass du Tabellen-Dumps in einen Chat kopierst.

Der Haken ist, was du ihm gibst. Die meisten Wege, einen Agenten an DynamoDB zu hängen, geben dem MCP-Serverprozess des Agenten deine rohen AWS-Zugangsdaten und direkten Schreibzugriff auf deine Tabellen. Genau davor warnen Sicherheitsforscher: ein Agent, den ein vergiftetes Tool-Ergebnis oder ein prompt-injiziertes Dokument steuern kann, mit Schlüsseln in der Hand, die in Produktion DeleteItem können. Dieser Guide behandelt beides — den sicheren und den rohen Weg —, damit du bewusst wählen kannst.

Gibt es einen DynamoDB-MCP-Server?

Ja — mehrere. AWS veröffentlicht einen offiziellen, der auf Datenmodellierung ausgerichtet ist, und Server aus der Community auf npm und PyPI bieten Live-Lese- oder Lese-/Schreibzugriff. Auch DynoTable arbeitet als lokaler MCP-Server. Die eigentliche Frage ist nicht, ob es einen gibt, sondern wie viel Macht du dem Agenten gibst: Read-only-Server sind einigermaßen sicher; schreibfähige, die deine AWS-Schlüssel halten, sind das Risiko.

Du willst, dass ein Agent DynamoDB liest und darüber nachdenkt? Mehrere MCP-Server können das; die Read-only-Varianten sind einigermaßen sicher.
Du willst, dass ein Agent Daten ändert? Gib ihm nicht deine Schlüssel und einen direkten Schreibpfad. Leite Writes über einen Prüfschritt, den ein Mensch committet. Das ist das Modell, das DynoTable unten nutzt.

Der sichere Weg: DynoTable als MCP-Server

DynoTable ist ein Desktop-Client für DynamoDB, der als lokaler MCP-Server arbeiten kann. Ein externer Agent verbindet sich damit und bekommt eine Projektion des gated Toolkits, das der eingebaute Assistent von DynoTable nutzt — ein paar app-lokale Tools bleiben in der App —, aber mit zwei Garantien, die die eigenständigen Server nicht bieten:

Deine AWS-Zugangsdaten erreichen den Agenten nie. DynoTable hält deine AWS-Profile; der Agent spricht mit DynoTable, nicht mit AWS. Nichts im Prozess des Agenten kann deine Schlüssel lesen.
Der Agent kann nicht direkt in DynamoDB schreiben. Jede Änderung, die er vorschlägt, landet in DynoTables vorbereitetem Commit-Fenster, das du prüfst und committest. Agenten schlagen vor; du committest.

Dazu: Es ist standardmäßig aus, jede Verbindung wird pro Client in einem Umfang deiner Wahl freigegeben, der Endpoint ist nur Loopback (127.0.0.1, von außerhalb deines Rechners nie erreichbar), und jeder Client ist widerrufbar.

Einschalten und einen Client verbinden

Schalte den Server unter Settings → MCP Server ein. DynoTable bindet einen Loopback-Port und zeigt den exakten Verbindungsbefehl. Der Endpoint ist http://127.0.0.1:<port>/mcp (den echten Port kopierst du aus dem Bereich).

Führ den Befehl aus dem MCP-Bereich in deinem Projekt aus:

claude mcp add --transport http dynotable http://127.0.0.1:<port>/mcp

Trag ihn in .cursor/mcp.json (Projekt) oder ~/.cursor/mcp.json (global) ein:

{
  "mcpServers": {
    "dynotable": {
      "url": "http://127.0.0.1:<port>/mcp"
    }
  }
}

Trag ihn in .vscode/mcp.json ein (Copilot-Agent-Modus):

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

Trag ihn in ~/.codex/config.toml ein:

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

Trag ihn unter mcp in opencode.json ein:

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

Einen bestimmten Client einzurichten — samt seiner Scope-Regeln, Verifikationsbefehle und der Fehler, in die genau dieser Client gern läuft — hat eine eigene Anleitung:

Claude Code — der Befehl claude mcp add, bei welchem --scope du registrierst und die Prüfung mit claude mcp list + /mcp.
Cursor — mcp.json im Projekt vs. global, warum ein Loopback-Server nicht in eine eingecheckte Datei gehört, und ${env:} für Server, die tatsächlich ein Geheimnis brauchen.
Codex — die mcp_servers-snake_case-Falle, die Transportwahl url vs. command und die Timeouts, die du erhöhen solltest.

Wenn ein Client sich zum ersten Mal verbindet, zeigt DynoTable eine Freigabeabfrage in der App, die den Client benennt und fragt, welchen Umfang du gewähren — oder verweigern — willst:

Read only — Schema, Abfragen, Item-Reads. Keine Änderungen.
Read & stage — alles davon, plus Änderungen ins Staging legen, die du prüfst (nie ein direkter Write).
Full access — alles davon, plus Ansichten öffnen, Filter und Exporte. Writes laufen auch hier über Staging.

Das vollständige Setup, die Umfänge und das Sicherheitsmodell stehen in den MCP-Server-Docs.

Was Agenten-Abfragen auf DynamoDB kosten

Ein MCP-Agent, der eine Produktionstabelle Scant, rechnet echte RCU ab. Bei On-Demand in us-east-1 misst DynamoDB 0,5 RCU pro 4 KB letztendlich konsistent für jedes untersuchte Item — Filter, die nach dem Read greifen, senken die abgerechnete Kapazität nicht. Eine 200 MB große Tabelle mit 2 KB großen Zeilen liegt bei grob 50.000 RCU für einen vollen Durchlauf. Gewähre den Umfang Read only, frag nach dem Schema, bevor du Daten holst, und kalkulier explorative Reads im Preisrechner.

Die anderen Optionen (und ihre Kompromisse)

Die funktionieren, aber lies den Kompromiss, bevor du einen davon auf eine Produktionstabelle richtest.

AWS' offizieller DynamoDB-MCP-Server — Modellierung, kein Live-Betrieb

AWS veröffentlicht einen offiziellen dynamodb-mcp-server in awslabs/mcp. Stand 2026-06-12 ist er auf Datenmodellierung und Design-Beratung ausgerichtet — Schema-Entwurf, Validierung gegen DynamoDB Local, Kostenschätzung — und nicht auf Live-Lesen/Schreiben gegen deine Produktionstabellen. Für Live-Zugriff auf die Datenebene verweist AWS auf seinen allgemeinen AWS API MCP Server, der AWS-API-/CLI-Aufrufe mit deinen konfigurierten AWS-Zugangsdaten ausführt. Das heißt: Der Serverprozess des Agenten hält Schlüssel mit voller Macht, großem Wirkungsradius und ohne DynamoDB-spezifischen Prüfschritt. (Prüf die aktuellen Tool-Sets im awslabs-Repo, bevor du dich darauf verlässt — diese Server ändern sich.)

Community-Server auf npm/PyPI — bestenfalls read-only, schlimmstenfalls rohe Schlüssel

Es gibt mehrere DynamoDB-MCP-Server aus der Community auf npm und PyPI; manche legen die vollen Tabellen-/Item-Operationen offen, andere sind bewusst read-only. Der rote Faden:

Dein AWS Access Key und Secret liegen in der Umgebung des Servers (.env oder Client-Konfiguration), mit der vollen IAM-Macht dieser Schlüssel.
Es gibt keine Freigabe pro Verbindung, keine Umfänge und kein Write-Staging — die Read-only-Varianten schützen dich nur, indem sie die Schreib-Tools weglassen, nicht per Design.

Ein Read-only-Server aus der Community ist ein vernünftiger, risikoarmer Weg, einen Agenten eine Tabelle erkunden zu lassen. Einem schreibfähigen deine Produktionsschlüssel zu geben ist das riskante Muster.

Ist es sicher, einem KI-Agenten Zugriff auf DynamoDB zu geben?

Das hängt ganz am Weg. Lesezugriff auf eine unkritische Tabelle ist risikoarm. Schreibzugriff ist die eigentliche Frage — und die sichere Antwort lautet: Gib einem autonomen Agenten nie beides, deine Zugangsdaten und einen direkten Schreibpfad. Entweder bleibt er read-only, oder jede Änderung läuft über einen Prüfschritt, den ein Mensch freigibt. DynoTable macht Letzteres: Der Agent hält nie deine Schlüssel und schreibt nie in DynamoDB; du committest aus dem Staging-Fenster.

Kann ein MCP-Agent in meine DynamoDB-Tabellen schreiben?

Mit einem rohen, schreibfähigen Server: ja, direkt — das ist das Risiko. Mit DynoTable: nein, nicht direkt. Bei Read & stage oder Full access kann der Agent eine Änderung stagen, aber sie erscheint als prüfbares Diff in der App und wird erst geschrieben, wenn du committest.

Wie nutze ich Claude Code mit DynamoDB?

Starte DynoTables MCP-Server (Settings → MCP Server), dann claude mcp add --transport http dynotable http://127.0.0.1:<port>/mcp in deinem Projekt, gib die Verbindung im gewünschten Umfang frei und lade Claude Code neu. Danach kann es dein Schema lesen, Abfragen ausführen und Änderungen stagen — ohne je deine AWS-Zugangsdaten zu halten. Die Claude-Code-Anleitung behandelt Umfänge und Verifikation vollständig; dasselbe Muster funktioniert für Cursor, Codex, VS Code Copilot und OpenCode (Konfigurationen oben).