Snowflake MCP Server: wie KI-Agenten an ein Warehouse andocken

Weil in den Daten nicht steht, was sie bedeuten. Ein Zugang liefert Zeilen und Spalten. Welche Spalte für welche Kennzahl zählt, liefert er nicht.

Ein Team hat einen KI-Agenten an Snowflake angeschlossen, und der Agent antwortet. Er zählt Aufträge, summiert Beträge und sortiert Kunden. Dann fragt jemand nach dem Auftragseingang im letzten Quartal. Der Agent nennt eine Zahl, und im Bericht steht eine andere.

Erklären kann die Zahl niemand. Falsch gerechnet ist sie nicht, denn das SQL dahinter läuft ohne Fehler. Im Warehouse stehen drei Rechenregeln für dieselbe Kennzahl, und der Agent hat eine davon getroffen. Welche gilt, steht in keiner Tabelle.

Deshalb wird ein Data & AI Berater gefragt, was der Agent eigentlich weiß. Er beginnt nicht beim Sprachmodell. Er liest zuerst, was der Agent erreichen kann: die Werkzeuge des Servers und die Rolle dahinter. Dabei zeigen sich vier Lücken. Ein Agent liest keine Dashboards, er liest Definitionen. Was dort nicht steht, erfindet er.

Er kann genau das, was die Werkzeuge des Servers hergeben. MCP, das Model Context Protocol, ist ein offener Standard, über den ein Sprachmodell Werkzeuge findet und aufruft. Welche Werkzeuge es gibt und was sie dürfen, legt der Server fest. Die allgemeine Erklärung steht in MCP erklärt.

Snowflake betreibt diesen Server selbst, ein Team muss nichts installieren. Die Spezifikation des Servers zählt die Werkzeuge auf, die meisten stammen aus Snowflake Cortex. Der Berater liest sie deshalb als Erstes. Die Tabelle zeigt die Werkzeugarten laut Dokumentation von Snowflake, Stand November 2026.

Zwei Dinge fallen dabei auf. Cortex Analyst braucht eine Semantic View, also ein Objekt, das Kennzahlen, Dimensionen und Beziehungen beschreibt. Fehlt sie, bleibt dem Agenten die SQL-Ausführung, und dann rät er aus Spaltennamen. Snowflake empfiehlt für Fachfragen einen Cortex Agent als einzigen Zugang, weil die SQL-Ausführung die Semantic View umgeht.

Das Zweite wiegt schwerer. Kein Werkzeug sagt dem Agenten, woher eine Spalte kommt oder was an ihr hängt. Der Server beantwortet Fragen an die Daten. Fragen an den Aufbau des Warehouse beantwortet er nicht.

Daten abfragen beantwortet, wie viel. Struktur verstehen beantwortet, was gemeint ist, woher es kommt und was daran hängt. Für die erste Aufgabe ist der Snowflake MCP Server gebaut. Für die zweite braucht der Agent die Definitionen des Warehouse, und die stehen im Code. Die Tabelle unter der Kurzantwort zeigt den Unterschied an fünf Fragen.

Der Berater liest deshalb den Code aus. Ein Notebook in Snowflake exportiert die Definitionen der Tabellen und Sichten, mit einer Rolle, die nur lesen darf. Was dabei gelesen wird, steht in Datenqualität messen. Aus dem Export baut ABIS einen Graphen. ABIS führt dabei kein SQL auf Snowflake aus und liest keinen Datensatz.

Eine Abfrage auf dem Graphen findet die drei Rechenregeln für den Auftragseingang. Der Berater sieht, welche Sicht welche Rechenregel nutzt und was daran hängt. Welche Rechenregel gilt, entscheidet der Fachbereich. Danach wird die gültige Rechenregel an einer Stelle gebaut und beschrieben.

Der Agent bekommt denselben Blick. ABIS bringt einen eigenen MCP-Server mit, der lokal läuft. Über ihn liest der Agent den Graphen, die Herkunft einer Spalte und den SQL-Text eines Objekts. Zeilen aus Snowflake bekommt er auf diesem Weg nicht.

Sie hat fünf Glieder: Frage, Struktur, Abfrage, Prüfung, Freigabe. Auf die Reihenfolge kommt es an. Der Agent klärt zuerst, was gemeint ist, und fragt erst danach die Daten ab. So schreibt er SQL gegen eine Definition und nicht gegen einen Spaltennamen.

Dafür hat der Agent zwei Anschlüsse an einem Client. Der eine führt zum Graphen in ABIS, der andere zum Snowflake MCP Server. Abgefragt wird nur aus Datenprodukten, also aus Sichten, die für Auswertungen gebaut und geprüft sind. Was ein Datenprodukt ausmacht, steht in Kapitel 27.

Vor der Freigabe steht die Prüfung. Eine Antwort nennt die Definition, die Quelle und den Stand der Daten. Schlägt der Agent eine Änderung vor, wird der Vorschlag gegen die Regeln des Katalogs geprüft. Eine Regel ist ein Satz mit Zielwert. Wie solche Regeln als Tests laufen, zeigt Datenvalidierung.

Mit einer SQL-Anweisung, einer Anmeldung über OAuth und einer Rolle. Die Einzelheiten ändern sich in diesem Feld schnell. Deshalb stehen sie in der Tabelle, mit Datum, und das Prinzip steht im Text. Die Anweisung selbst zeigt das Beispiel unter der Tabelle.

Drei Grundsätze gelten unabhängig vom Stand. Der Server bietet nur an, was in seiner Spezifikation steht. Der Zugang zum Server ist noch kein Zugang zu einem Werkzeug: Jedes Werkzeug braucht ein eigenes Recht auf das Objekt dahinter. Und die Sitzung läuft mit einer Rolle des Nutzers, der sich anmeldet.

Daneben gab es einen zweiten Weg. Snowflake Labs hat einen Open-Source-Server veröffentlicht, den der Client auf dem eigenen Rechner startet. Er konnte zusätzlich Objekte anlegen und löschen. Das Projekt ist seit Mai 2026 als veraltet markiert und verweist auf den verwalteten Server. Neue Anbindungen baut der Berater deshalb nur dort auf.

Er braucht eine eigene Rolle, und die darf wenig. Der Grund liegt in der Anmeldung: Der Agent arbeitet mit der Rolle des Nutzers, der ihn anmeldet. Richtet eine Entwicklerin den Agenten mit ihrer eigenen Rolle ein, sieht er alles, was sie sieht. Dazu gehören Rohdaten, Testbestände und Spalten mit Personendaten.

Der Berater legt deshalb mit dem Datenteam sechs Regeln fest. Sie folgen einem Satz: weit lesen, eng schreiben. In Snowflake heißt das zunächst, gar nicht zu schreiben. Die Tabelle nennt je Regel die Funktion in Snowflake, Stand November 2026.

Eine Regel verdient einen zweiten Blick. Masking Policies und Row Access Policies wirken zur Laufzeit jeder Abfrage, also auch für die Rolle des Agenten. Was sie ausblenden, fehlt in der Antwort, und zwar ohne Hinweis. Deshalb steht in der Beschreibung des Datenprodukts, welchen Ausschnitt die Rolle sieht.

Ein Mensch, und zwar der, dem das Ergebnis gehört. Der Agent misst, der Mensch entscheidet. Eine Antwort bestätigt die Person, die gefragt hat. Eine Änderung am Code gibt das Datenteam frei, eine Definition der Fachbereich.

In Snowflake kann der Agent mit seiner Rolle nichts ändern. Ein Vorschlag ist deshalb Text: eine Sicht, eine Regel, eine Korrektur. Bevor ihn jemand einbaut, zeigt der Graph, welche Objekte die Änderung berührt. Der Agent kann diese Wirkung in ABIS simulieren, ohne etwas zu ändern.

Auch ein Prüflauf braucht eine Freigabe. Will der Agent in ABIS Objekte prüfen lassen, nennt er vorher Umfang und Grund. Der Lauf startet erst, wenn ein Mensch in ABIS Desktop eine PIN eingibt und bestätigt. Kein Werkzeug nimmt die PIN entgegen, und nach zehn Minuten verfällt die Anfrage.

Soll ein Agent später doch schreiben, gilt eine enge Liste. Erlaubt sind wenige benannte Vorgänge, alles andere wird abgelehnt und protokolliert. Geschrieben wird erst, nachdem die zuständige Person bestätigt und eine zweite freigegeben hat.

Die Grenzen liegen bei der Bedeutung, bei der Rolle und beim Stand der Technik. Der Snowflake MCP Server macht Daten erreichbar. Ob eine Kennzahl fachlich richtig definiert ist, klärt weiter der Fachbereich. Die Angaben zu Snowflake gelten für November 2026.

• Der Agent sieht, was die Rolle sieht. Was eine Policy ausblendet, fehlt ohne Hinweis.
• Cortex Analyst kennt nur, was in der Semantic View steht. Eine fehlende oder falsch beschriebene Kennzahl gleicht kein Sprachmodell aus.
• Der Graph zeigt den Code, wie er exportiert wurde. ABIS hat keine Verbindung zu Snowflake. Nach einer Änderung am Warehouse wird neu exportiert.
• ABIS fragt keine Daten in Snowflake ab. Einen Agenten, der über ABIS SQL auf Snowflake ausführt, gibt es nicht.
• Zwei Server an einem Client brauchen Sorgfalt. Snowflake empfiehlt, die Werkzeuge fremder MCP-Server vor der Nutzung zu prüfen.
• Große Ergebnisse werden gekürzt. Der Agent fragt deshalb Summen und Anteile ab, keine Listen aller Zeilen.