Googles Java-Client für MCP Toolbox for Databases erreichte am 9. September Version 1.0.0. In einer Ankündigungvom 6. Oktober erläuterte das Unternehmen Änderungen an Transport, Authentifizierung und Werkzeugparametern für Teams, die Java-Anwendungen mit einem separat laufenden Toolbox-Server verbinden. Der Release-Eintrag datiert die Veröffentlichung des Codes fast einen Monat vor dieser Ankündigung.

Der Unterschied ist für ein Java-Team wichtig, das über eine Einführung des Clients entscheidet. Google bezeichnet 1.0 als stabile, abwärtskompatible Grundlage, doch derselbe Release-Eintrag nennt eine inkompatible Änderung: Gebundene Parameter werden aus der Werkzeugdefinition entfernt, die einem Agenten angezeigt wird. Bestehende Integrationen sollten vor einem Upgrade prüfen, wie sie diese Definitionen verwenden. Googles Repository weist außerdem darauf hin, dass die Java-Funktionen noch weiterentwickelt werden und nicht dem Stand der Python-, JavaScript/TypeScript- und Go-SDKs entsprechen.

Die wesentliche Änderung

Der 1.0-Client bietet einer Java-Anwendung einen festgelegten Weg, die von MCP Toolbox bereitgestellten Werkzeuge zu entdecken und aufzurufen. Das neue HttpMcpTransport liegt hinter einer Transportschnittstelle, während CredentialsProvider und AuthMethods die Auflösung von Zugangsdaten vom Client trennen. Google zufolge werden Zugangsdaten für jede Anfrage asynchron aufgelöst. Der Release ergänzt außerdem Standardwerte für Parameter, HTTP-Warnungen zur Offenlegung von Zugangsdaten, Versionsauswahl, Sitzungsverfolgung und eine Zuordnung für benutzerdefinierte Anfrage-Header. Das sind dokumentierte SDK-Funktionen, keine Leistungs- oder Sicherheitsprüfung von BIG CHANGE.

Toolbox ist selbst ein separater Server. Ein Betreiber konfiguriert ihn mit Datenquellen und Werkzeugen; der Java-Client verbindet sich mit dessen URL, lädt Werkzeugdefinitionen und sendet Aufrufe. Eine Java-Abhängigkeit allein konfiguriert keine Datenbank, erteilt keine Berechtigungen und stellt den Server nicht bereit. Die offizielle Java-Dokumentation beschreibt die Rollen von Client und Server; das SDK-Repository setzt voraus, dass der Server vor der Clienteinrichtung läuft.

Was ein Java-Team prüfen kann

Der folgende Ablauf stützt sich auf Googles Dokumentation und Repository. BIG CHANGE hat den Code nicht ausgeführt und keine Datenbank verbunden.

  1. Richten Sie einen separaten Toolbox-Server und eine Datenquelle ein. Googles Einstiegsdokumentation behandelt Server, Werkzeugdefinitionen und unterstützte Integrationen. Wählen Sie für die erste Prüfung ein eng begrenztes, schreibgeschütztes Datenbankwerkzeug und prüfen Sie die Zugriffskontrollen des Servers. Das SDK-Repository nennt Java 17 oder neuer als Basislaufzeit.
  2. Fixieren Sie die Java-Abhängigkeit. Sowohl die Ankündigung des 1.0-Releases als auch das Repository zeigen Maven-Koordinaten com.google.cloud.mcp:mcp-toolbox-sdk-java:1.0.0; das Repository enthält auch die Gradle-Form. Die allgemeine Java-Dokumentation verwendet weiterhin einen VERSION Platzhalter. Für diese Prüfung ist deshalb das Release-Artefakt die genaue Referenz.
  3. Verbinden Sie sich mit dem Server und prüfen Sie ein Werkzeug. Richten Sie McpToolboxClient auf die URL des laufenden Servers /mcp und verwenden Sie anschließend loadToolset, listTools oder loadTool , um die veröffentlichten Definitionen vor einem Aufruf zu prüfen. Das Repository zeigt einen Aufruf mit Java Map und ein zurückgegebenes Textergebnis. Eine erfolgreiche Prüfung ist die Antwort eines benannten, konfigurierten Werkzeugs und nicht bloß ein fehlerfrei erzeugtes Clientobjekt.
  4. Wählen Sie die Authentifizierung bewusst. Die 1.0-Ankündigung beschreibt CredentialsProvider und AuthMethods für Client-Zugangsdaten, darunter einen Google-Application-Default-Credentials-Weg für OIDC. Sie beschreibt auch HTTP-Warnungen, wenn Zugangsdaten unverschlüsselt übertragen würden. Eine Warnung ersetzt weder einen HTTPS-Endpunkt noch eine serverseitige Autorisierung. Gebundene Werte sensibler Parameter sollten an der Server- und Clientgrenze überprüft werden, insbesondere beim Upgrade von einem Vorab-Build.

Zu erwarten sind eine Werkzeugdefinition und ein Ergebnis, die den für den Agenten vorgesehenen Datenbankberechtigungen entsprechen. Schlägt die Entdeckung fehl, prüfen Sie zuerst Server-URL, verfügbaren Werkzeugnamen und Authentifizierung. Schlägt der Aufruf fehl, vergleichen Sie die erforderlichen Werkzeugparameter mit den gesendeten Werten und prüfen Sie die Serverprotokolle. Das sind Diagnoseprüfungen auf Grundlage der dokumentierten Trennung der Komponenten, keine Behauptung, dass sich eine bestimmte Bereitstellung automatisch erholt.

Grenzen und Kosten

Googles Beispiel für eine Verkehrsanwendung zeigt Spring Boot und LangChain4j beim Aufruf von Toolbox-Werkzeugen, die AlloyDB nutzen. Der Oktoberartikel bezeichnet Cymbal Transit als fiktiv. Das Beispiel zeigt ein Integrationsdesign, keine gemessene Kundennutzung oder Zuverlässigkeit.

Das Java-SDK-Repository steht unter der Apache-2.0-Lizenz. Damit sind die Preise für Datenbank, Cloud-Bereitstellung, Modellaufrufe oder Netzwerkverkehr nicht festgelegt; Teams müssen die tatsächlich gewählten Dienste kalkulieren. Das Repository kennzeichnet die Nutzung von GraalVM native-image als experimentell und warnt, dass die Java-SDK-Funktionen im Vergleich zu anderen Toolbox-Clients unvollständig sind. Prüfen Sie diese Grenzen anhand des konkreten Frameworks und der Datenquelle, bevor Sie Googles Aussage zur Eignung für Unternehmen als für ein Produktivsystem bestätigt ansehen.

Quellen und weiterführende Informationen