Server MCP

Il Model Context Protocol (MCP) è uno standard aperto che permette agli agenti AI di dialogare con strumenti e fonti di dati esterni. DynoTable può agire come server MCP — così un agente in esecuzione nel tuo terminale o editor (Claude Code, Cursor, Codex e altri) può lavorare direttamente con le tue tabelle DynamoDB, invece di costringerti a copiare schemi e risultati avanti e indietro in una chat.

Quando è connesso, l'agente ottiene lo stesso toolkit sottoposto a gate che usa l'assistente integrato — legge il tuo schema, esegue query e letture di singoli item, mette in staging le modifiche per la revisione, apre viste ed esporta — su un endpoint HTTP locale, solo loopback. L'agente scopre le tue tabelle, le interroga e propone modifiche senza mai detenere le tue credenziali AWS.

È disattivato per impostazione predefinita. Attivarlo, e ogni singola connessione, è esplicitamente sotto il tuo controllo — vedi Sicurezza qui sotto.

Abilita il server

Apri Settings → MCP Server e attivalo. DynoTable avvia un server associato a 127.0.0.1 (solo loopback — mai raggiungibile da un'altra macchina) e mostra il comando di connessione corrispondente.

Settings → MCP Server: il server in esecuzione su una porta locale di loopback, con l'elenco dei client connessi e i loro livelli di accesso.
Settings → MCP Server: il server in esecuzione su una porta locale di loopback, con l'elenco dei client connessi e i loro livelli di accesso.

Esponi i profili

Il server è attivo, ma nessun agente può connettersi finché non esponi un profilo. Apri la sezione MCP di un profilo in Settings e attiva Esponi via MCP. Ogni profilo esposto ottiene il proprio comando di connessione — così puoi configurare una connessione per profilo (es. un dynotable-dev e un dynotable-prod), ciascuna isolata in modo rigido alle credenziali e alla regione di quel profilo. Una connessione vede sempre e solo i dati del profilo a cui è associata.

Possono essere esposti sia i profili basati su AWS sia quelli locali (DynamoDB-Local). Esporre un profilo locale consente a un agente di gestire le tue tabelle locali popolate via MCP — comodo per lo sviluppo. (Due profili locali sulla stessa porta condividono lo stesso database locale, quindi vedono le stesse tabelle.)

La sezione MCP di un profilo con «Esponi via MCP» attivo — il blocco di connessione del profilo mostra l'endpoint da aggiungere al tuo client.
La sezione MCP di un profilo con «Esponi via MCP» attivo — il blocco di connessione del profilo mostra l'endpoint da aggiungere al tuo client.

Collega un client

DynoTable parla MCP su streamable HTTP, quindi qualsiasi agente compatibile con MCP può connettersi. Ogni profilo esposto mostra il proprio comando di connessione nella sua sezione MCP — copialo da lì. Il comando punta a http://127.0.0.1:<port>/mcp?profile=<slug>: il ?profile=<slug> indica a DynoTable quale profilo vuoi e lo pre-seleziona nel prompt di approvazione (è solo un suggerimento — la conferma resta a te). Usare lo slug del profilo nel nome del server (es. dynotable-prod) mantiene distinte le connessioni di due profili.

Gli esempi qui sotto usano prod come slug; sostituiscilo con lo slug del tuo profilo e con la porta reale presa da Settings.

Esegui questo nel tuo progetto — è il comando esatto mostrato nella sezione MCP del profilo:

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

Per collegare un secondo profilo, ripeti con il comando di quel profilo (con il suo slug). Dopo la connessione, riavvia o ricarica il client affinché rilevi il nuovo server.

Approva la connessione

La prima volta che un client si connette, DynoTable mostra un prompt di consenso all'interno dell'app. Nomina il client che si connette, ti lascia scegliere quale profilo la connessione associa (pre-selezionato dal suggerimento ?profile=, limitato ai tuoi profili esposti) e ti chiede di concedere uno scope — oppure di negare. Niente viene esposto finché non approvi.

Il prompt di consenso in-app: un client che si connette richiede l'accesso e tu concedi uno dei tre scope oppure neghi.
Il prompt di consenso in-app: un client che si connette richiede l'accesso e tu concedi uno dei tre scope oppure neghi.

Scope

Uno scope decide quali strumenti la connessione può vedere e usare. Sono cumulativi — ogni livello include quelli precedenti:

  • Read only — legge il tuo schema, esegue query e legge item. Nessuna modifica.
  • Read & stage — tutto quello di Read only, più mettere in staging le modifiche perché tu le riveda e le confermi (l'agente non scrive mai direttamente su DynamoDB — passa attraverso lo staging).
  • Full access — tutto quanto sopra, più aprire viste, impostare filtri ed esportare risultati. Le scritture passano comunque attraverso lo staging — anche con Full access l'agente non può scrivere direttamente su DynamoDB.

La connessione si associa al profilo che approvi nel prompt — le sue credenziali e la sua regione sono fissate per tutta la durata della connessione, così legge (e mette in staging le scritture verso) esattamente i dati di quel profilo. Il nome del client nel prompt è auto-dichiarato dall'agente che si connette, quindi il profilo e lo scope che approvi sono il vero gate, non il nome.

Se il profilo approvato usa MFA, all'agente viene chiesto il codice monouso direttamente nella sua stessa sessione — senza bisogno di tornare a DynoTable. (I profili che accedono tramite SSO completano comunque quell'accesso in DynoTable.)

Gestisci le connessioni

Ogni client approvato è elencato in Settings → MCP Server. Revoca chiunque in qualsiasi momento — un client revocato viene tagliato fuori alla sua prossima richiesta. Anche annullare l'esposizione di un profilo ne revoca immediatamente le connessioni. Disattivare il server lo ferma del tutto.

Sicurezza

  • Solo loopback. Il server si associa a 127.0.0.1; niente al di fuori della tua macchina può raggiungerlo.
  • Disattivato per impostazione predefinita, approvazione per connessione. Nessun agente ottiene accesso finché non abiliti il server e approvi la sua connessione a uno scope che scegli tu.
  • Le credenziali restano locali. Le connessioni usano i tuoi profili AWS esistenti su questa macchina (Connettiti ad AWS); le credenziali non vengono mai inviate all'agente.
  • Un profilo per connessione. Ogni connessione è fissata al singolo profilo che hai approvato — non può mai raggiungere le tabelle o le credenziali di un altro profilo.
  • Le scritture passano per la revisione. Anche con Full access, le modifiche vengono messe in staging perché tu le confermi — l'agente non può scrivere su DynamoDB da solo.
  • Revocabile. Revoca un client o disattiva il server quando vuoi.

Aggiornato