Snowflake MCP Server einrichten
Snowflake-managed MCP Server per SQL anlegen, Werkzeuge wie Cortex Analyst und Cortex Search auswählen und einen MCP-Client sicher per OAuth oder PAT verbinden.
- Skill Road
- Snowflake MCP Server einrichten
Veröffentlicht am 18.09.2026
Der Snowflake-managed MCP Server ist kein Programm zum Herunterladen, sondern ein Datenbankobjekt innerhalb eines Snowflake-Accounts. Diese Anleitung zeigt die grundlegenden Schritte von der Erstellung bis zur ersten Verbindung mit einem KI-Client.
Voraussetzungen
Du brauchst einen bestehenden Snowflake-Account und eine Rolle mit dem Recht CREATE MCP SERVER auf dem Ziel-Schema sowie USAGE-Rechten auf die Objekte, die der Server später anbieten soll – etwa eine Semantic View für Cortex Analyst, eine Cortex-Search-Instanz oder ein Warehouse für SQL-Ausführung.
Server per SQL anlegen
Der Server wird mit einer YAML-Spezifikation erzeugt, die die verfügbaren Werkzeuge auflistet:
CREATE OR REPLACE MCP SERVER mein_server
FROM SPECIFICATION
$$
tools:
- name: "kennzahlen_abfragen"
identifier: "meine_db.mein_schema.meine_semantic_view"
type: "CORTEX_ANALYST_MESSAGE"
description: "Fragen zu Umsatz- und Kennzahlen in natürlicher Sprache beantworten."
title: "Kennzahlen"
$$;
Weitere Werkzeugtypen sind CORTEX_SEARCH_SERVICE_QUERY für unstrukturierte Suche, SYSTEM_EXECUTE_SQL für direkte SQL-Ausführung, CORTEX_AGENT_RUN für einen bestehenden Cortex Agent und GENERIC für eigene Funktionen oder Stored Procedures. Ein Server erlaubt laut Dokumentation bis zu 50 Werkzeuge insgesamt.
Endpunkt und Authentifizierung
Der Server ist danach unter https://<account>.snowflakecomputing.com/api/v2/databases/<datenbank>/schemas/<schema>/mcp-servers/<servername> erreichbar. Für den produktiven Betrieb ist Snowflakes eigenes OAuth 2.0 der Standardweg; für einen schnellen ersten Test eignet sich ein Programmatic Access Token (PAT), das als Bearer-Token im Client hinterlegt wird. Nutze in Hostnamen Bindestriche statt Unterstriche, um Verbindungsprobleme zu vermeiden.
Mit einem MCP-Client verbinden
In einem CLI-Client wie Claude Code lässt sich der Server testweise mit einem Befehl nach diesem Muster registrieren, wobei die spitzen Klammern durch die eigenen Werte ersetzt werden:
claude mcp add --transport http snowflake https://<account>.snowflakecomputing.com/api/v2/databases/<datenbank>/schemas/<schema>/mcp-servers/<servername>
Beim Verbinden fragt der Client nach dem Bearer-Token beziehungsweise startet den OAuth-Ablauf, je nachdem, wie der Server auf Account-Ebene konfiguriert ist.
Rechte eng fassen
Lege für den MCP-Zugriff eine eigene, eng zugeschnittene Rolle an, statt eine bestehende, breit berechtigte Rolle wiederzuverwenden. Das gilt besonders für das Werkzeug SYSTEM_EXECUTE_SQL, weil ein Agent damit modellgeneriertes SQL gegen echte Daten ausführt. Prüfe vor der Freigabe, welche Tabellen, Semantic Views und Search-Instanzen die Rolle tatsächlich sehen darf.
Einrichtung testen
Stelle im Client zunächst eine einfache, lesende Frage, die zum konfigurierten Werkzeug passt, etwa eine Kennzahlenfrage bei Cortex Analyst. Antwortet der Agent mit einem plausiblen, auf echten Daten basierenden Ergebnis statt mit einem Berechtigungs- oder Verbindungsfehler, ist die Einrichtung korrekt.
Typische Stolperfallen
Ein häufiger Fehler ist ein Unterstrich statt eines Bindestrichs im Accountnamen des Endpunkts – das führt zu TLS- oder Verbindungsfehlern, weil Snowflake in Hostnamen konsequent Bindestriche verwendet. Ein zweiter Stolperstein sind fehlende Rechte auf referenzierte Objekte: Steht die Semantic View oder Cortex-Search-Instanz in einem anderen Schema als der Server, braucht die Rolle zusätzlich USAGE auf dieses Schema, sonst schlägt bereits das Anlegen mit CREATE OR REPLACE MCP SERVER fehl. Reagiert ein Werkzeug mit einer leeren oder unplausiblen Antwort statt mit einem Fehler, lohnt sich ein Blick in die zugrunde liegende Semantic View oder Cortex-Search-Konfiguration – oft liegt es an einer unvollständigen semantischen Modellierung und nicht an der MCP-Anbindung selbst. Wer mehrere Anwendungsfälle abdecken will, sollte außerdem eher mehrere schlanke Server mit klar getrennten Werkzeugen anlegen als einen einzigen Server mit vielen unterschiedlichen Tool-Typen, weil das die spätere Rechtevergabe und Fehlersuche deutlich vereinfacht.
Häufige Fragen
Läuft der Snowflake MCP Server lokal oder muss ich ihn selbst hosten?
Weder noch: Er ist ein Feature der Snowflake-Plattform und läuft vollständig innerhalb deines Snowflake-Accounts. Es gibt keine lokale Installation und keinen eigenen Server-Prozess zu betreiben.
Brauche ich zwingend einen bezahlten Snowflake-Account?
Ja, der MCP-Server setzt einen bestehenden Snowflake-Account voraus und verursacht reguläre Warehouse- und Cortex-Verbrauchskosten. Ohne Snowflake-Nutzung lässt er sich nicht sinnvoll einsetzen.
Was ist der Unterschied zum älteren Snowflake-Labs/mcp-Projekt auf GitHub?
Snowflake-Labs/mcp war ein quelloffenes Community-Projekt zum lokalen Selbstbetrieb. Es gilt laut eigenem Repository als nicht mehr gepflegt; Snowflake empfiehlt stattdessen den hier beschriebenen gehosteten, verwalteten Server.
Kann ein Agent über den Server beliebiges SQL ausführen?
Nur wenn ein `SYSTEM_EXECUTE_SQL`-Werkzeug konfiguriert ist, und auch dann nur mit den Rechten der verbundenen Rolle. Für sensible Umgebungen empfiehlt sich eine eigene, eng begrenzte Rolle statt einer bestehenden, breit berechtigten.
Wie viele Werkzeuge kann ein einzelner Server anbieten?
Laut Dokumentation bis zu 50 Werkzeuge über alle unterstützten Typen (Cortex Analyst, Cortex Search, SQL-Ausführung, Cortex Agent, generische Funktionen) hinweg.