Servidor MCP

O Model Context Protocol (MCP) é um padrão aberto que permite que agentes de IA conversem com ferramentas e fontes de dados externas. O DynoTable pode agir como um servidor MCP — para que um agente rodando no seu terminal ou editor (Claude Code, Cursor, Codex e outros) possa trabalhar com suas tabelas do DynamoDB diretamente, em vez de você copiar schemas e resultados de um lado para o outro em um chat.

Quando conectado, o agente ganha o mesmo conjunto de ferramentas controladas que o assistente integrado usa — lendo seu schema, executando consultas e leituras de item único, preparando alterações para revisão, abrindo visões e exportando — sobre um endpoint HTTP local, somente loopback. O agente descobre suas tabelas, consulta-as e propõe edições sem nunca segurar suas credenciais AWS.

Ele fica desativado por padrão. Ligá-lo, e cada conexão individual, está explicitamente sob o seu controle — veja Segurança abaixo.

Habilitar o servidor

Abra Configurações → Servidor MCP e ligue-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.

Expor perfis

O servidor está ligado, mas nenhum agente pode 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 ganha seu próprio comando de conexão — então você pode configurar uma conexão por perfil (por exemplo, um dynotable-dev e um dynotable-prod), cada uma rigidamente isolada às credenciais e à região daquele perfil. Uma conexão só enxerga os dados do perfil ao qual está vinculada.

Tanto perfis com backend AWS quanto perfis locais (DynamoDB-Local) podem ser expostos. Expor um perfil local deixa um agente operar suas tabelas locais com dados de seed sobre MCP — útil para desenvolvimento. (Dois perfis locais na mesma porta compartilham o mesmo banco de dados local, então veem as mesmas tabelas.)

Conectar um cliente

O DynoTable fala MCP sobre streamable HTTP, então qualquer agente compatível com MCP pode conectar. Cada perfil exposto mostra seu próprio comando de conexão na sua seção MCP — copie-o de lá. O comando aponta para http://127.0.0.1:<port>/mcp?profile=<slug>: o ?profile=<slug> informa ao DynoTable qual perfil você quer e o pré-seleciona no pedido 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 mcp add --transport http dynotable-prod "http://127.0.0.1:<port>/mcp?profile=prod"

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

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

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

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

Para conectar um segundo perfil, repita com o comando daquele perfil (seu próprio slug). Depois de conectar, reinicie ou recarregue o cliente para que ele reconheça o novo servidor.

Aprovar a conexão

Na primeira vez que um cliente conecta, o DynoTable mostra um pedido de consentimento dentro do app. Ele nomeia o cliente que está conectando, deixa você escolher 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.

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 — ler seu schema, executar consultas e ler itens. Sem alterações.
• Leitura e preparação — tudo de Somente leitura, mais preparar alterações para você revisar e commitar (o agente nunca escreve no DynamoDB diretamente — ele passa pela preparação).
• Acesso total — tudo acima, mais abrir visões, definir filtros e exportar resultados. As escritas ainda passam pela preparação — mesmo no Acesso total o agente não pode escrever no DynamoDB diretamente.

A conexão vincula o perfil que você aprova no pedido — suas credenciais e região ficam fixadas durante toda a vida da conexão, de modo que ela lê (e prepara escritas para) exatamente os dados daquele perfil. O nome do cliente no pedido é autodeclarado pelo agente que está conectando, então o perfil e o escopo que você aprova são a verdadeira proteção, não o nome.

Se o perfil aprovado usa MFA, o código único é pedido ao agente diretamente na sessão dele — sem precisar voltar ao DynoTable. (Perfis que entram via SSO ainda completam esse login no DynoTable.)

Gerenciar conexões

Todo cliente aprovado é listado em Configurações → Servidor MCP. Revogue qualquer um deles a qualquer momento — um cliente revogado é cortado na próxima requisição. Deixar de expor um perfil revoga imediatamente as conexões dele também. Desligar o servidor para tudo.

Segurança

• Somente loopback. O servidor vincula 127.0.0.1; nada fora da sua máquina consegue alcançá-lo.
• Desativado por padrão, aprovação por conexão. Nenhum agente ganha acesso até você habilitar o servidor e aprovar a conexão dele em um escopo que você escolher.
• As credenciais ficam 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 consegue alcançar as tabelas ou credenciais de outro perfil.
• As escritas passam por revisão. Mesmo no Acesso total, as alterações são preparadas para você commitar — o agente não pode escrever no DynamoDB por conta própria.
• Revogável. Revogue um cliente ou desligue o servidor quando quiser.