- Erste Schritte
- Best Practices
- Organisationsmodellierung im Orchestrator
- Beste Praktiken für die Automatisierung (Automation Best Practices)
- Optimieren von Unattended-Infrastruktur mithilfe von Maschinenvorlagen
- Organisieren von Ressourcen mit Tags
- Exportieren von Rastern im Hintergrund
- Durchsetzung der Governance der Integration Service-Verbindung auf Benutzerebene
- Mandant
- Über den Kontext „Mandant“
- Suche nach Ressourcen in einem Mandanten
- Verwaltung von Robotern
- Verbindung von Robotern mit Orchestrator
- Speicherung von Roboterzugangsdaten in CyberArk
- Speichern der Kennwörter von Unattended-Robotern im Azure Key Vault (schreibgeschützt)
- Speichern der Anmeldeinformationen von Unattended-Robotern im HashiCorp Vault (schreibgeschützt)
- Speichern der Anmeldeinformationen von Unattended-Robotern im AWS Secrets Manager (schreibgeschützt)
- Löschen von getrennten und nicht reagierenden Unattended-Sitzungen
- Roboter-Authentifizierung
- Roboter-Authentifizierung mit Client-Anmeldeinformationen
- Konfigurieren von Automatisierungsfunktionen
- Solutions (Lösungen)
- Audit
- Einstellungen
- Registrierung
- Benachrichtigungen
- Events
- Anzeigen und Zugreifen auf Benachrichtigungen
- Anzeigen und Zugreifen auf E-Mail-Benachrichtigungen
- Es werden nur ungelesene Benachrichtigungen angezeigt
- Alle Benachrichtigungen als gelesen markieren
- Alle Benachrichtigungen löschen
- Löschen von Benachrichtigungen
- Abonnieren von Ereignissen
- Abbestellen von Ereignissen
- Ordnerkontext
- Prozesse
- Jobs
- Apps
- Auslöser
- Protokolle
- Überwachung
- Indizes
- Warteschlangen
- Assets
- Über Assets
- Verwalten von Assets in Orchestrator
- Verwalten von Assets in Studio
- Speichern von Assets im Azure Key Vault (schreibgeschützt)
- Speichern von Assets im HashiCorp Vault (schreibgeschützt)
- Speichern von Assets im AWS Secrets Manager (schreibgeschützt)
- Speichern von Assets in Google Secret Manager (schreibgeschützt)
- Verbindungen
- Geschäftsregeln
- Speicher-Buckets
- Agent Gateway
- About Agent Gateway
- MCP-Anwendungsfälle und -Flows
- Testen von MCP-Servern
- Fehlerbehebung für MCP-Server
- MCP-Compliance-Richtlinien
- Testverfahren in Orchestrator
- Ressourcenkatalogdienst
- Integrationen
- Fehlersuche und ‑behebung
Setup-Schritte zum Verbinden eines öffentlichen oder privaten externen Tools mit UiPath als Remote-MCP-Server und die jeweils erforderliche Authentifizierung.
Viele der Tools, die Ihre Agents benötigen, sind bereits an anderer Stelle vorhanden, vielleicht in einer Software, die still innerhalb Ihrer eigenen Infrastruktur ausgeführt wird. Mit einem Remote-MCP-Server können Sie diese als MCP-Tool in UiPath integrieren, sodass Ihre Agents sie auf die gleiche Weise erkennen und aufrufen können, wie sie Tools verwenden, die nativ auf der Plattform erstellt wurden und die Governance-Funktionen der UiPath Platform übernehmen.
Wie Sie eine Verbindung herstellen, hängt davon ab, wo sich das Tool befindet:
- Direkt, wenn es bereits im Internet öffentlich ist.
- Über UiPath-Relay, wenn es sich in Ihrem eigenen Netzwerk befindet.
Auf dieser Seite werden beide beschrieben, mit den jeweiligen Einrichtungsschritten. Für die anderen MCP-Servertypen, UiPath, Coded, Command und Self-Hosted, siehe MCP-Servertypen.
Anwendungsfälle
- Integrieren Sie die API eines Partners in Ihre Automatisierungen: Ihr Team hat bereits API-Zugriff auf einen Spediteur oder einen Zahlungsanbieter. Als Remote-MCP-Server steht er Ihren Agents direkt zur Verfügung, ohne dass eine benutzerdefinierte Integration erstellt oder verwaltet werden muss.
- Verbinden Sie ein SaaS-Tool, das Ihre Agents bereits benötigen: Viele bekannte Plattformen veröffentlichen ihren eigenen öffentlichen MCP-Server. Sobald er im Orchestrator hinzugefügt wurde, ist er für jeden Agent und jede Automatisierung mit Zugriff auf diesen Ordner verfügbar.
- Erreichen Sie ein internes System, ohne es dem Internet zugänglich zu machen: Ihr Ticketingsystem oder ein Legacy-Dienst wird in Ihrem eigenen Rechenzentrum ausgeführt und kann nicht öffentlich veröffentlicht werden. Über Relay können Ihre Agents ihre Tools aufrufen, ohne dass ein einziger eingehender Port geöffnet ist.
Auf einen Blick
| Anwendungsfall 1: Relay | Anwendungsfall 2: Direkt | |
|---|---|---|
| Am besten geeignet für | Tools in Ihrem eigenen Netzwerk oder Rechenzentrum | Tools sind bereits über das Internet erreichbar |
| Zusätzliche Einrichtung | Der Relay-Client ist in Ihrem Netzwerk installiert und registriert | Keines über das Hinzufügen des MCP-Servers hinaus |
| Änderungen an der Firewall | Keine, Relay hält einen Nur-Ausgehend-Tunnel offen | Keine |
Anwendungsfall 1: Externes MCP über Relay + OAuth
Ablauf der Anforderung
Das Szenario
Ein Tool, das Ihre Agents benötigen, ein ERP, ein Ticketingsystem oder ein Legacy-Dienst, wird in Ihrem eigenen Netzwerk hinter einer Firewall ausgeführt und ist über das öffentliche Internet nicht erreichbar. Sie möchten, dass Ihre UiPath-Agents ihre Tools genauso aufrufen, wie sie jeden anderen MCP-Server in Ihrem Katalog aufrufen, ohne dass er dem Internet zugänglich gemacht wird.
Erreichbarkeit und Identität müssen berücksichtigt werden:
- Erreichen eines Hosts ohne öffentliche Route – gelöst über UiPath Relay
- Nachweis der UiPath-Identität des Aufrufers – gelöst über dynamische OAuth-Authentifizierung
Die eigenen Anmeldeinformationen des Tools bleiben von beiden getrennt.
Wenn das Tool bereits über das öffentliche Internet erreichbar ist, verwenden Sie stattdessen Anwendungsfall 2, da Sie Relay nicht benötigen.
Einrichten der Verbindung
Voraussetzungen:
- Relay für Ihren Mandanten bereitgestellt, wobei der Relay-Client in Ihrem Netzwerk installiert und registriert ist. Weitere Informationen zur Aktivierung finden Sie im Administratorhandbuch zu Relay .
- Ihre Identität verfügt über die Berechtigung
MCPServers.Viewin dem Ordner, der den MCP-Server enthält. Die Rollen Automation User und Automation Developer enthalten ihn. - Die Anmeldeinformationen, die das Tool selbst benötigt, ein API-Schlüssel oder eine Integration Service-Verbindung, finden Sie in diesem Ordner.
Anweisungen
- Wählen Sie auf der Seite MCP-Server die Option MCP-Server hinzufügen.
- Wählen Sie den Remote- Typ aus.
- Geben Sie einen Namen für den MCP-Server ein.
- Fügen Sie eine Beschreibung hinzu.
- Legen Sie den Verbindungstyp auf Privat (Relay) fest.
- Authentifizierung konfigurieren:
- Verbindung: Wählen oder fügen Sie eine Integration Service-Verbindung hinzu, die zum Abrufen des Authentifizierungstokens verwendet werden soll.
- Authentifizierungstoken: Fügen Sie im Abschnitt Header ein statisches Authentifizierungstoken hinzu. Wir empfehlen, auf ein Asset zu verweisen, anstatt ein Geheimnis zu hartcodieren, z. B.
Authorization: %ASSETS/RemoteBearerToken%.
- Geben Sie unter Remote-URL die Adresse des Tools ein, die in Ihrem Netzwerk zu sehen ist, dieselbe Adresse, die der Relay-Client bereits erreicht.
- Wählen Sie Hinzufügen aus.
Authentifizieren des Anrufers
Aufrufer authentifizieren sich auf die gleiche Weise wie bei jedem anderen MCP-Server: über den MCP OAuth-Flow für interaktive Clients wie eine IDE oder ein persönliches Zugriffstoken, eine externe Anwendung oder eine interaktive Anmeldung für automatisierte Aufrufer. Die vollständige Methodenmatrix finden Sie unter MCP-Serverauthentifizierung .
POST https://cloud.uipath.com/{org}/{tenant}/agenthub_/mcp/{folderKey}/{slug}
Authorization: Bearer <token>
Content-Type: application/json
{ "jsonrpc": "2.0", "method": "tools/list", "id": 1 }
POST https://cloud.uipath.com/{org}/{tenant}/agenthub_/mcp/{folderKey}/{slug}
Authorization: Bearer <token>
Content-Type: application/json
{ "jsonrpc": "2.0", "method": "tools/list", "id": 1 }
Ihre Anmeldeinformationen werden niemals an das Tool weitergegeben. Die eigenen Anmeldeinformationen aus dem Feld Header oder Verbindung oben werden bei jedem Aufruf separat angewendet.
Überprüfen der Verbindung
Ein tools/list -Aufruf, der die Tools des Tools zurückgibt, bestätigt sowohl die Identität des Aufrufers als auch die eigenen Anmeldeinformationen des Tools. Wenn der Aufruf fehlschlägt:
- 401 bedeutet in der Regel das Token des Aufrufers.
- 403 bedeutet in der Regel, dass im Ordner
MCPServers.Viewfehlt. - 502 oder 504 bedeutet in der Regel, dass der Relay-Client offline ist, oder dass das Tool seine eigenen Anmeldeinformationen abgelehnt hat.
Weitere Informationen finden Sie unter Fehlerbehebung bei der MCP-Server-Authentifizierung und Fehlerbehebung bei MCP-Servern .
Anwendungsfall 2: Externes MCP, direkt + OAuth
Das Szenario
Ein Tool, das Ihre Agents benötigen, ist bereits im öffentlichen Internet, auf einem SaaS- oder Partner-MCP-Server, oder einem, den Sie hosten und selbst bereitstellen. Sie möchten, dass Ihre Agents ihn auf die gleiche Weise wie jeden anderen MCP-Server aufrufen, mit demselben Governance- und Prüfungspfad, ohne dass Relay erforderlich ist.
Wenn das Tool privat oder lokal ist, verwenden Sie stattdessen Anwendungsfall 1 .
Einrichten der Verbindung
Voraussetzungen:
- Ihre Identität verfügt über die Berechtigung
MCPServers.Viewin dem Ordner, der den MCP-Server enthält. Die Rollen Automation User und Automation Developer enthalten ihn. - Die Anmeldeinformationen, die das Tool selbst benötigt, ein API-Schlüssel oder eine Integration Service-Verbindung, finden Sie in diesem Ordner.
Anweisungen
- Wählen Sie auf der Seite MCP-Server die Option MCP-Server hinzufügen.
- Wählen Sie den Remote- Typ aus.
- Geben Sie einen Namen für den MCP-Server ein.
- Fügen Sie eine Beschreibung hinzu.
- Legen Sie den Verbindungstyp auf Standard fest.
- Authentifizierung konfigurieren:
- Verbindung: Wählen oder fügen Sie eine Integration Service-Verbindung hinzu, die zum Abrufen des Authentifizierungstokens verwendet werden soll.
- Authentifizierungstoken: Fügen Sie im Abschnitt Header ein statisches Authentifizierungstoken hinzu. Wir empfehlen, auf ein Asset zu verweisen, anstatt ein Geheimnis zu hartcodieren, z. B.
Authorization: %ASSETS/RemoteBearerToken%.
- Geben Sie bei Remote-URL die Adresse des Tools ein, wie sie in Ihrem Netzwerk zu sehen ist.
- Wählen Sie Hinzufügen aus.
Authentifizieren des Anrufers
Aufrufer authentifizieren sich auf die gleiche Weise wie bei jedem anderen MCP-Server: über den MCP OAuth-Flow für interaktive Clients wie eine IDE oder ein persönliches Zugriffstoken, eine externe Anwendung oder eine interaktive Anmeldung für automatisierte Aufrufer. Die vollständige Methodenmatrix finden Sie unter MCP-Serverauthentifizierung .
POST https://cloud.uipath.com/{org}/{tenant}/agenthub_/mcp/{folderKey}/{slug}
Authorization: Bearer <token>
Content-Type: application/json
{ "jsonrpc": "2.0", "method": "tools/list", "id": 1 }
POST https://cloud.uipath.com/{org}/{tenant}/agenthub_/mcp/{folderKey}/{slug}
Authorization: Bearer <token>
Content-Type: application/json
{ "jsonrpc": "2.0", "method": "tools/list", "id": 1 }
Überprüfen der Verbindung
Ein tools/list -Aufruf, der die Tools des Tools zurückgibt, bestätigt, dass die Verbindung funktioniert. Wenn der Aufruf fehlschlägt:
- 401 bedeutet in der Regel das Token des Aufrufers.
- 403 bedeutet in der Regel, dass im Ordner
MCPServers.Viewfehlt. - 502 bedeutet in der Regel, dass das Tool nicht erreichbar ist oder dass es seine eigenen Anmeldeinformationen abgelehnt hat.
- Ein Verbindungsfehler, bei dem keiner erwartet wird, bedeutet in der Regel, dass die Adresse in einen privaten oder internen Host aufgelöst wird; wechseln Sie stattdessen zu Anwendungsfall 1.
Weitere Informationen finden Sie unter Fehlerbehebung bei der MCP-Server-Authentifizierung und Fehlerbehebung bei MCP-Servern .
- Anwendungsfälle
- Auf einen Blick
- Anwendungsfall 1: Externes MCP über Relay + OAuth
- Ablauf der Anforderung
- Das Szenario
- Einrichten der Verbindung
- Authentifizieren des Anrufers
- Überprüfen der Verbindung
- Anwendungsfall 2: Externes MCP, direkt + OAuth
- Das Szenario
- Einrichten der Verbindung
- Authentifizieren des Anrufers
- Überprüfen der Verbindung