DynoTable
Intermedio7 min di lettura

Server MCP per DynamoDB: collega Claude Code, Cursor e Codex in sicurezza

Il Model Context Protocol (MCP) permette a un agente AI nel tuo terminale o editor — Claude Code, Cursor, Codex, VS Code Copilot — di chiamare strumenti esterni invece di tirare a indovinare. Puntane uno su DynamoDB e l'agente può leggere il tuo schema, eseguire query reali e proporre modifiche, senza che tu incolli dump di tabelle in una chat.

Il punto critico è cosa gli consegni. La maggior parte dei modi per collegare un agente a DynamoDB dà al processo del server MCP dell'agente le tue credenziali AWS grezze e l'accesso in scrittura diretto alle tue tabelle. È esattamente lo schema contro cui mettono in guardia i ricercatori di sicurezza: un agente che può essere pilotato dal risultato avvelenato di uno strumento o da un documento con prompt injection, che detiene chiavi capaci di fare DeleteItem in produzione. Questa guida copre entrambi i percorsi — quello sicuro e quello grezzo — così puoi scegliere in modo consapevole.

Esiste un server MCP per DynamoDB?

Sì — e non uno solo. AWS pubblica un server ufficiale orientato alla modellazione dei dati, mentre la community mette a disposizione server npm e PyPI per l'accesso live in sola lettura o in lettura/scrittura. Anche DynoTable funziona come server MCP locale. La vera scelta non è se esista o meno, ma quanti poteri vuoi affidare all'agente: i server in sola lettura sono ragionevolmente sicuri; quelli con accesso in scrittura che detengono le tue chiavi AWS sono il vero rischio.

  • Vuoi che un agente legga e ragioni su DynamoDB? Diversi server MCP lo fanno; quelli in sola lettura sono ragionevolmente sicuri.
  • Vuoi che un agente modifichi i dati? Non dargli le tue chiavi e un percorso di scrittura diretto. Instrada le scritture attraverso uno step di revisione, così che le confermi una persona. È il modello che usa DynoTable, qui sotto.

Il modo sicuro: DynoTable come server MCP

DynoTable è un client DynamoDB desktop che può fungere da server MCP locale. Un agente esterno si connette ad esso e ottiene lo stesso toolkit sottoposto a gate che usa l'assistente integrato di DynoTable — ma con due garanzie che i server standalone non offrono:

  • Le tue credenziali AWS non raggiungono mai l'agente. DynoTable detiene i tuoi profili AWS; l'agente parla con DynoTable, non con AWS. Niente nel processo dell'agente può leggere le tue chiavi.
  • L'agente non può scrivere direttamente su DynamoDB. Ogni modifica che propone finisce nella finestra dei commit in staging di DynoTable perché tu la riveda e la confermi. Gli agenti propongono; tu confermi.

In più: è disattivato per impostazione predefinita, ogni connessione è approvata per client a uno scope che scegli tu, l'endpoint è solo loopback (127.0.0.1, mai raggiungibile al di fuori della tua macchina) e qualsiasi client è revocabile.

Abilitalo e collega un client

Attiva il server in Settings → MCP Server. DynoTable si associa a una porta di loopback e mostra il comando di connessione esatto. L'endpoint è http://127.0.0.1:<port>/mcp (copia la porta reale dal pannello).

Esegui il comando dal pannello MCP nel tuo progetto:

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

La prima volta che un client si connette, DynoTable mostra un prompt di consenso in-app che nomina il client e ti chiede quale scope concedere — oppure di negare:

  • Read only — schema, query, letture di item. Nessuna modifica.
  • Read & stage — quanto sopra, più mettere in staging le modifiche perché tu le riveda (mai una scrittura diretta).
  • Full access — quanto sopra, più aprire viste, filtri ed esportazioni. Le scritture passano comunque attraverso lo staging anche qui.

La configurazione completa, gli scope e il modello di sicurezza si trovano nella documentazione del server MCP.

Le altre opzioni (e i loro compromessi)

Funzionano, ma leggi il compromesso prima di puntarne una su una tabella di produzione.

Il server MCP DynamoDB ufficiale di AWS — modellazione, non operazioni live

AWS pubblica un dynamodb-mcp-server ufficiale in awslabs/mcp. Alla data del 2026-06-12 è orientato alla modellazione dei dati e alla guida alla progettazione — design dello schema, validazione con DynamoDB Local, stima dei costi — piuttosto che alla lettura/scrittura live sulle tue tabelle di produzione. Per l'accesso live al data plane, AWS indirizza gli utenti verso il suo AWS API MCP Server generale, che esegue chiamate API/CLI di AWS con le credenziali AWS che hai configurato. Questo significa che il processo del server dell'agente detiene chiavi con pieni poteri e un raggio d'azione ampio, senza uno step di revisione specifico per DynamoDB. (Verifica i set di strumenti attuali nel repo awslabs prima di fare affidamento su questo — questi server cambiano.)

Server community su npm/PyPI — al meglio in sola lettura, al peggio con chiavi grezze

Ci sono diversi server MCP DynamoDB della community su npm e PyPI; alcuni espongono operazioni complete su tabelle/item, altri sono volutamente in sola lettura. Il filo comune:

  • La tua chiave di accesso AWS e il segreto vivono nell'ambiente del server (.env o configurazione del client), con tutto il potere IAM di quelle chiavi.
  • Non c'è alcun consenso per connessione, nessuno scope e nessuno staging delle scritture — quelli in sola lettura ti proteggono solo omettendo gli strumenti di scrittura, non per design.

Un server community in sola lettura è un modo ragionevole e a basso rischio per lasciare che un agente esplori una tabella. Dare a uno capace di scrivere le tue chiavi di produzione è lo schema rischioso.

È sicuro dare a un agente AI l'accesso a DynamoDB?

Dipende interamente dal percorso. L'accesso in lettura su una tabella non sensibile è a basso rischio. L'accesso in scrittura è la vera domanda — e la risposta sicura è non dare mai a un agente autonomo sia le tue credenziali sia un percorso di scrittura diretto. O lo tieni in sola lettura, o instradi ogni modifica attraverso uno step di revisione che una persona approva. DynoTable fa quest'ultima cosa: l'agente non detiene mai le tue chiavi e non scrive mai su DynamoDB; confermi tu dalla finestra di staging.

Un agente MCP può scrivere sulle mie tabelle DynamoDB?

Con un server grezzo capace di scrivere: sì, direttamente — ed è questo il rischio. Con DynoTable: no, non direttamente. Con Read & stage o Full access l'agente può mettere in staging una modifica, ma compare come un diff revisionabile nell'app e viene scritta solo quando tu la confermi.

Come uso Claude Code con DynamoDB?

Avvia il server MCP di DynoTable (Settings → MCP Server), poi esegui claude mcp add --transport http dynotable http://127.0.0.1:<port>/mcp nel tuo progetto, approva la connessione allo scope che vuoi e ricarica Claude Code. A quel punto può leggere il tuo schema, eseguire query e mettere in staging le modifiche — senza mai detenere le tue credenziali AWS. Lo stesso schema funziona per Cursor, VS Code Copilot, Codex e OpenCode (configurazioni sopra).

Correlati

I nomi dei prodotti sono marchi dei rispettivi proprietari; citati solo a scopo identificativo. Dettagli dei server concorrenti e di AWS verificati il 2026-06-12 — ricontrolla i repo upstream prima di fare affidamento su di essi.

Aggiornato