Postgres pour Agents IA

Ce que contient ce pack

Ce pack rassemble les cinq surfaces SQL dont un agent a réellement besoin pour lire, écrire et raisonner sur une base Postgres. Deux sont des serveurs MCP stdio que vous pointez vers votre DSN. Un est un MCP universel qui gère Postgres, MySQL, SQLite et plus. Les deux derniers sont des fournisseurs Postgres managés avec intégration agent de premier ordre.

Le serveur PostgreSQL MCP de référence vit dans le repo officiel modelcontextprotocol/servers et c'est le binding stdio le plus simple : query, list_tables, describe_table. La variante communautaire ajoute explain, index_advice et écritures paramétrées. DBHub abstrait la couche de connexion pour qu'une installation MCP atteigne Postgres, MySQL, SQLite ou DuckDB. Neon et Supabase livrent leurs propres MCPs qui vont au-delà du SQL brut — Neon expose la création de branche comme outil (une DB par tâche d'agent), Supabase expose auth, storage et Row Level Security.

Pourquoi Postgres pour agents compte

La plupart des démos « agent + base de données » trichent. Elles utilisent un SQLite éphémère, des fixtures faites main, zéro concurrence. Les vraies apps tournent sur Postgres avec des centaines de tables, des policies RLS, des colonnes JSON et un connection pooling existant. Brancher un LLM sur cette surface naïvement, c'est comme ça qu'on finit avec un DELETE sans WHERE en production.

Ce pack choisit les cinq serveurs qui gèrent les réalités :

• Mode lecture seule par défaut. Les cinq livrent avec des flags read-only ou un scoping de capacités.
• Introspection de schéma. L'agent peut demander describe_table au lieu de deviner les colonnes.
• Connection pooling. Chaque serveur réutilise un pool — pas de tempête de reconnexion par requête.
• Branch / sandbox. L'outil de branche Neon donne à chaque tâche d'agent sa propre base jetable en 200ms.

Installer en une commande

# Installation pack — écrit les configs MCP dans le config file de votre outil
tokrepo install pack/postgres-for-agents

# Ou choisir des serveurs individuels
tokrepo install postgres-mcp
tokrepo install dbhub
tokrepo install neon-mcp
tokrepo install supabase-mcp

Le TokRepo CLI écrit le config au bon endroit pour chaque outil — claude_desktop_config.json pour Claude Code, mcp.json pour Cursor, AGENTS.md pour Codex CLI. Les connection strings vivent dans vos env vars ; les configs ne portent que les noms de serveur.

Pièges courants

• N'exposez pas l'écriture le jour 1. Commencez avec --read-only. Promouvez en read-write seulement après avoir vu l'agent exécuter quelques centaines de lectures sereinement.
• Utilisez un rôle dédié, pas le superuser postgres. Créez un rôle mcp_agent avec SELECT sur les schémas que vous voulez réellement exposer. Les policies RLS doivent s'appliquer à ce rôle aussi.
• Surveillez le coût du schema dump. list_tables sur un schéma de production de 500 tables peut faire exploser le contexte de l'agent. Filtrez à un seul schéma ou une allow-list.
• Le branching ne sécurise que si vous l'utilisez vraiment. Les branches Neon sont peu chères — créez-en une par tâche, pointez le MCP vers le DSN de la branche, jetez après.
• Le RLS Supabase n'est pas optionnel. Si l'agent se connecte avec la service role key, le RLS est contourné. Utilisez anon + JWT pour toute tâche touchant aux données utilisateur.

Relation avec d'autres packs

Ce pack est la couche données structurées. Pour la recherche sémantique / non structurée (similarité, RAG sur documents) vous voulez le pack Comparatif Vector DB — Chroma, Qdrant, Weaviate, Pinecone. Pour le toolbox MCP plus large (filesystem, browser, GitHub) voir Stack de Serveurs MCP. Les agents en production utilisent typiquement un élément de chaque pack : Postgres pour l'état transactionnel, vector DB pour les embeddings, MCP stack pour les surfaces d'outils.