MCP-Server

Das Model Context Protocol (MCP) ist ein offener Standard, der es KI-Agenten erlaubt, mit externen Tools und Datenquellen zu sprechen. DynoTable kann als MCP-Server agieren — sodass ein Agent in deinem Terminal oder Editor (Claude Code, Cursor, Codex und andere) direkt mit deinen DynamoDB-Tabellen arbeiten kann, statt dass du Schemas und Ergebnisse zwischen Chat und App hin- und herkopierst.

Wenn er verbunden ist, bekommt der Agent dasselbe gesperrte Toolkit, das auch der eingebaute Assistent nutzt — dein Schema lesen, Queries und Einzel-Item-Reads ausführen, Änderungen zur Prüfung vorbereiten, Ansichten öffnen und exportieren — über einen lokalen, nur per Loopback erreichbaren HTTP-Endpoint. Der Agent entdeckt deine Tabellen, fragt sie ab und schlägt Bearbeitungen vor, ohne jemals deine AWS-Anmeldedaten zu halten.

Er ist standardmäßig aus. Ihn einzuschalten und jede einzelne Verbindung liegt ausdrücklich in deiner Hand — siehe Sicherheit unten.

Den Server aktivieren

Öffne Einstellungen → MCP-Server und schalte ihn ein. DynoTable startet einen Server, der an 127.0.0.1 gebunden ist (nur Loopback — nie von einem anderen Rechner erreichbar), und zeigt den Verbindungsbefehl dafür an.

Einstellungen → MCP-Server: der Server läuft auf einem lokalen Loopback-Port, mit der Liste der verbundenen Clients und ihren Zugriffsebenen.

Profile freigeben

Der Server ist an, aber kein Agent kann sich verbinden, bis du ein Profil freigibst. Öffne den MCP-Bereich eines Profils in den Einstellungen und aktiviere Über MCP freigeben. Jedes freigegebene Profil bekommt seinen eigenen Verbindungsbefehl — so kannst du eine Verbindung pro Profil einrichten (z. B. ein dynotable-dev und ein dynotable-prod), jede hart isoliert auf die Anmeldedaten und Region dieses Profils. Eine Verbindung sieht immer nur die Daten des Profils, an das sie gebunden ist.

Sowohl AWS-gestützte als auch lokale (DynamoDB-Local) Profile lassen sich freigeben. Ein lokales Profil freizugeben erlaubt einem Agenten, deine lokalen geseedeten Tabellen über MCP zu steuern — praktisch für die Entwicklung. (Zwei lokale Profile auf demselben Port teilen sich dieselbe lokale Datenbank, sehen also dieselben Tabellen.)

Der MCP-Bereich eines Profils mit eingeschaltetem „Über MCP freigeben“ — der profilspezifische Verbindungsblock zeigt den Endpoint, den du zu deinem Client hinzufügst.

Einen Client verbinden

DynoTable spricht MCP über streamable HTTP, sodass jeder MCP-fähige Agent sich verbinden kann. Jedes freigegebene Profil zeigt seinen eigenen Verbindungsbefehl in seinem MCP-Bereich an — kopiere ihn von dort. Der Befehl zeigt auf http://127.0.0.1:<port>/mcp?profile=<slug>: Das ?profile=<slug> teilt DynoTable mit, welches Profil du möchtest, und wählt es in der Freigabeabfrage vor (es ist nur ein Hinweis — du bestätigst weiterhin). Den Profil-Slug im Servernamen zu verwenden (z. B. dynotable-prod) hält die Verbindungen zweier Profile auseinander.

Die Beispiele unten verwenden prod als Slug; ersetze ihn durch den Slug deines Profils und den echten Port aus den Einstellungen.

Führe das in deinem Projekt aus — es ist genau der Befehl, der im MCP-Bereich des Profils angezeigt wird:

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

Füge den Server zu .cursor/mcp.json (Projekt) oder ~/.cursor/mcp.json (global) hinzu:

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

Füge ihn zu .vscode/mcp.json hinzu (Copilot Agent Mode):

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

Füge ihn zu ~/.codex/config.toml hinzu:

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

Füge ihn unter mcp in opencode.json hinzu:

{
  "mcp": {
    "dynotable-prod": {
      "type": "remote",
      "url": "http://127.0.0.1:<port>/mcp?profile=prod",
      "enabled": true
    }
  }
}

Um ein zweites Profil zu verbinden, wiederhole das mit dem Befehl dieses Profils (seinem eigenen Slug). Starte oder lade den Client nach dem Verbinden neu, damit er den neuen Server erkennt.

Die Verbindung freigeben

Wenn sich ein Client zum ersten Mal verbindet, zeigt DynoTable eine Zustimmungsabfrage in der App. Sie nennt den sich verbindenden Client, lässt dich welches Profil die Verbindung bindet auswählen (vorausgewählt aus dem ?profile=-Hinweis, beschränkt auf deine freigegebenen Profile) und bittet dich, einen Scope zu gewähren — oder abzulehnen. Nichts wird zugänglich gemacht, bis du zustimmst.

Scopes

Ein Scope entscheidet, welche Tools die Verbindung sehen und nutzen kann. Sie sind kumulativ — jede Stufe schließt die vorigen mit ein:

Nur Lesen — dein Schema lesen, Queries ausführen und Items lesen. Keine Änderungen.
Lesen & Stagen — alles aus Nur Lesen, plus Änderungen für dich zum Prüfen und Committen vorbereiten (der Agent schreibt nie direkt in DynamoDB — er läuft über Staging).
Vollzugriff — alles oben, plus Ansichten öffnen, Filter setzen und Ergebnisse exportieren. Schreibvorgänge laufen weiterhin über Staging — selbst bei Vollzugriff kann der Agent nicht direkt in DynamoDB schreiben.

Die Verbindung bindet das Profil, das du in der Abfrage freigibst — seine Anmeldedaten und Region sind für die Lebensdauer der Verbindung festgepinnt, sodass sie genau die Daten dieses Profils liest (und Schreibvorgänge dorthin staged). Der Client-Name in der Abfrage wird vom sich verbindenden Agenten selbst gemeldet, also sind das Profil und der Scope, die du freigibst, das eigentliche Tor, nicht der Name.

Wenn das freigegebene Profil MFA nutzt, wird der Agent direkt in seiner eigenen Sitzung nach dem Einmalcode gefragt — du musst nicht zu DynoTable zurückwechseln. (Profile, die sich per SSO anmelden, schließen diese Anmeldung weiterhin in DynoTable ab.)

Verbindungen verwalten

Jeder freigegebene Client wird in Einstellungen → MCP-Server aufgelistet. Widerrufe jeden davon jederzeit — ein widerrufener Client wird bei seiner nächsten Anfrage abgeschnitten. Ein Profil wieder zu sperren widerruft sofort auch dessen Verbindungen. Den Server auszuschalten stoppt alles.

Sicherheit

Nur Loopback. Der Server bindet 127.0.0.1; nichts außerhalb deines Rechners kann ihn erreichen.
Standardmäßig aus, Freigabe pro Verbindung. Kein Agent bekommt Zugriff, bis du den Server aktivierst und seine Verbindung mit einem Scope deiner Wahl freigibst.
Anmeldedaten bleiben lokal. Verbindungen nutzen deine bestehenden AWS-Profile auf diesem Rechner (Mit AWS verbinden); Anmeldedaten werden nie an den Agenten gesendet.
Ein Profil pro Verbindung. Jede Verbindung ist an das eine Profil gepinnt, das du freigegeben hast — sie kann nie die Tabellen oder Anmeldedaten eines anderen Profils erreichen.
Schreibvorgänge laufen über die Prüfung. Selbst bei Vollzugriff werden Änderungen für dich zum Committen gestaged — der Agent kann nicht von sich aus in DynamoDB schreiben.
Widerrufbar. Widerrufe einen Client oder schalte den Server aus, wann immer du willst.