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.

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.)

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"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 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 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.

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.








