Server MCP

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

Una volta collegato, l'agente ottiene una proiezione del toolkit regolato dell'assistente integrato — leggere il tuo schema, eseguire query e letture di singoli item, mettere in staging le modifiche per la revisione, aprire viste ed esportare — su un endpoint HTTP locale, solo loopback. Alcuni strumenti locali dell'app restano nell'app e non vengono esposti. L'agente scopre le tue tabelle, le interroga e propone modifiche senza mai avere in mano le tue credenziali AWS.

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

Attivare il server

Apri Impostazioni → Server MCP e attivalo. DynoTable avvia un server in ascolto su 127.0.0.1 (solo loopback, mai raggiungibile da un'altra macchina) e ne mostra il comando di connessione.

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

Esporre i profili

Il server è attivo, ma nessun agente può collegarsi finché non esponi un profilo. Apri la sezione MCP di un profilo nelle Impostazioni e attiva Esponi via MCP. Ogni profilo esposto ottiene il proprio comando di connessione, così puoi predisporre una connessione per profilo (per esempio un dynotable-dev e un dynotable-prod), ciascuna isolata in modo netto sulle credenziali e sulla regione di quel profilo. Una connessione vede solo i dati del profilo a cui è legata.

Puoi esporre sia i profili basati su AWS sia quelli locali (DynamoDB-Local). Esporre un profilo locale permette a un agente di pilotare le tue tabelle locali già popolate via MCP: comodo in 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.

Collegare un client

DynoTable parla MCP su HTTP streamable, quindi può collegarsi qualsiasi agente compatibile con MCP. 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> dice a DynoTable quale profilo vuoi e lo preseleziona nella richiesta di approvazione (è solo un suggerimento, la conferma la dai comunque tu). Usare lo slug del profilo nel nome del server (per esempio dynotable-prod) tiene distinte le connessioni di due profili.

Gli esempi qui sotto usano prod come slug; sostituisci lo slug del tuo profilo e la porta reale che trovi nelle Impostazioni.

Esegui questo comando nel tuo progetto — è esattamente quello mostrato nella sezione MCP del profilo:

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

Aggiungi il server a .cursor/mcp.json (progetto) o ~/.cursor/mcp.json (globale):

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

Aggiungilo a .vscode/mcp.json (modalità agente di Copilot):

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

Aggiungilo a ~/.codex/config.toml:

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

Aggiungilo sotto mcp in opencode.json:

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

Per collegare un secondo profilo, ripeti con il comando di quel profilo (con il suo slug). Dopo la connessione, riavvia o ricarica il client così che veda il nuovo server.

Approvare la connessione

La prima volta che un client si collega, DynoTable mostra una richiesta di consenso dentro l'app. Indica il client che si sta collegando, ti fa scegliere a quale profilo legare la connessione (preselezionato dal suggerimento ?profile=, limitato ai profili che hai esposto) e ti chiede di concedere uno scope — oppure di negare. Nulla viene esposto finché non approvi.

Scope

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

Read only — legge il tuo schema, esegue query e legge item. Nessuna modifica.
Read & stage — tutto ciò che c'è in Read only, più la messa in staging delle modifiche perché tu le riveda e ne faccia il commit (l'agente non scrive mai direttamente su DynamoDB: passa dallo staging).
Full access — tutto quanto sopra, più l'apertura di viste, l'impostazione dei filtri e l'export dei risultati. Le scritture passano comunque dallo staging: anche con Full access l'agente non può scrivere direttamente su DynamoDB.

La connessione è legata al profilo che approvi nella richiesta: le sue credenziali e la sua regione restano fissate per tutta la vita della connessione, quindi legge (e mette in staging le scritture su) esattamente i dati di quel profilo. Il nome del client nella richiesta è auto-dichiarato dall'agente che si collega, quindi il vero controllo sono il profilo e lo scope che approvi, non il nome.

Se il profilo approvato usa l'MFA, il codice una tantum viene chiesto all'agente direttamente nella sua sessione: non serve tornare su DynoTable. (I profili che accedono tramite SSO completano comunque quell'accesso in DynoTable.)

Gestire le connessioni

Ogni client approvato è elencato in Impostazioni → Server MCP. Puoi revocarne uno in qualsiasi momento: un client revocato viene tagliato fuori alla richiesta successiva. Togliere l'esposizione a un profilo ne revoca immediatamente anche le connessioni. Spegnere il server ferma tutto.

Security

Solo loopback. Il server è in ascolto su 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 attivi il server e non approvi la sua connessione con uno scope scelto da te.
Le credenziali restano locali. Le connessioni usano i profili AWS che hai già su questa macchina (Collegarsi 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 dalla revisione. Anche con Full access, le modifiche vengono messe in staging perché tu ne faccia il commit: l'agente non può scrivere su DynamoDB da solo.
Revocabile. Revoca un client o spegni il server quando vuoi.