DynoTable
Um servidor MCP local que dá ao Claude Code, Cursor e Codex acesso de leitura ao seu esquema e itens do DynamoDB, com todas as gravações colocadas em fila para revisão humana.
Documentação
Servidor MCP
Conecte Claude Code, Cursor ou Codex ao servidor MCP local do DynoTable — como habilitá-lo, o consentimento e os escopos por conexão, e o modelo de segurança.
O Model Context Protocol (MCP) é um padrão aberto que permite que agentes de IA conversem com ferramentas externas e fontes de dados. O DynoTable pode atuar como um servidor MCP — para que um agente rodando no seu terminal ou editor (Claude Code, Cursor, Codex e outros) possa trabalhar diretamente com suas tabelas do DynamoDB, em vez de você copiar esquemas e resultados de um lado para o outro em um chat. Quando conectado, o agente recebe uma projeção do kit de ferramentas restrito do assistente integrado — leitura do seu esquema, execução de consultas e leituras de itens individuais, preparação de alterações para revisão, abertura de visualizações e exportação — por meio de um endpoint HTTP local, somente loopback. Consultas somente leitura usam o mesmo índice e condição de chave que o filtro visual no aplicativo; visualize o código SDK equivalente com o construtor de consultas antes de conectar um cliente. Algumas ferramentas locais do aplicativo permanecem no aplicativo e não são expostas. O agente descobre suas tabelas, consulta-as e propõe edições sem nunca ter acesso às suas credenciais AWS. Está desativado por padrão. Ativá-lo, e cada conexão individual, está explicitamente sob seu controle — veja Segurança abaixo.
Habilitar o servidor
Abra Configurações → Servidor MCP e ative-o. O DynoTable inicia um servidor vinculado a 127.0.0.1 (somente loopback — nunca acessível de outra máquina) e mostra o comando de conexão para ele. Painel Configurações → Servidor MCP do DynoTable: o servidor MCP do DynamoDB rodando em uma porta local de loopback, com a lista de clientes conectados e seus níveis de acesso.
Expor perfis
O servidor está ativo, mas nenhum agente pode se conectar até você expor um perfil. Abra a seção MCP de um perfil em Configurações e ative Expor via MCP. Cada perfil exposto recebe seu próprio comando de conexão — para que você possa configurar uma conexão por perfil (por exemplo, um dynotable-dev e um dynotable-prod), cada um isolado rigidamente às credenciais e região desse perfil. Uma conexão só vê os dados do perfil ao qual está vinculada. Perfis com suporte AWS e locais (DynamoDB-Local) podem ser expostos. Expor um perfil local permite que um agente conduza suas tabelas locais semeadas via MCP — útil para desenvolvimento. (Dois perfis locais na mesma porta compartilham o mesmo banco de dados local, então veem as mesmas tabelas.) Seção MCP de um perfil do DynoTable com "Expor via MCP" ativado — o bloco de conexão por perfil mostra o endpoint a ser adicionado ao seu cliente.
Conectar um cliente
O DynoTable fala MCP via HTTP transmissível, então qualquer agente compatível com MCP pode se conectar. Cada perfil exposto mostra seu próprio comando de conexão na seção MCP — copie-o de lá. O comando aponta para http://127.0.0.1:/mcp?profile=: o ?profile= informa ao DynoTable qual perfil você deseja e o pré-seleciona no prompt de aprovação (é apenas uma dica — você ainda confirma). Usar o slug do perfil no nome do servidor (por exemplo, dynotable-prod) mantém as conexões de dois perfis distintas. Os exemplos abaixo usam prod como slug; substitua pelo slug do seu perfil e pela porta real de Configurações. Claude CodeCursorVS CodeCodexOpenCode Execute isto no seu projeto — é exatamente o comando mostrado na seção MCP do perfil: claude mcp add --transport http dynotable-prod "http://127.0.0.1:/mcp?profile=prod" Adicione o servidor a .cursor/mcp.json (projeto) ou ~/.cursor/mcp.json (global): { "mcpServers": { "dynotable-prod": { "url": "http://127.0.0.1:/mcp?profile=prod" } } } Adicione-o a .vscode/mcp.json (modo agente Copilot): { "servers": { "dynotable-prod": { "type": "http", "url": "http://127.0.0.1:/mcp?profile=prod" } } } Adicione-o a ~/.codex/config.toml: [mcp_servers.dynotable-prod] url = "http://127.0.0.1:/mcp?profile=prod" Adicione-o sob mcp em opencode.json: { "mcp": { "dynotable-prod": { "type": "remote", "url": "http://127.0.0.1:/mcp?profile=prod", "enabled": true } } } Para conectar um segundo perfil, repita com o comando desse perfil (seu próprio slug). Após conectar, reinicie ou recarregue o cliente para que ele reconheça o novo servidor.
Aprovar a conexão
Na primeira vez que um cliente se conecta, o DynoTable mostra um prompt de consentimento dentro do aplicativo. Ele nomeia o cliente conectado, permite que você escolha qual perfil a conexão vincula (pré-selecionado a partir da dica ?profile=, limitado aos seus perfis expostos) e pede que você conceda um escopo — ou negue. Nada é exposto até você aprovar. Prompt de consentimento MCP no aplicativo do DynoTable: um cliente conectado solicita acesso, e você concede um de três escopos ou nega.
Escopos
Um escopo decide quais ferramentas a conexão pode ver e usar. Eles são cumulativos — cada nível inclui os anteriores: Somente leitura — leia seu esquema, execute consultas e leia itens. Sem alterações. Leitura e preparação — tudo em Somente leitura, além de preparar alterações para você revisar e confirmar (o agente nunca escreve diretamente no DynamoDB — ele roteia pela preparação). Acesso total — tudo acima, além de abrir visualizações, definir filtros e exportar resultados. Gravações ainda passam pela preparação — mesmo no Acesso total, o agente não pode escrever diretamente no DynamoDB. Os escopos seguem sua licença. Desconectado, o servidor recusa conexões; no plano gratuito somente leitura, toda conexão é limitada a Somente leitura e as ferramentas Workbench e Smart Table ficam ocultas, qualquer que seja o escopo que você aprovou. A conexão vincula o perfil que você aprova no prompt — suas credenciais e região são fixadas pela vida da conexão, então ela lê (e prepara gravações para) exatamente os dados desse perfil. O nome do cliente no prompt é autoinformado pelo agente conectado, então o perfil e o escopo que você aprova são a verdadeira barreira, não o nome. Se o perfil aprovado usa MFA, o agente é solicitado a fornecer o código de uso único diretamente em sua própria sessão — sem necessidade de voltar ao DynoTable. (Perfis que entram via SSO ainda concluem esse login no DynoTable.)
Gerenciar conexões
Todo cliente aprovado está listado em Configurações → Servidor MCP. Revogue qualquer um deles a qualquer momento — um cliente revogado é cortado na próxima solicitação. Deixar de expor um perfil também revoga imediatamente suas conexões. Desligar o servidor interrompe tudo.
Segurança
Somente loopback. O servidor vincula 127.0.0.1; nada fora da sua máquina pode alcançá-lo. Desativado por padrão, aprovação por conexão. Nenhum agente obtém acesso até você habilitar o servidor e aprovar sua conexão em um escopo de sua escolha. Credenciais permanecem locais. As conexões usam seus perfis AWS existentes nesta máquina (Conectar à AWS); as credenciais nunca são enviadas ao agente. Um perfil por conexão. Cada conexão é fixada ao único perfil que você aprovou — ela nunca pode alcançar tabelas ou credenciais de outro perfil. Gravações passam por revisão. Mesmo no Acesso total, as alterações são preparadas para você confirmar — o agente não pode escrever no DynamoDB por conta própria. Revogável. Revogue um cliente ou desligue o servidor quando quiser.
Canônico: https://dynotable.com/docs/dynamodb-mcp Mapa do site para agentes: https://dynotable.com/llms.txt · Pergunte a este site: https://dynotable.com/llms?query=