Qu’est-ce que Snowflake-managed MCP Server ?
Le serveur MCP officiel de Snowflake tourne dans votre compte Snowflake. Vous le créez avec une instruction SQL (CREATE MCP SERVER ... FROM SPECIFICATION) et une liste YAML d'outils : Cortex Agents, services Cortex Search, Cortex Analyst sur des vues sémantiques, exécution SQL, et vos propres fonctions et procédures. Le serveur communautaire antérieur dans Snowflake-Labs/mcp est déprécié : son README, revérifié le 26 octobre 2026, dit qu'il n'est plus maintenu et oriente les utilisateurs ici, bien que le dépôt ne soit pas archivé.
Les clients se connectent à une URL de compte se terminant par /api/v2/databases/{db}/schemas/{schema}/mcp-servers/{name}, en utilisant Snowflake OAuth ou OAuth externe comme Okta ou Entra ID. Le serveur implémente la révision de protocole MCP 2025-11-25, outils uniquement, et depuis le 20 août 2026 renvoie les réponses tools/call comme un flux SSE, si bien que les clients doivent accepter les réponses JSON et event-stream.
Installer Snowflake-managed MCP Server
CREATE MCP SERVER (in Snowflake), then connect to https://<account_url>/api/v2/databases/<db>/schemas/<schema>/mcp-servers/<name>Snowflake-managed MCP Server vaut-il le coup ?
C'est ainsi qu'une équipe data concevrait le MCP si on le lui demandait. L'accès au serveur n'accorde rien en soi ; chaque outil a besoin de son propre grant, les outils SQL utilisent par défaut SELECT uniquement, et Snowflake conseille explicitement de ne pas mettre de SQL brut sur le même serveur qu'un agent parce que cela laisse un client contourner les garde-fous de l'agent. Les annotations d'outils, comme readOnly ou destructive, sont étiquetées comme des indices et non des contrôles de sécurité, ce qui est une franchise que la plupart des fournisseurs sautent.
L'installation est un travail d'admin. Il n'y a pas d'enregistrement dynamique de client, si bien que chaque client a besoin de sa propre intégration de sécurité OAuth, et la documentation spécifie un client confidentiel pour Cursor et VS Code et un client PKCE public pour Claude Desktop. Chaque utilisateur a aussi besoin d'un DEFAULT_WAREHOUSE ou la session échoue à démarrer, ce qui est le premier ticket de support qu'un déploiement verra.
Les limites documentées sont assez serrées pour façonner la conception. Un serveur contient jusqu'à 50 outils, les réponses SQL et de fonctions sont coupées à 250 Ko, les réponses d'agent peuvent dépasser 200 Ko sauf si max_results est défini, et la récursion s'arrête à 10 appels. Les objets serveur MCP ne sont pas répliqués dans les groupes de bascule, bien que leurs intégrations OAuth le soient, si bien qu'un plan de reprise après sinistre doit les recréer.
Le coût est la partie que Snowflake laisse vague. Il n'y a pas de ligne MCP, mais chaque appel dépense du temps de warehouse ou de la consommation Cortex, et la documentation avertit que les configurations d'agent récursives peuvent produire des boucles non bornées. Une équipe qui budgétise cela devrait le tarifer comme une charge de warehouse supplémentaire d'une nouvelle classe d'utilisateur, parce que c'est exactement ce qu'est un agent.
Là où il fait la différence
Une équipe plateforme data chez un détaillant qui utilise déjà Cortex Analyst
Laisser la finance poser des questions sur le revenu depuis Claude sans accès direct aux tables
Exposez un seul Cortex Agent adossé à une vue sémantique comme unique outil, accordé à un rôle finance. Les analystes obtiennent des réponses avec le SQL généré ; la dépense est le temps de warehouse par question, alors réglez un petit warehouse et un query_timeout.
Un ingénieur analytique dans une équipe data de 10 personnes
Lancer des requêtes SELECT ad hoc depuis Cursor en construisant des modèles dbt
Un serveur MCP séparé avec seulement SYSTEM_EXECUTE_SQL, read_only laissé activé, et un rôle au moindre privilège garde les requêtes exploratoires loin de l'agent face au métier.
Un responsable de la gouvernance des données dans une banque
Approuver l'accès d'un assistant IA aux données clients
Liez l'OAuth externe à Entra ID, réglez OAUTH_USE_SECONDARY_ROLES sur NONE et une ALLOWED_ROLES_LIST restreinte, et n'accordez jamais le rôle d'accès à PUBLIC, tout ce que la documentation de Snowflake recommande.
Avant de vous engager
- Mise en route
- Écrivez une spec YAML, lancez CREATE MCP SERVER, accordez USAGE, puis créez une intégration de sécurité OAuth par client ; les clients documentés sont Claude.ai et Claude Desktop, le mode développeur de ChatGPT et Cursor.
- Intégrations
- Cinq types d'outils : CORTEX_AGENT_RUN, CORTEX_SEARCH_SERVICE_QUERY, CORTEX_ANALYST_MESSAGE, SYSTEM_EXECUTE_SQL et GENERIC pour les UDF et procédures stockées ; jusqu'à 50 outils par serveur.
- Données et confidentialité
- Les requêtes tournent sous le rôle Snowflake de l'utilisateur et ne quittent jamais le compte sauf comme réponses d'outils au client. Snowflake avertit de l'empoisonnement d'outils par des serveurs tiers ; pas encore évalué FedRAMP.
- Coût à grande échelle
- Pas de prix MCP publié ; chaque appel facture le warehouse ou le service Cortex choisi, et la récursion est plafonnée à 10 invocations pour limiter les boucles d'agent emballées.
- Limites
- Plafond de réponse de 250 Ko pour les outils SQL et de fonctions, pas de ressources ni de prompts, pas d'enregistrement dynamique de client, pas de r éplication des objets serveur dans les groupes de bascule.
Les points forts
- Grants par outil et SQL SELECT uniquement par défaut
- Snowflake OAuth ou votre propre fournisseur d'identité
- Expose Cortex Agents, Search et Analyst comme outils
- Rien à héberger ; tourne dans votre compte Snowflake
Les points faibles
- Pas d'enregistrement dynamique de client ; l'admin configure chaque client
- Outils uniquement ; pas de ressources, prompts ou sampling MCP
- Les objets serveur ne sont pas répliqués dans les groupes de bascule
- Chaque appel coûte des crédits de warehouse ou Cortex
Idéal pour
Les clients Snowflake qui veulent un accès d'agent gouverné aux données de warehouse et aux services Cortex sous les rôles existants.
Alternatives à Snowflake-managed MCP Server
Snowflake-managed MCP Server : questions fréquentes
- Snowflake-managed MCP Server vaut-il le coup ?
- La gouvernance faite proprement pour les agents sur Snowflake, payée en heures d'admin et crédits de warehouse plutôt qu'en frais de licence. Nous lui donnons 4.0 sur 5.
- Combien coûte Snowflake-managed MCP Server ?
- Aucun frais MCP séparé n'est publié ; les appels d'outils tournent sur vos warehouses Snowflake et services Cortex, qui facturent comme d'habitude.
- Quels sont les inconvénients de Snowflake-managed MCP Server ?
- Pas d'enregistrement dynamique de client ; l'admin configure chaque client; outils uniquement ; pas de ressources, prompts ou sampling MCP; les objets serveur ne sont pas répliqués dans les groupes de bascule; chaque appel coûte des crédits de warehouse ou Cortex.
- À qui s’adresse Snowflake-managed MCP Server ?
- Les clients Snowflake qui veulent un accès d'agent gouverné aux données de warehouse et aux services Cortex sous les rôles existants.
- Combien coûte Snowflake-managed MCP Server pour une équipe ou en production ?
- Pas de prix MCP publié ; chaque appel facture le warehouse ou le service Cortex choisi, et la récursion est plafonnée à 10 invocations pour limiter les boucles d'agent emballées.
- Snowflake-managed MCP Server est-il sûr pour les données de l’entreprise ?
- Les requêtes tournent sous le rôle Snowflake de l'utilisateur et ne quittent jamais le compte sauf comme réponses d'outils au client. Snowflake avertit de l'empoisonnement d'outils par des serveurs tiers ; pas encore évalué FedRAMP.
- Quelles sont les meilleures alternatives à Snowflake-managed MCP Server ?
- Les alternatives les plus proches que nous avons testées sont ClickHouse MCP Server et MCP Toolbox for Databases.
Réponses vérifiées le 26 oct. 2026.