L’écosystème MCP compte plus de 5 800 serveurs communautaires, mais pour le data engineering l’ensemble pertinent est bien plus restreint. Ce sont les serveurs qui donnent aux assistants IA un accès réel à votre infrastructure de données : exécution de requêtes sur l’entrepôt, inspection de schémas, gestion de topics de streaming et accès fédéré à plusieurs bases de données. Plutôt que de construire des intégrations personnalisées pour chaque client IA, ces serveurs fournissent une interface standardisée qui fonctionne dans Claude Desktop, Claude Code, Cursor et tout autre client compatible MCP.
Serveurs spécifiques à un entrepôt
Snowflake
Dépôt : snowflake-labs/mcp Maintenu par : Snowflake Labs (officiel)
Le serveur MCP Snowflake officiel de Snowflake Labs. Il inclut :
- Exécution SQL contre votre entrepôt
- Intégration Cortex AI (les capacités ML et LLM natives de Snowflake)
- Vues sémantiques pour un accès aux données gouverné
- Support RBAC — le serveur respecte vos contrôles d’accès existants
Le RBAC fonctionne via un compte de service : les permissions de ce compte régissent ce que l’IA peut interroger. Il n’y a pas de système de permissions au niveau MCP séparé — le serveur utilise les contrôles d’accès existants de l’entrepôt. Si une table est visible pour le compte de service, l’IA peut la requêter ; sinon, elle ne le peut pas.
L’intégration Cortex AI signifie que vous pouvez combiner des requêtes SQL traditionnelles avec les fonctions ML de Snowflake dans un seul appel d’outil MCP, ce qui est utile pour les équipes qui font du ML dans l’entrepôt ou utilisent Snowpark.
BigQuery
Dépôt : googleapis/genai-toolbox Maintenu par : Google (officiel)
Le MCP Toolbox de Google fournit un accès à BigQuery, Cloud SQL, Spanner et AlloyDB via un seul serveur. L’intégration BigQuery supporte l’exécution de requêtes et l’inspection de schémas. Toolbox gère l’authentification via Application Default Credentials — le même mécanisme utilisé par la bibliothèque client BigQuery — donc pas de configuration d’authentification séparée à gérer.
Pour la configuration détaillée, voir BigQuery MCP Toolbox Setup et Choosing Between BigQuery MCP Options. Si vous avez besoin d’un accès distant (transport HTTP pour un accès partagé en équipe), BigQuery Remote MCP Server Setup couvre le schéma de déploiement sur Cloud Run.
ClickHouse
Dépôt : ClickHouse/mcp-clickhouse Maintenu par : ClickHouse (officiel)
Le serveur officiel ClickHouse supporte l’inspection de schémas et l’exécution de requêtes. Maintenu par l’équipe ClickHouse, il suit les changements d’API et les nouvelles fonctionnalités en parallèle des releases ClickHouse.
Serveurs multi-bases de données
centralmind/gateway
Dépôt : centralmind/gateway Bases de données supportées : PostgreSQL, MySQL, ClickHouse, Snowflake, BigQuery, MSSQL, Oracle, SQLite, ElasticSearch, DuckDB
Ce serveur mérite d’être connu si vous travaillez avec plusieurs bases de données. Un seul serveur gateway fournit un accès MCP à toutes depuis un fichier de configuration et un processus serveur. La configuration mappe les chaînes de connexion à des sources de données nommées ; les outils IA référencent ces noms plutôt que les détails de connexion.
Le scénario pratique : votre équipe utilise PostgreSQL pour la base de données applicative, BigQuery pour l’entrepôt, et ElasticSearch pour la recherche. Plutôt que de configurer trois serveurs MCP séparés dans chaque client de développeur, vous configurez un seul gateway qui connaît les trois. Une entrée dans claude_desktop_config.json, un processus serveur à gérer.
Exemple de configuration :
databases: - name: app_db type: postgresql dsn: "postgresql://user:pass@localhost/app" - name: warehouse type: bigquery project: my-gcp-project dataset: analytics - name: search type: elasticsearch url: "http://localhost:9200"Le gateway traduit les appels d’outils MCP dans le protocole de base de données approprié pour chaque backend. Vous pouvez appliquer des contrôles d’accès au niveau des colonnes et des modes lecture seule par base de données.
MindsDB MCP
Dépôt : mindsdb/mcp Bases de données supportées : PostgreSQL, MySQL, MongoDB, Snowflake, BigQuery
Le serveur MCP de MindsDB fournit un accès en requêtes fédérées — vous pouvez interroger plusieurs bases de données via une interface de type SQL. L’avantage principal par rapport à un simple gateway multi-base de données est la capacité ML intégrée de MindsDB : vous pouvez joindre des tables de bases de données traditionnelles avec des prédictions de modèles ML dans une seule requête.
Pour les équipes qui utilisent déjà MindsDB pour des fonctionnalités ML, le serveur MCP est une extension naturelle. Pour les équipes qui souhaitent simplement un accès multi-base de données, centralmind/gateway est plus simple.
Orchestration et streaming
Databricks MCP
Le serveur MCP Databricks supporte les requêtes SQL via l’API Databricks Statement Execution. Pour les équipes de data engineering utilisant Databricks SQL Warehouses et Databricks Workflows, cela donne aux assistants IA un accès direct en requêtes à votre lakehouse.
Maintenu par la communauté depuis début 2026. Le CLI Databricks fournit une alternative pour certains patterns d’accès — voir CLI vs MCP for AI Agents pour l’analyse des compromis.
confluentinc/mcp-confluent
Dépôt : confluentinc/mcp-confluent Maintenu par : Confluent (officiel)
Le serveur MCP officiel de Confluent expose Kafka et Confluent Cloud via le protocole MCP. Les capacités incluent :
- Lister les topics et inspecter les schémas (intégration Schema Registry)
- Produire et consommer des messages pour les tests ou le débogage
- Accéder aux API REST Confluent Cloud pour la gestion des clusters
Pour le data engineering en streaming, ce serveur ouvre le débogage conversationnel des pipelines Kafka. Plutôt que d’écrire des scripts consommateurs ad hoc pour inspecter un topic, vous demandez à l’IA d’échantillonner des messages et de décrire ce qu’elle trouve. L’intégration Schema Registry signifie que l’IA peut décoder les messages en utilisant le schéma enregistré plutôt que de voir des octets bruts.
Utile pour : déboguer les pipelines où les données n’arrivent pas comme attendu, explorer le contenu des topics en développement, réviser l’évolution du schéma avant de déployer des changements.
Choisir un point de départ
La priorité dépend de ce que vous interrogez le plus :
Un entrepôt principal (Snowflake ou BigQuery) : utilisez le serveur officiel du fournisseur. Snowflake Labs pour Snowflake, le GenAI Toolbox de Google pour BigQuery. Ils offrent la meilleure intégration et une maintenance active du fournisseur.
Plusieurs bases de données : commencez par centralmind/gateway. Un seul serveur gère PostgreSQL, MySQL, BigQuery, et plus. La charge de configuration est faible ; la charge opérationnelle de faire tourner plusieurs serveurs est plus élevée.
Infrastructure de streaming : mcp-confluent si vous êtes sur Confluent Cloud. Pour Kafka auto-géré, un serveur personnalisé construit avec le SDK Python est probablement nécessaire — l’écosystème MCP pour Kafka en dehors de l’écosystème Confluent est limité.
Projets dbt : le serveur MCP dbt ajoute le contexte de lignage et de documentation. Voir dbt MCP Server Setup Hub.
Avant de construire des serveurs personnalisés pour l’un de ces cas, vérifiez Custom MCP Server Decision Criteria — l’écosystème a évolué rapidement, et un serveur existant peut couvrir votre cas d’usage.