MCP

PostgreSQL MCP : d'abord voir la structure des tables, puis exécuter une requête en lecture seule

Pour qui doit inspecter un schema PostgreSQL ou exécuter du SQL en lecture seule ; il faut fournir soi-même la chaîne de connexion. Une transaction en lecture seule lit encore la base et peut porter un mot de passe : ce n'est pas un risque zéro.

Official source · modelcontextprotocol/server-postgres

Install

npx -y @modelcontextprotocol/server-postgres postgresql://localhost/mydb

À qui ça s'adresse

Pour faire inspecter à un modèle la structure des tables d'une base PostgreSQL et lui faire exécuter du SQL en lecture seule. Les preuves indiquent : ce MCP fournit un accès en lecture seule à PostgreSQL, pour inspecter le schema et exécuter des requêtes en lecture seule.

Tu dois pouvoir fournir une URL postgresql:// joignable, et accepter que le modèle lise les structures de tables et les résultats. Une transaction en lecture seule n'est pas un « risque zéro » : elle se connecte encore, lit encore des données, et l'URL peut porter un nom d'utilisateur et un mot de passe.

Les preuves ne listent pas les clients. La page officielle est dans l'arbre servers-archived ; les preuves n'indiquent pas à part l'état de maintenance. Ne suppose pas que c'est encore l'implémentation principale recommandée.

Premier essai en 3 minutes

Prends le chemin principal NPX ; ne fais pas de Docker l'installation principale. Dans la configuration MCP du client, utilise :

"command": "npx",
"args": [
  "-y",
  "@modelcontextprotocol/server-postgres",
  "postgresql://localhost/mydb"
]

Remplace la dernière URL par une base à laquelle tu as un droit d'accès en lecture seule. Le nom d'utilisateur et le mot de passe peuvent s'écrire comme dans les preuves : postgresql://user:password@host:port/db-name. Ne colle pas un compte d'écriture de production ni un mot de passe complet dans la conversation.

Prérequis : la machine a npx ; la base autorise les connexions depuis ce processus ; la première fois, inspecte seulement le schema ou exécute une requête qui ne change pas les données.

Emplacement : command / args du serveur MCP du client. Le troisième argument est la chaîne de connexion.

Premier appel à faible risque : d'abord lire la ressource postgres://<host>/<table>/schema pour voir les noms et types de colonnes d'une table ; ou appeler l'outil query avec une chaîne sql — les preuves garantissent l'exécution dans une transaction READ ONLY. N'essaie pas INSERT/UPDATE/DELETE pour « vérifier la lecture seule ».

Signal de succès : une fois le client connecté, il peut lister les ressources de schema de table, ou query renvoie un résultat en lecture seule. Si la connexion échoue, change d'abord l'URL (base locale, port, nom de base) ; ne passe pas à Docker pour deviner. Pour Docker, les preuves ajoutent seulement : sous macOS, si le service est sur l'hôte, utilise host.docker.internal.

Cas d'usage

Cas 1 : savoir quelles colonnes a une table. Lis postgres://<host>/<table>/schema. Les preuves indiquent que c'est un JSON schema découvert automatiquement depuis les métadonnées, avec noms de colonnes et types. Il n'y a pas d'API d'énumération des noms de tables ; remplace <host> et <table> selon ta connexion réelle. N'invente pas les tables invisibles.

Cas 2 : exécuter une requête en lecture seule sur une table dont l'existence est déjà confirmée. Appelle query ; le seul paramètre est sql. Les preuves garantissent l'exécution dans une transaction READ ONLY ; elles ne documentent ni pagination, ni délai, ni l'étendue du dialecte SQL exécutable. Tu peux confirmer seulement : ce SQL part comme requête en lecture seule vers la base déjà connectée. Ne suppose pas pouvoir écrire des tables temporaires ou appeler des fonctions qui changent l'état.

Limites d'usage

C'est un accès en lecture seule, pas une écriture annulable : les preuves ne donnent pas d'undo. La chaîne de connexion peut contenir un mot de passe — exposition des identifiants et du plan de données. Le seul outil est query. Docker et NPX sont des chemins différents ; le chemin principal reste NPX. Les preuves ne documentent ni pool de connexions, ni SSL, ni imposition d'un rôle lecture seule, et elles ne disent pas qu'une transaction READ ONLY bloque tous les effets de bord (certaines fonctions SQL peuvent encore avoir des effets externes, mais la page ne développe pas). La page est dans un arbre de dépôt archivé ; les preuves ne fournissent ni paquet de remplacement ni note de migration.