Geschäftsdaten
CRM, ERP, Bestellungen, Dokumente, Analysen und internes Wissen.
Mit MCP kann ein anderes Programm über einen Standardvertrag Tools, Informationen und wiederverwendbare Eingabeaufforderungen veröffentlichen. ADK-Rust wandelt diese Funktionen in typisierte Agententools um, macht das umfassendere Protokoll verfügbar und kann eine wechselnde Flotte lokaler MCP-Server verwalten, während Ihr Produkt ausgeführt wird.
ADK-Rust MCP-Architektur
Ihr Agent nutzt die MCP-Funktionen wie jedes andere ADK-Rust-Tool. MCP verbindet es mit jedem Server, wobei jeder Server für seine eigenen Daten, Regeln und Aktionen verantwortlich bleibt.
Die Erfahrung, nach Arbeit zu fragen.
Agent oder Workflow
Wählt eine Funktion aus den Tools aus, die sie sehen darf.
ADK-Richtlinie
Wendet Genehmigung, Autorisierung, Leitplanken und Prüfung rund um den Anruf an.
Der typisierte Adapter innerhalb der Laufzeit.
McpToolset
Erkennt Tools und bewahrt die Schemata und Ergebnisinhalte des Servers.
Protokoll APIs
Ressourcen, Eingabeaufforderungen, Abschluss, Abonnements, Erhebung und Aufgaben.
Servermanager
Ändert und überwacht eine Registrierung lokaler stdio-Verbindungen.
Wählen Sie den Transport, der dem Eigentum entspricht.
Lokal stdio
ADK-Rust startet einen nativen Binärprozess oder einen anderen untergeordneten Prozess und ist Eigentümer seiner Sitzung.
Streamable HTTP
Stellen Sie eine Verbindung zu einem unabhängig gehosteten Dienst mit Headern, Authentifizierung und Zeitüberschreitungen her.
Jeder Server veröffentlicht nur das, was er besitzt.
Werkzeuge
Aktionen
Ressourcen
Kontext
Aufforderungen
Vorlagen
Aufgaben
Lange Arbeit
CRM, ERP, Bestellungen, Dokumente, Analysen und internes Wissen.
Quellcodeverwaltung, Build-Tools, Browser, Sandboxes und Codierungsumgebungen.
Zahlungen, Kommunikation, Suche, Karten und Partner APIs.
Medienerstellung, Tabellenkalkulationen, Computernutzung und domänenspezifische Dienste.
Beginnen Sie mit dem Problem
Ein KI-Agent wird nützlich, wenn er die Systeme erreichen kann, die echte Informationen enthalten und echte Arbeit leisten. Ohne ein gemeinsames Protokoll benötigt jede Datenbank, jedes SaaS-Produkt, jedes Browser-Tool, jeder interne Dienst und jede Fachlaufzeit einen benutzerdefinierten Adapter. Diese Adapter wiederholen Erkennung, Schemata, Transport, Fehler, Authentifizierung und Lebenszykluscode.
MCP legt einen stabilen Vertrag um diese Grenze herum fest. Ein Server beschreibt, was er bietet und wie er aufgerufen wird. Ein Client erkennt diesen Katalog zur Laufzeit. Die Agent-Anwendung kann dann eine überprüfte Funktion auswählen, ohne die Implementierung des Servers zu importieren oder seine privaten Anmeldeinformationen zu erhalten.
ADK-Rust verbindet diesen Vertrag mit denselben Tool- und Toolset-Abstraktionen, die von nativen Rust-Tools verwendet werden. Das Modell kann über seine normale Agentenschleife mit MCP-Funktionen arbeiten, während die Anwendung die anbieterspezifische Schemakonvertierung, Genehmigung, Sitzungen, Telemetrie und Betriebsrichtlinien rund um den Anruf beibehält.
Werkzeug
Ein Tool verfügt über einen Namen, eine nützliche Beschreibung, ein Eingabeschema und optional ein Ausgabeschema. Beispiele hierfür sind das Lesen einer Bestellung, das Durchsuchen eines Repositorys, das Aktualisieren eines Tickets oder das Erstellen einer Tabelle.
Ressource
Eine Ressource gibt Informationen einen stabilen URI. Es kann ein Dokument, eine Richtlinie, einen Datenbankeintrag, einen Katalog oder ein generiertes Ergebnis darstellen, ohne den Eindruck zu erwecken, dass das Lesen von Daten eine Aktion sei.
Prompt
Eine Eingabeaufforderung kann die richtigen Anweisungen und Eingaben für eine Aufgabe erfassen, die der Domäne des Servers gehört, beispielsweise die Untersuchung einer Bestellung oder die Überprüfung einer Bereitstellung.
Erhebung
Während eines Toolaufrufs kann ein Server den Client auffordern, ein Formular vorzulegen oder eine genehmigte URL zu öffnen. Die Verantwortung für die Einwilligung und die Validierung der Antwort bleibt bei der Anwendung.
Dynamic MCP management
An agent product may serve several tenants, workspaces, or operating modes. The useful MCP servers can change when a workspace opens, an administrator enables an integration, a credential rotates, or a specialist process is upgraded.
`McpServerManager` keeps that lifecycle in the application instead of forcing every server definition into startup code. It is designed for local stdio child processes; independently hosted HTTP services remain application-owned connections.
Read mcp.json-compatible definitions or construct them in Rust. Disabled servers stay registered without starting.
Spawn each enabled child and complete the MCP handshake before its capabilities become visible.
List tools from running servers, filter the published surface, and prefix only names that collide.
Add, update, enable, disable, or remove a server without rebuilding the agent application.
Detect a closed connection and apply the server's bounded exponential-backoff restart policy.
Persist the current registry atomically, cancel MCP sessions, wait for the grace period, and drop child transports.
Practical sequence
The model does not receive database credentials or private API clients. It receives a reviewed catalog of tools and resources. ADK-Rust keeps approval around the consequential replacement call.
Aktuelle Protokolloberfläche
Die direkten ADK-Rust APIs decken die Funktionen ab, die ein Agentenprodukt am häufigsten benötigt: Tools erkennen und aufrufen, Ressourcen lesen, Eingabeaufforderungen auflösen, Argumentvorschläge anfordern, sich ändernde Ressourcen abonnieren, Ermittlungsanfragen beantworten und einer ausgehandelten, lang laufenden Toolaufgabe folgen.
Für erweitertes Server-Authoring, benutzerdefinierte Client-Handler, Benachrichtigungen, Transporte, Autorisierungsarbeiten und Protokollerweiterungen exportiert adk_tool::mcp::rmcp genau die offizielle SDK-Version, die im Framework verwendet wird. Dadurch wird vermieden, dass inkompatible Protokolltypen in einer Anwendung gemischt werden.
Verwenden Sie MCP-Funktionen innerhalb gewöhnlicher ADK-Rust-Agenten- und Tool-Flows.
Lesen Sie den Rest des Katalogs, anstatt MCP auf Toolaufrufe zu reduzieren.
Unterstützen Sie Protokollgespräche, die über eine unmittelbare Antwort hinausgehen.
Wählen Sie lokale Prozessverantwortung oder einen separat gehosteten Dienst.
Arbeitsbeispiel
Eine Anwendung benötigt möglicherweise unterschiedliche MCP-Funktionen für jeden Arbeitsbereich, Kunden oder jede Aufgabe. Die Festcodierung jedes Servers beim Start erschwert diese Änderungen. McpServerManager gibt der Anwendung einen Ort, an dem sie lokale MCP-Server starten, ihre Tools kombinieren, ihre Konfiguration ändern, ihre Verbindungen überwachen und sie sauber schließen kann.
Dieses Beispiel beginnt mit einem konfigurierten Server namens local-tools. Der Agent kann sein Echo-Tool erkennen und aufrufen. Anschließend fügt die Anwendung einen zweiten Server hinzu, aktiviert ihn, ersetzt seine laufende Konfiguration, speichert die aktualisierte Registrierung und entfernt sie wieder. Bei jeder Änderung werden dieselben APIs verwendet, die für einen Verwaltungsbildschirm oder einen Konfigurationsdienst verfügbar sind.
Das Beispiel läuft vollständig auf Ihrem Computer. Die ausführbare Datei Rust startet eine Kopie von sich selbst als untergeordneter Server MCP, sodass Handshake, Tool-Erkennung, Tool-Aufruf, Neustart, Persistenz und Herunterfahren real sind. Es ist kein Modell, Node.js-Paket, API-Schlüssel oder Internetverbindung erforderlich.
Laden Sie local-tools aus einer mcp.json-kompatiblen Konfiguration, starten Sie den untergeordneten Prozess, schließen Sie den MCP-Handshake ab und ermitteln Sie das Echo-Tool.
Registrieren Sie Standby-Tools als deaktiviert, aktivieren und starten Sie es dann, wenn die Anwendung entscheidet, dass die Funktion verfügbar werden soll.
Aktualisieren Sie die Definition des laufenden Servers. Der Manager startet es mit der neuen Konfiguration neu und kann die vorherige Definition wiederherstellen, wenn der Ersatzstart fehlschlägt.
Schreiben Sie die Live-Registrierung zurück in JSON, deaktivieren und entfernen Sie den zusätzlichen Server und schließen Sie dann jede MCP-Sitzung und jeden untergeordneten Prozess sauber.
let manager = McpServerManager::from_json(&config)?
.with_health_check_interval(Duration::from_secs(15));
manager.start_server("local-tools").await?;
manager.start_monitoring();
manager
.add_server("standby-tools".into(), standby)
.await?;
manager.enable_server("standby-tools").await?;
manager.start_server("standby-tools").await?;
manager
.update_server("standby-tools", replacement)
.await?;
manager.save_json_file("mcp.json").await?;
manager.shutdown().await?;$ cargo run --manifest-path examples/mcp_manager/Cargo.toml
1. Loaded local-tools from mcp.json-compatible configuration
status: Running
2. Discovered 1 tool: echo
3. Called the real child server
response: {"output":"MCP server replied: dynamic MCP is running"}
4. Added standby-tools at runtime: Disabled
enabled and started: Running
5. Reconfigured the running server and restarted it safely
6. Saved the live registry
7. Disabled, removed, and shut down every child serverClient, Manager oder Server
Die meisten Agentenanwendungen sind MCP-Clients. Sie verbinden sich mit einem bestehenden Server und stellen ausgewählte Tools einem Agenten zur Verfügung. Produkte, die Arbeitsbereichs- oder Administratorintegrationen ermöglichen, können lokale stdio-Verbindungen hinter dem Manager platzieren. Teams, die eine neue Funktion veröffentlichen, verwenden die erneut exportierten rmcp-Server APIs und testen den Server dann von einem ADK-Rust-Client aus.
Produktionsdesign
MCP sorgt für konsistente Erkennung und Kommunikation. Es entscheidet nicht, welche Systeme ein Agent erreichen soll, welche Aktionen eine Genehmigung erfordern, wie Anmeldeinformationen ausgestellt werden oder was passieren soll, wenn eine Abhängigkeit fehlschlägt. Das bleiben Produkt- und Plattformentscheidungen.
Erstellen Sie einen Server rund um eine kohärente Funktion, die einem Team oder System gehört. Vermeiden Sie einen riesigen Server, dessen Tools unabhängige Anmeldeinformationen und Risikostufen umfassen.
Filtern Sie Werkzeuge, bevor das Modell sie sieht. Halten Sie Lesevorgänge getrennt von Schreibvorgängen, Zahlungen, Löschungen, Bereitstellungen und anderen Folgeaktionen.
mcp.json autoApprove bleibt aus Kompatibilitätsgründen erhalten; Es umgeht nicht die Autorisierung, die Bestätigungshandler oder die Anwendungsrichtlinie des Frameworks.
Verwenden Sie stdio, wenn Ihre Anwendung Eigentümer des lokalen untergeordneten Prozesses ist. Verwenden Sie Streamable HTTP, wenn eine andere Bereitstellung Verfügbarkeit, Identität und Skalierung besitzt.
Werkzeugbeschreibungen, Schemata, Ressourceninhalte und Ergebnisse überschreiten eine Systemgrenze. Validieren Sie Argumente, begrenzen Sie Ergebnisgrößen und schützen Sie den Modellkontext vor feindlichen Anweisungen.
Legen Sie Verbindungs- und Aufgaben-Timeouts fest, zeichnen Sie Lebenszyklusänderungen auf, prüfen Sie die Geschäftsabhängigkeit separat und entscheiden Sie, wie sich das Produkt verhält, wenn ein Server nicht verfügbar ist.
Verbinden Sie die nützlichen Systeme
Beginnen Sie mit einem Server, den Sie verstehen, filtern Sie seinen Katalog, rufen Sie ein schreibgeschütztes Tool auf und überprüfen Sie das vollständige Ergebnis. Fügen Sie Schreibaktionen, dynamisches Management, Remote-Dienste, Erhebung und lang laufende Aufgaben hinzu, wenn das Produkt jeweils einen klaren Grund hat.