DynoTable
Fortgeschritten6 Min. Lesezeit

DynamoDB-MCP-Server: Claude Code, Cursor & Codex sicher verbinden

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 davon auf DynamoDB, und der Agent kann dein Schema lesen, echte Queries ausführen und Änderungen vorschlagen, ohne dass du Tabellen-Dumps in einen Chat einfügst.

Der Haken ist, was du ihm überlässt. Die meisten Wege, einen Agenten mit DynamoDB zu verdrahten, geben dem MCP-Server-Prozess des Agenten deine rohen AWS-Anmeldedaten und direkten Schreibzugriff auf deine Tabellen. Das ist genau das Muster, vor dem Sicherheitsforscher warnen: ein Agent, der von einem vergifteten Tool-Ergebnis oder einem per Prompt Injection manipulierten Dokument gesteuert werden kann und Schlüssel hält, die in der Produktion DeleteItem ausführen können. Diese Anleitung behandelt beides — den sicheren Weg und den rohen Weg — damit du bewusst wählen kannst.

Gibt es einen DynamoDB-MCP-Server?

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

  • Willst du, dass ein Agent über DynamoDB liest und nachdenkt? Mehrere MCP-Server können das; die schreibgeschützten sind einigermaßen sicher.
  • Willst du, dass ein Agent Daten ändert? Gib ihm nicht deine Schlüssel und einen direkten Schreibweg. Leite Schreibvorgänge über einen Prüfschritt, sodass ein Mensch sie committet. Das ist das Modell, das DynoTable nutzt, siehe unten.

Der sichere Weg: DynoTable als MCP-Server

DynoTable ist ein Desktop-DynamoDB-Client, der als lokaler MCP-Server agieren kann. Ein externer Agent verbindet sich damit und bekommt dasselbe gesperrte Toolkit, das auch DynoTables eingebauter Assistent nutzt — aber mit zwei Garantien, die die eigenständigen Server nicht bieten:

  • Deine AWS-Anmeldedaten 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 Staging-Fenster, damit du sie prüfen und committen kannst. Agenten schlagen vor; du committest.

Außerdem: Er ist standardmäßig aus, jede Verbindung wird pro Client mit einem von dir gewählten Scope freigegeben, der Endpoint ist nur per Loopback erreichbar (127.0.0.1, nie von außerhalb deines Rechners erreichbar), und jeder Client ist widerrufbar.

Aktivieren und einen Client verbinden

Schalte den Server unter Einstellungen → MCP-Server ein. DynoTable bindet einen Loopback-Port und zeigt den genauen Verbindungsbefehl. Der Endpoint ist http://127.0.0.1:<port>/mcp (kopiere den echten Port aus dem Panel).

Führe den Befehl aus dem MCP-Panel in deinem Projekt aus:

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

Wenn sich ein Client zum ersten Mal verbindet, zeigt DynoTable eine Zustimmungsabfrage in der App, die den Client nennt und fragt, welchen Scope du gewähren willst — oder ablehnst:

  • Nur Lesen — Schema, Queries, Item-Reads. Keine Änderungen.
  • Lesen & Stagen — alles oben, plus Änderungen für dich zum Prüfen stagen (nie ein direkter Schreibvorgang).
  • Vollzugriff — alles oben, plus Ansichten öffnen, Filter setzen und exportieren. Schreibvorgänge laufen auch hier weiterhin über Staging.

Das vollständige Setup, die Scopes und das Sicherheitsmodell findest du in den MCP-Server-Docs.

Die anderen Optionen (und ihre Kompromisse)

Diese 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-Design, Validierung gegen DynamoDB Local, Kostenschätzung — statt auf Live-Lesen/-Schreiben gegen deine Produktionstabellen. Für Live-Zugriff auf die Datenebene verweist AWS Nutzer auf seinen allgemeinen AWS-API-MCP-Server, der AWS-API-/CLI-Aufrufe mit deinen konfigurierten AWS-Anmeldedaten ausführt. Das bedeutet, der Serverprozess des Agenten hält Schlüssel mit voller Macht und breitem Wirkungsradius und ohne DynamoDB-spezifischen Prüfschritt. (Verifiziere die aktuellen Tool-Sets im awslabs-Repo, bevor du dich darauf verlässt — diese Server ändern sich.)

Community-npm-/-PyPI-Server — bestenfalls schreibgeschützt, schlimmstenfalls rohe Schlüssel

Es gibt mehrere Community-DynamoDB-MCP-Server auf npm und PyPI; manche stellen vollständige Tabellen-/Item-Operationen bereit, andere sind bewusst schreibgeschützt. Der gemeinsame Nenner:

  • 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 Zustimmung pro Verbindung, keine Scopes und kein Write-Staging — die schreibgeschützten schützen dich nur, indem sie die Schreib-Tools weglassen, nicht durch Design.

Ein schreibgeschützter Community-Server 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 DynamoDB-Zugriff zu geben?

Es hängt ganz vom Weg ab. Lesezugriff auf eine nicht sensible Tabelle ist risikoarm. Schreibzugriff ist die Frage — und die sichere Antwort ist, einem autonomen Agenten nie beides zu geben: deine Anmeldedaten und einen direkten Schreibweg. Entweder halte ihn schreibgeschützt, oder leite jede Änderung über einen Prüfschritt, den ein Mensch freigibt. DynoTable tut 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 Lesen & Stagen oder Vollzugriff kann der Agent eine Änderung stagen, aber sie erscheint als prüfbares Diff in der App und wird erst geschrieben, wenn du sie committest.

Wie nutze ich Claude Code mit DynamoDB?

Starte DynoTables MCP-Server (Einstellungen → MCP-Server), führe dann claude mcp add --transport http dynotable http://127.0.0.1:<port>/mcp in deinem Projekt aus, gib die Verbindung mit dem gewünschten Scope frei und lade Claude Code neu. Er kann dann dein Schema lesen, Queries ausführen und Bearbeitungen stagen — ohne jemals deine AWS-Anmeldedaten zu halten. Dasselbe Muster funktioniert für Cursor, VS Code Copilot, Codex und OpenCode (Konfigurationen oben).

Verwandt

  • MCP-Server-Docs — vollständiges Setup, Scopes, Zustimmung und das Sicherheitsmodell.
  • KI-Tools — das gesperrte Toolkit, das externe Agenten bekommen, und wie jede Aktion mit Berechtigungen versehen ist.
  • Staging — wie vorgeschlagene Schreibvorgänge geprüft und committet werden.
  • Die PartiQL-vs-SQL-Lücke, auf die ein Agent bei DynamoDB stößt, und der ehrliche Überblick über DynamoDB-GUI-Clients.
  • Lieber eine einzelne Anfrage von Hand zusammenbauen? Der DynamoDB-Expression-Builder erzeugt die FilterExpression / KeyConditionExpression in deinem Browser — kein Agent, kein SQL.
  • Lade DynoTable herunter und verbinde deinen ersten Agenten in unter einer Minute.

Produktnamen sind Marken ihrer jeweiligen Inhaber; hier nur zur Identifizierung genannt. Details zu Wettbewerbern und AWS-Server am 2026-06-12 verifiziert — prüfe die Upstream-Repos erneut, bevor du dich darauf verlässt.

Aktualisiert