Servidor MCP do DynamoDB: conecte Claude Code, Cursor e Codex com segurança

O Model Context Protocol (MCP) permite que um agente de IA no seu terminal ou editor — Claude Code, Cursor, Codex, VS Code Copilot — chame ferramentas externas em vez de adivinhar. Aponte um deles para o DynamoDB e o agente pode ler seu schema, executar consultas reais e propor edições, sem que você cole despejos de tabela em um chat.

O detalhe é o que você entrega a ele. A maioria das formas de conectar um agente ao DynamoDB dá ao processo do servidor MCP do agente suas credenciais AWS brutas e acesso de escrita direto às suas tabelas. Esse é exatamente o padrão sobre o qual os pesquisadores de segurança alertam: um agente que pode ser conduzido por um resultado de ferramenta envenenado ou por um documento com injeção de prompt, segurando chaves que podem fazer DeleteItem em produção. Este guia cobre os dois — o caminho seguro e o caminho bruto — para que você possa escolher deliberadamente.

Existe um servidor MCP para o DynamoDB?

Sim — e existem vários. A AWS publica um oficial voltado para modelagem de dados, e servidores da comunidade no npm e no PyPI expõem acesso de leitura ou leitura e escrita ao vivo. O DynoTable também funciona como um servidor MCP local. A escolha real não é se existe um, mas quanta autonomia você entrega ao agente: servidores somente leitura são razoavelmente seguros; os capazes de escrita que guardam suas chaves AWS são o risco.

• Quer que um agente leia e raciocine sobre o DynamoDB? Vários servidores MCP fazem isso; os somente leitura são razoavelmente seguros.
• Quer que um agente altere dados? Não dê a ele suas chaves e um caminho de escrita direto. Roteie as escritas por uma etapa de revisão para que um humano as commite. Esse é o modelo que o DynoTable usa, abaixo.

O jeito seguro: o DynoTable como servidor MCP

O DynoTable é um cliente DynamoDB de desktop que pode agir como um servidor MCP local. Um agente externo conecta-se a ele e ganha o mesmo conjunto de ferramentas controladas que o assistente integrado do DynoTable usa — mas com duas garantias que os servidores isolados não oferecem:

• Suas credenciais AWS nunca chegam ao agente. O DynoTable segura seus perfis AWS; o agente conversa com o DynoTable, não com a AWS. Nada no processo do agente consegue ler suas chaves.
• O agente não pode escrever no DynamoDB diretamente. Toda alteração que ele propõe cai na janela de commit preparado do DynoTable para você revisar e commitar. Os agentes propõem; você commita.

Além disso: ele fica desativado por padrão, cada conexão é aprovada por cliente em um escopo que você escolhe, o endpoint é somente loopback (127.0.0.1, nunca acessível de fora da sua máquina) e qualquer cliente é revogável.

Habilite-o e conecte um cliente

Ligue o servidor em Configurações → Servidor MCP. O DynoTable vincula uma porta loopback e mostra o comando exato de conexão. O endpoint é http://127.0.0.1:<port>/mcp (copie a porta real do painel).

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

{
  "mcpServers": {
    "dynotable": {
      "url": "http://127.0.0.1:<port>/mcp"
    }
  }
}

{
  "servers": {
    "dynotable": {
      "type": "http",
      "url": "http://127.0.0.1:<port>/mcp"
    }
  }
}

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

{
  "mcp": {
    "dynotable": {
      "type": "remote",
      "url": "http://127.0.0.1:<port>/mcp",
      "enabled": true
    }
  }
}

Na primeira vez que um cliente conecta, o DynoTable mostra um pedido de consentimento dentro do app nomeando o cliente e perguntando qual escopo conceder — ou negar:

• Somente leitura — schema, consultas, leituras de item. Sem alterações.
• Leitura e preparação — o acima, mais preparar alterações para você revisar (nunca uma escrita direta).
• Acesso total — o acima, mais abrir visões, filtros e exportações. As escritas ainda passam pela preparação mesmo aqui.

A configuração completa, os escopos e o modelo de segurança ficam na documentação do servidor MCP.

As outras opções (e seus prós e contras)

Elas funcionam, mas leia o prós e contras antes de apontar uma delas para uma tabela de produção.

O servidor MCP oficial do DynamoDB da AWS — modelagem, não operação ao vivo

A AWS publica um dynamodb-mcp-server oficial em awslabs/mcp. Em 2026-06-12 ele é orientado para modelagem de dados e orientação de design — design de schema, validação contra o DynamoDB Local, estimativa de custo — em vez de leitura/escrita ao vivo contra suas tabelas de produção. Para acesso ao plano de dados ao vivo, a AWS direciona os usuários ao seu AWS API MCP Server geral, que executa chamadas da AWS API/CLI com as credenciais AWS que você configurou. Isso significa que o processo do servidor do agente segura chaves de poder total com um raio de impacto amplo e nenhuma etapa de revisão específica do DynamoDB. (Verifique os conjuntos de ferramentas atuais no repositório awslabs antes de confiar nisso — esses servidores mudam.)

Servidores da comunidade no npm/PyPI — somente leitura no melhor caso, chaves brutas no pior

Há vários servidores MCP do DynamoDB da comunidade no npm e no PyPI; alguns expõem operações completas de tabela/item, outros são deliberadamente somente leitura. O fio condutor:

• Sua chave de acesso e secret da AWS ficam no ambiente do servidor (.env ou config do cliente), com todo o poder IAM dessas chaves.
• Não há consentimento por conexão, nem escopos, nem preparação de escrita — os somente leitura protegem você apenas omitindo as ferramentas de escrita, não por design.

Um servidor da comunidade somente leitura é uma forma razoável e de baixo risco de deixar um agente explorar uma tabela. Dar a um capaz de escrita suas chaves de produção é o padrão arriscado.

É seguro dar a um agente de IA acesso ao DynamoDB?

Depende inteiramente do caminho. Acesso de leitura em uma tabela não sensível é de baixo risco. O acesso de escrita é a questão — e a resposta segura é nunca dar a um agente autônomo tanto suas credenciais quanto um caminho de escrita direto. Ou mantenha-o somente leitura, ou roteie toda alteração por uma etapa de revisão que um humano aprova. O DynoTable faz o segundo: o agente nunca segura suas chaves e nunca escreve no DynamoDB; você commita pela janela de preparação.

Um agente MCP pode escrever nas minhas tabelas do DynamoDB?

Com um servidor bruto capaz de escrita: sim, diretamente — esse é o risco. Com o DynoTable: não, diretamente não. Em Leitura e preparação ou Acesso total o agente pode preparar uma alteração, mas ela aparece como um diff revisável no app e só é escrita quando você a commita.

Como eu uso o Claude Code com o DynamoDB?

Rode o servidor MCP do DynoTable (Configurações → Servidor MCP), depois claude mcp add --transport http dynotable http://127.0.0.1:<port>/mcp no seu projeto, aprove a conexão no escopo que você quiser e recarregue o Claude Code. Ele pode então ler seu schema, executar consultas e preparar edições — sem nunca segurar suas credenciais AWS. O mesmo padrão funciona para Cursor, VS Code Copilot, Codex e OpenCode (configs acima).

Relacionado

• Documentação do servidor MCP — configuração completa, escopos, consentimento e o modelo de segurança.
• Ferramentas de IA — o conjunto de ferramentas controladas que os agentes externos ganham, e como cada ação é permissionada.
• Preparação — como as escritas propostas são revisadas e commitadas.
• A lacuna do PartiQL vs SQL que um agente encontra no DynamoDB, e a comparação honesta de clientes GUI do DynamoDB.
• Prefere montar uma única requisição à mão? O Construtor de Expressões do DynamoDB gera a FilterExpression / KeyConditionExpression no seu navegador — sem agente, sem SQL.
• Baixe o DynoTable e conecte seu primeiro agente em menos de um minuto.

Os nomes de produtos são marcas registradas de seus respectivos donos; referenciados para identificação apenas. Detalhes dos servidores concorrentes e da AWS verificados em 2026-06-12 — reverifique os repositórios upstream antes de confiar neles.