Googles MCP Toolbox: KI-Agenten greifen per Java auf Datenbanken zu

Von /
Workflow-Diagramm: Java-Anwendung greift per MCP Toolbox auf eine Datenbank zu

Google hat das Java-SDK seiner MCP Toolbox for Databases in Version 1.0 veröf­fent­licht. Java-Anwendungen können KI-Agenten damit über das Model Context Protocol (MCP) auf Datenbanken wie PostgreSQL, Oracle oder MySQL zugrei­fen lassen. Für Betreiber gewach­se­ner Systemlandschaften rückt damit vor allem eine Frage in den Vordergrund: Wer darf über den Agenten welche Daten sehen?

MCP ist ein offe­ner Standard, über den KI-Anwendungen externe Werkzeuge und Datenquellen einheit­lich anspre­chen. Die MCP Toolbox for Databases ist ein quell­of­fe­ner MCP-Server von Google, der zwischen KI-Agenten und Datenbanken vermit­telt. Über das Java-SDK als Client-Bibliothek gelan­gen die auf dem Server defi­nier­ten Werkzeuge in Java-Anwendungen und von dort zum Agenten.

Was die MCP Toolbox leistet

Gestartet ist das Projekt als »Gen AI Toolbox for Databases«, noch vor MCP. Die Projektseite nennt neben Google-Cloud-Diensten wie AlloyDB, BigQuery, Cloud SQL und Spanner auch PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, MongoDB, Redis, Elasticsearch, Snowflake und weitere.

Zentral ist die Konfigurationsdatei tools.yaml. Jedes dort beschrie­bene Werkzeug steht für eine para­me­tri­sierte Abfrage, die der Agent nutzen darf. Statt selbst SQL zu schrei­ben, entschei­det das Sprachmodell nur, welches Werkzeug passt, und setzt die Parameterwerte ein. Daneben gibt es gene­ri­sche Werkzeuge wie list_tables oder execute_sql, die Google für die Datenexploration aus Entwicklungsumgebungen vorsieht.

Die Dokumentation warnt zudem: Sogenannte Template-Parameter werden vor der Ausführung direkt in das SQL-Statement einge­setzt und sind anfäl­lig für SQL-Injection. Google empfiehlt einfa­che Parameter und für Template-Parameter eine Liste erlaub­ter Werte.

Java-SDK 1.0: Was neu ist und was noch fehlt

Version 1.0.0 des SDK erschien laut GitHub am 9. September 2026, die offi­zi­elle Ankündigung im Google Cloud Blog folgte am 7. Oktober. Google bezeich­net die Version als stabile Grundlage für Unternehmensanwendungen. Wichtige Änderungen laut Release Notes und Ankündigung:

  • Gebundene Parameter: Legt die Anwendung einen Wert selbst fest, etwa die ID des ange­mel­de­ten Nutzers oder Mandanten, blen­det das SDK diesen Parameter aus der Werkzeugbeschreibung für das Sprachmodell aus. Das Modell kann ihn damit nicht verän­dern. Das ist ein Breaking Change gegen­über Version 0.2.
  • Authentifizierung: Die Anmeldung des Clients am Toolbox-Server steckt in eige­nen Schnittstellen. Googles Application Default Credentials sind einge­baut, eigene Token-Quellen möglich. Werden Zugangsdaten unver­schlüs­selt per HTTP über­tra­gen, warnt das SDK zur Laufzeit.
  • Hooks und Standardwerte: Vor und nach jedem Werkzeugaufruf lassen sich eigene Funktionen ausfüh­ren, Parameter können Standardwerte erhal­ten.

Mindestvoraussetzung ist Java 17, ab Java 21 lassen sich virtu­elle Threads nutzen. Laut Repository reicht der Funktionsumfang noch nicht an die SDKs für Python, JavaScript/TypeScript und Go heran; welche Funktionen fehlen, nennt Google nicht. Fertige Integrationspakete für Frameworks wie LangChain oder Googles Agent Development Kit gibt es nach Angaben von heise bislang nur für andere Sprachen.

Was bedeutet das konkret?

Die Toolbox ist ein Baustein für Entwickler und Integratoren, kein Werkzeug für Endanwender. Für Unternehmen und Medienhäuser erge­ben sich drei Punkte:

  • Kontrollierter Zugriff wird einfa­cher: Statt einem Agenten freie Abfragen zu erlau­ben, lassen sich genau defi­nierte Abfragen frei­ge­ben, zum Beispiel »Artikel einer Ausgabe nach Status« oder »Bestellungen eines Kunden«.
  • Berechtigungen blei­ben die Hauptaufgabe: Ein Agent liest das, was der Datenbankbenutzer des Toolbox-Servers lesen darf. Ist dieser Benutzer zu weit berech­tigt, hilft auch die beste Werkzeugdefinition nur begrenzt.
  • Herstellerdatenbanken sind ein Sonderfall: Redaktionssysteme, DAM- oder Planungssysteme spei­chern ihre Daten oft in Strukturen, die der Hersteller nicht als Schnittstelle vorsieht. Direkte Abfragen darauf können Supportansprüche berüh­ren und bei Updates brechen.

Wie real das Risiko ist, zeig­ten Sicherheitsforscher im Juli 2025 am MCP-Server von Supabase, nicht an der Google-Toolbox: In ihrem Szenario las ein weit­rei­chend berech­tig­ter Agent Support-Tickets mit einge­schleus­ten Anweisungen und schrieb darauf­hin vertrau­li­che Zugangsdaten in ein für den Angreifer sicht­ba­res Ticket. Der Entwickler Simon Willison beschreibt das Muster als Kombination aus Zugriff auf private Daten, nicht vertrau­ens­wür­di­gen Inhalten und einem Weg nach außen.

Unsere Einordnung: Erst Rechte klären, dann die MCP Toolbox anbinden

Die Richtung der Toolbox ist aus unse­rer Sicht rich­tig: vorde­fi­nierte Abfragen, server­sei­tig gebun­dene Parameter und getrennte Authentifizierung entspre­chen dem Prinzip der mini­ma­len Rechte (Least Privilege). Bevor Sie einen Agenten an produk­tive Daten anbin­den, soll­ten Sie dennoch einige Fragen klären:

  • Datenzugang: Eigener, nur lesen­der Datenbankbenutzer, möglichst auf dedi­zierte Sichten (Views) oder ein Replikat statt auf die Produktivdatenbank.
  • Werkzeugzuschnitt: Nur die Abfragen frei­ge­ben, die ein Anwendungsfall wirk­lich braucht. Generische Werkzeuge wie execute_sql gehö­ren in Testumgebungen, nicht in den Betrieb.
  • Nutzerbezug: Nutzer- oder Mandantenkennungen server­sei­tig binden, nicht vom Modell über­ge­ben lassen.
  • Nachvollziehbarkeit: Werkzeugaufrufe proto­kol­lie­ren und regel­mä­ßig auswer­ten.
  • Schnittstellen der Hersteller: Bei Redaktionssystemen und DAM vorhan­dene APIs prüfen, bevor Sie direkt auf deren Datenbanken zugrei­fen.

Einen Überblick zur Einführung gibt unser Beitrag KI im Mittelstand: Fahrplan für Agenten & Automatisierung. Bei der Einbindung von KI-Agenten in bestehende Systemlandschaften unter­stüt­zen wir im Rahmen von CONSULT + CONNECT mit Beratung und Systemintegration.

Mit Version 1.0 ist das Java-SDK nutz­bar, der Funktionsumfang wächst aber noch; für produk­tive Projekte entschei­det weni­ger das SDK als das Berechtigungskonzept dahin­ter.

Quellen

Wie können wir Sie unter­stüt­zen?

Kostenloses Erst-Gespräch

Lassen Sie uns gemein­sam prüfen, wo in Ihren Kommunikations‑, Marketing- oder Unternehmensprozessen konkrete Effizienzpotenziale liegen.

– Henning Bartens, Co-CEO

Termin verein­ba­ren


Strukturiert. Ehrlich. Informativ.

Nach oben scrollen