DynoTable
Intermédiaire7 min de lecture

Serveur MCP DynamoDB : connecter Claude Code, Cursor et Codex en toute sécurité

Le Model Context Protocol (MCP) permet à un agent IA dans ton terminal ou ton éditeur — Claude Code, Cursor, Codex, VS Code Copilot — d’appeler des outils externes au lieu de deviner. Pointe-en un vers DynamoDB et l’agent peut lire ton schéma, exécuter de vraies requêtes et proposer des éditions, sans que tu colles des extraits de tables dans un chat.

Le hic, c’est ce que tu lui confies. La plupart des façons de relier un agent à DynamoDB donnent au processus du serveur MCP de l’agent tes identifiants AWS bruts et un accès en écriture directe à tes tables. C’est exactement le schéma contre lequel les chercheurs en sécurité mettent en garde : un agent qui peut être manipulé par un résultat d’outil empoisonné ou un document avec injection de prompt, tout en détenant des clés capables d’un DeleteItem en production. Ce guide couvre les deux — la voie sûre et la voie brute — pour que tu choisisses délibérément.

Existe-t-il un serveur MCP pour DynamoDB ?

Oui — et même plusieurs. AWS publie un serveur officiel orienté modélisation des données, et des serveurs communautaires sur npm et PyPI exposent un accès en lecture ou en lecture-écriture en direct. DynoTable fait également office de serveur MCP local. La vraie question n’est pas de savoir si un tel serveur existe, mais quelle puissance tu accordes à l’agent : les serveurs en lecture seule sont raisonnablement sûrs ; ceux capables d’écriture qui détiennent tes identifiants AWS, eux, représentent le risque.

  • Tu veux qu’un agent lise et raisonne sur DynamoDB ? Plusieurs serveurs MCP le font ; ceux en lecture seule sont raisonnablement sûrs.
  • Tu veux qu’un agent modifie des données ? Ne lui donne pas tes clés et un accès en écriture directe. Fais passer les écritures par une étape d’examen pour qu’un humain les valide. C’est le modèle qu’utilise DynoTable, ci-dessous.

La voie sûre : DynoTable comme serveur MCP

DynoTable est un client DynamoDB de bureau qui peut faire office de serveur MCP local. Un agent externe s’y connecte et obtient la même boîte à outils sous autorisation que l’assistant intégré de DynoTable — mais avec deux garanties que les serveurs autonomes n’offrent pas :

  • Tes identifiants AWS n’atteignent jamais l’agent. DynoTable détient tes profils AWS ; l’agent parle à DynoTable, pas à AWS. Rien dans le processus de l’agent ne peut lire tes clés.
  • L’agent ne peut pas écrire directement dans DynamoDB. Chaque changement qu’il propose atterrit dans la fenêtre de validation en staging de DynoTable pour que tu l’examines et le valides. Les agents proposent ; tu valides.

En plus : c’est désactivé par défaut, chaque connexion est approuvée par client à une portée que tu choisis, l’endpoint est en loopback uniquement (127.0.0.1, jamais joignable hors de ta machine), et tout client est révocable.

L’activer et connecter un client

Active le serveur dans Réglages → Serveur MCP. DynoTable lie un port loopback et affiche la commande de connexion exacte. L’endpoint est http://127.0.0.1:<port>/mcp (copie le vrai port depuis le panneau).

Lance la commande depuis le panneau MCP dans ton projet :

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

La première fois qu’un client se connecte, DynoTable affiche une demande de consentement dans l’app, nommant le client et demandant quelle portée accorder — ou refuser :

  • Lecture seule — schéma, requêtes, lectures d’items. Aucun changement.
  • Lecture & staging — ce qui précède, plus la mise en staging de changements pour que tu les examines (jamais une écriture directe).
  • Accès complet — ce qui précède, plus l’ouverture de vues, les filtres et les exports. Les écritures passent toujours par le staging, même ici.

La configuration complète, les portées et le modèle de sécurité se trouvent dans la documentation du serveur MCP.

Les autres options (et leurs compromis)

Elles fonctionnent, mais lis le compromis avant d’en pointer une vers une table de production.

Le serveur MCP DynamoDB officiel d’AWS — modélisation, pas opérations en direct

AWS publie un dynamodb-mcp-server officiel dans awslabs/mcp. Au 2026-06-12, il est orienté vers la modélisation des données et les conseils de conception — conception de schéma, validation contre DynamoDB Local, estimation des coûts — plutôt que vers la lecture/écriture en direct sur tes tables de production. Pour l’accès en direct au plan de données, AWS oriente les utilisateurs vers son serveur MCP général AWS API, qui exécute des appels AWS API/CLI avec tes identifiants AWS configurés. Cela signifie que le processus du serveur de l’agent détient des clés pleins pouvoirs avec un large rayon d’impact et sans étape d’examen propre à DynamoDB. (Vérifie les jeux d’outils actuels sur le dépôt awslabs avant de t’y fier — ces serveurs changent.)

Serveurs communautaires npm/PyPI — lecture seule au mieux, clés brutes au pire

Il existe plusieurs serveurs MCP DynamoDB communautaires sur npm et PyPI ; certains exposent l’ensemble des opérations sur les tables/items, d’autres sont délibérément en lecture seule. Le point commun :

  • Ta clé d’accès AWS et ton secret vivent dans l’environnement du serveur (.env ou config du client), avec toute la puissance IAM de ces clés.
  • Il n’y a aucun consentement par connexion, aucune portée et aucun staging des écritures — ceux en lecture seule te protègent seulement en omettant les outils d’écriture, pas par conception.

Un serveur communautaire en lecture seule est une façon raisonnable et peu risquée de laisser un agent explorer une table. Confier tes clés de production à un serveur capable d’écrire est le schéma risqué.

Est-il sûr de donner à un agent IA un accès à DynamoDB ?

Tout dépend de la voie. L’accès en lecture sur une table non sensible est peu risqué. L’accès en écriture est la vraie question — et la réponse sûre est de ne jamais donner à un agent autonome à la fois tes identifiants et un accès en écriture directe. Soit tu le gardes en lecture seule, soit tu fais passer chaque changement par une étape d’examen qu’un humain approuve. DynoTable fait ce dernier choix : l’agent ne détient jamais tes clés et n’écrit jamais dans DynamoDB ; c’est toi qui valides depuis la fenêtre de staging.

Un agent MCP peut-il écrire dans mes tables DynamoDB ?

Avec un serveur brut capable d’écrire : oui, directement — c’est ça le risque. Avec DynoTable : non, pas directement. En Lecture & staging ou Accès complet, l’agent peut mettre en staging un changement, mais il apparaît comme un diff examinable dans l’app et n’est écrit que lorsque toi tu le valides.

Comment utiliser Claude Code avec DynamoDB ?

Lance le serveur MCP de DynoTable (Réglages → Serveur MCP), puis claude mcp add --transport http dynotable http://127.0.0.1:<port>/mcp dans ton projet, approuve la connexion à la portée que tu veux, et recharge Claude Code. Il peut alors lire ton schéma, exécuter des requêtes et mettre en staging des éditions — sans jamais détenir tes identifiants AWS. Le même schéma fonctionne pour Cursor, VS Code Copilot, Codex et OpenCode (configs ci-dessus).

Voir aussi

Les noms de produits sont des marques de leurs propriétaires respectifs ; référencés à des fins d’identification uniquement. Détails sur les serveurs concurrents et AWS vérifiés le 2026-06-12 — revérifie les dépôts en amont avant de t’y fier.

Mis à jour