Serveur MCP

Le Model Context Protocol (MCP) est un standard ouvert qui permet aux agents IA de communiquer avec des outils et des sources de données externes. DynoTable peut faire office de serveur MCP — pour qu’un agent tournant dans ton terminal ou ton éditeur (Claude Code, Cursor, Codex, et d’autres) puisse travailler directement avec tes tables DynamoDB, au lieu que tu copies des schémas et des résultats dans un chat dans un sens puis dans l’autre.

Une fois connecté, l’agent récupère la même boîte à outils sous autorisation que l’assistant intégré — lecture de ton schéma, exécution de requêtes et de lectures d’un seul item, mise en staging de changements à examiner, ouverture de vues, et export — sur un endpoint HTTP local, en loopback uniquement. L’agent découvre tes tables, les interroge, et propose des éditions sans jamais détenir tes identifiants AWS.

Il est désactivé par défaut. L’activer, et chaque connexion individuelle, est explicitement sous ton contrôle — voir Sécurité plus bas.

Activer le serveur

Ouvre Réglages → Serveur MCP et active-le. DynoTable démarre un serveur lié à 127.0.0.1 (loopback uniquement — jamais joignable depuis une autre machine) et affiche la commande de connexion correspondante.

Réglages → Serveur MCP : le serveur tournant sur un port loopback local, avec la liste des clients connectés et leurs niveaux d'accès.

Exposer des profils

Le serveur est activé, mais aucun agent ne peut se connecter tant que tu n’as pas exposé un profil. Ouvre la section MCP d’un profil dans les Réglages et active Exposer via MCP. Chaque profil exposé obtient sa propre commande de connexion — tu peux donc câbler une connexion par profil (par exemple un dynotable-dev et un dynotable-prod), chacune fortement isolée aux identifiants et à la région de ce profil. Une connexion ne voit jamais que les données du profil auquel elle est liée.

Les profils adossés à AWS comme locaux (DynamoDB-Local) peuvent être exposés. Exposer un profil local permet à un agent de piloter tes tables seedées en local via MCP — pratique pour le développement. (Deux profils locaux sur le même port partagent la même base de données locale, donc ils voient les mêmes tables.)

La section MCP d’un profil avec « Exposer via MCP » activé — le bloc de connexion propre au profil affiche l’endpoint à ajouter à ton client.

Connecter un client

DynoTable parle MCP via HTTP streamable, donc n’importe quel agent compatible MCP peut se connecter. Chaque profil exposé affiche sa propre commande de connexion dans sa section MCP — copie-la depuis là. La commande pointe vers http://127.0.0.1:<port>/mcp?profile=<slug> : le ?profile=<slug> indique à DynoTable quel profil tu veux et le pré-sélectionne dans la demande d’approbation (ce n’est qu’une indication — tu confirmes quand même). Mettre le slug du profil dans le nom du serveur (par exemple dynotable-prod) garde distinctes les connexions de deux profils.

Les exemples ci-dessous utilisent prod comme slug ; remplace-le par le slug de ton profil et le vrai port depuis les Réglages.

Lance ceci dans ton projet — c’est la commande exacte affichée dans la section MCP du profil :

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

Ajoute le serveur à .cursor/mcp.json (projet) ou ~/.cursor/mcp.json (global) :

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

Ajoute-le à .vscode/mcp.json (mode agent Copilot) :

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

Ajoute-le à ~/.codex/config.toml :

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

Ajoute-le sous mcp dans opencode.json :

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

Pour connecter un second profil, recommence avec la commande de ce profil (son propre slug). Après la connexion, redémarre ou recharge le client pour qu’il prenne en compte le nouveau serveur.

Approuver la connexion

La première fois qu’un client se connecte, DynoTable affiche une demande de consentement dans l’app. Elle nomme le client qui se connecte, te laisse choisir quel profil la connexion lie (pré-sélectionné depuis l’indication ?profile=, limité à tes profils exposés), et te demande d’accorder une portée — ou de refuser. Rien n’est exposé tant que tu n’as pas approuvé.

Portées

Une portée décide quels outils la connexion peut voir et utiliser. Elles sont cumulatives — chaque niveau inclut les précédents :

Lecture seule — lire ton schéma, exécuter des requêtes, et lire des items. Aucun changement.
Lecture & staging — tout ce qu’il y a dans Lecture seule, plus la mise en staging de changements pour que tu les examines et les valides (l’agent n’écrit jamais directement dans DynamoDB — il passe par le staging).
Accès complet — tout ce qui précède, plus l’ouverture de vues, la définition de filtres, et l’export de résultats. Les écritures passent toujours par le staging — même en Accès complet l’agent ne peut pas écrire directement dans DynamoDB.

La connexion lie le profil que tu approuves dans la demande — ses identifiants et sa région sont épinglés pour toute la durée de la connexion, donc elle lit (et met en staging les écritures vers) exactement les données de ce profil. Le nom du client dans la demande est auto-déclaré par l’agent qui se connecte, donc le profil et la portée que tu approuves sont la vraie barrière, pas le nom.

Si le profil approuvé utilise le MFA, le code à usage unique est demandé à l’agent directement dans sa propre session — pas besoin de revenir dans DynoTable. (Les profils qui se connectent via SSO complètent encore cette connexion dans DynoTable.)

Gérer les connexions

Chaque client approuvé est listé dans Réglages → Serveur MCP. Révoque-en n’importe lequel à tout moment — un client révoqué est coupé à sa prochaine requête. Dé-exposer un profil révoque immédiatement ses connexions aussi. Désactiver le serveur l’arrête entièrement.

Sécurité

Loopback uniquement. Le serveur se lie à 127.0.0.1 ; rien d’extérieur à ta machine ne peut l’atteindre.
Désactivé par défaut, approbation par connexion. Aucun agent n’obtient l’accès tant que tu n’as pas activé le serveur et approuvé sa connexion à une portée que tu choisis.
Les identifiants restent locaux. Les connexions utilisent tes profils AWS existants sur cette machine (Connecter un compte AWS) ; les identifiants ne sont jamais envoyés à l’agent.
Un profil par connexion. Chaque connexion est épinglée au seul profil que tu as approuvé — elle ne peut jamais atteindre les tables ou les identifiants d’un autre profil.
Les écritures passent par un examen. Même en Accès complet, les changements sont mis en staging pour que tu les valides — l’agent ne peut pas écrire dans DynamoDB de lui-même.
Révocable. Révoque un client ou désactive le serveur quand tu veux.