Servidor MCP

El Model Context Protocol (MCP) es un estándar abierto que permite a los agentes de IA comunicarse con herramientas y fuentes de datos externas. DynoTable puede actuar como servidor MCP — de modo que un agente que se ejecuta en tu terminal o editor (Claude Code, Cursor, Codex y otros) puede trabajar directamente con tus tablas de DynamoDB, en lugar de que tú copies esquemas y resultados de un lado a otro en un chat.

Una vez conectado, el agente obtiene el mismo kit de herramientas restringido que usa el asistente integrado — leer tu esquema, ejecutar consultas y lecturas de un solo elemento, preparar cambios para revisión, abrir vistas y exportar — a través de un endpoint HTTP local, solo de loopback. El agente descubre tus tablas, las consulta y propone ediciones sin retener nunca tus credenciales de AWS.

Está desactivado por defecto. Activarlo, y cada conexión individual, está explícitamente bajo tu control — consulta Seguridad más abajo.

Habilitar el servidor

Abre Ajustes → Servidor MCP y actívalo. DynoTable inicia un servidor enlazado a 127.0.0.1 (solo loopback — nunca accesible desde otra máquina) y muestra el comando de conexión correspondiente.

Ajustes → Servidor MCP: el servidor ejecutándose en un puerto de loopback local, con la lista de clientes conectados y sus niveles de acceso.

Exponer perfiles

El servidor está activado, pero ningún agente puede conectarse hasta que expongas un perfil. Abre la sección MCP de un perfil en Ajustes y activa Exponer mediante MCP. Cada perfil expuesto obtiene su propio comando de conexión — así puedes configurar una conexión por perfil (p. ej. un dynotable-dev y un dynotable-prod), cada uno aislado de forma estricta a las credenciales y la región de ese perfil. Una conexión solo ve los datos del perfil al que está enlazada.

Se pueden exponer tanto perfiles respaldados por AWS como locales (DynamoDB-Local). Exponer un perfil local permite que un agente maneje tus tablas locales con datos de prueba a través de MCP — útil para desarrollo. (Dos perfiles locales en el mismo puerto comparten la misma base de datos local, así que ven las mismas tablas.)

La sección MCP de un perfil con «Exponer mediante MCP» activado — el bloque de conexión por perfil muestra el endpoint que debes añadir a tu cliente.

Conectar un cliente

DynoTable habla MCP a través de streamable HTTP, así que cualquier agente compatible con MCP puede conectarse. Cada perfil expuesto muestra su propio comando de conexión en su sección MCP — cópialo desde ahí. El comando apunta a http://127.0.0.1:<port>/mcp?profile=<slug>: el ?profile=<slug> le indica a DynoTable qué perfil quieres y lo preselecciona en el aviso de aprobación (es solo una sugerencia — aun así tú lo confirmas). Usar el slug del perfil en el nombre del servidor (p. ej. dynotable-prod) mantiene distintas las conexiones de dos perfiles.

Los ejemplos de abajo usan prod como slug; sustitúyelo por el slug de tu perfil y el puerto real de Ajustes.

Ejecuta esto en tu proyecto — es el comando exacto que se muestra en la sección MCP del perfil:

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

Añade el servidor a .cursor/mcp.json (proyecto) o ~/.cursor/mcp.json (global):

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

Añádelo a .vscode/mcp.json (modo agente de Copilot):

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

Añádelo a ~/.codex/config.toml:

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

Añádelo bajo mcp en opencode.json:

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

Para conectar un segundo perfil, repite con el comando de ese perfil (su propio slug). Tras conectarte, reinicia o recarga el cliente para que detecte el nuevo servidor.

Aprobar la conexión

La primera vez que un cliente se conecta, DynoTable muestra un aviso de consentimiento dentro de la app. Nombra al cliente que se está conectando, te deja elegir a qué perfil se enlaza la conexión (preseleccionado a partir de la sugerencia ?profile=, limitado a tus perfiles expuestos) y te pide que concedas un ámbito — o que lo deniegues. No se expone nada hasta que apruebas.

Ámbitos

Un ámbito decide qué herramientas puede ver y usar la conexión. Son acumulativos — cada nivel incluye los anteriores:

Solo lectura — leer tu esquema, ejecutar consultas y leer elementos. Sin cambios.
Lectura y preparación — todo lo de Solo lectura, más preparar cambios para que los revises y confirmes (el agente nunca escribe en DynamoDB directamente — pasa por preparación).
Acceso total — todo lo anterior, más abrir vistas, establecer filtros y exportar resultados. Las escrituras siguen pasando por preparación — incluso con Acceso total el agente no puede escribir en DynamoDB directamente.

La conexión queda enlazada al perfil que apruebas en el aviso — sus credenciales y región quedan fijadas durante toda la vida de la conexión, de modo que lee (y prepara escrituras hacia) exactamente los datos de ese perfil. El nombre del cliente en el aviso lo declara el propio agente que se conecta, así que el perfil y el ámbito que apruebas son la verdadera barrera, no el nombre.

Si el perfil aprobado usa MFA, se le pide al agente el código de un solo uso directamente en su propia sesión — sin necesidad de volver a DynoTable. (Los perfiles que inician sesión mediante SSO siguen completando ese inicio de sesión en DynoTable.)

Gestionar conexiones

Cada cliente aprobado aparece en Ajustes → Servidor MCP. Revoca cualquiera de ellos en cualquier momento — un cliente revocado queda cortado en su siguiente solicitud. Dejar de exponer un perfil revoca de inmediato sus conexiones también. Apagar el servidor lo detiene todo.

Seguridad

Solo loopback. El servidor se enlaza a 127.0.0.1; nada fuera de tu máquina puede alcanzarlo.
Desactivado por defecto, aprobación por conexión. Ningún agente obtiene acceso hasta que habilitas el servidor y apruebas su conexión con un ámbito que tú eliges.
Las credenciales se quedan en local. Las conexiones usan tus perfiles de AWS existentes en esta máquina (Conectar con AWS); las credenciales nunca se envían al agente.
Un perfil por conexión. Cada conexión queda fijada al único perfil que aprobaste — nunca puede alcanzar las tablas ni las credenciales de otro perfil.
Las escrituras pasan por revisión. Incluso con Acceso total, los cambios se preparan para que tú los confirmes — el agente no puede escribir en DynamoDB por su cuenta.
Revocable. Revoca un cliente o apaga el servidor cuando quieras.