- Démarrage
- Meilleures pratiques
- Locataire
- À propos du contexte du locataire
- Recherche de ressources dans un locataire
- Gestion des Robots
- Connexion des Robots à Orchestrator
- Enregistrement des identifiants du Robot dans CyberArk
- Stockage des mots de passe de l’Unattended Robot dans Azure Key Vault (lecture seule)
- Stockage des informations d’identification de l’Unattended Robot dans HashiCorp Vault (lecture seule)
- Stockage des informations d'identification du robot Unattended dans AWS Secrets Manager (lecture seule)
- Suppression des sessions Unattended déconnectées et qui ne répondent pas
- Authentification du Robot
- Authentification du Robot avec les informations d'identification du client
- Configurer les capacités d’automatisation
- Solutions
- Audit
- Paramètres
- Registre
- Cloud Robots
- Présentation des robots cloud
- Exécution d'automatisations Unattended à l'aide de Cloud Robots - VM
- Téléchargement de votre propre image
- Réutilisation des images de machines personnalisées (pour les pools manuels)
- Réinitialisation des informations d'identification d'une machine (pour les pools manuels)
- Surveillance
- Mises à jour de sécurité
- Demander un essai
- Questions fréquemment posées
- Configuration du VPN pour les robots du cloud
- Configurer une connexion ExpressRoute
- Diffusion en direct et contrôle à distance
- Robots Automation Suite
- Contexte des dossiers
- Processus (Processes)
- Tâches (Jobs)
- Apps
- Déclencheurs (Triggers)
- Journaux (Logs)
- Surveillance
- Index
- Files d'attente (Queues)
- Actifs
- À propos des actifs
- Gestion des actifs dans Orchestrator
- Gestion des actifs dans Studio
- Stockage des ressources dans Azure Key Vault (lecture seule)
- Stockage des ressources dans HashiCorp Vault (lecture seule)
- Stockage des ressources dans AWS Secrets Manager (lecture seule)
- Stocker des ressources dans Google Secret Manager (lecture seule)
- Connexions
- Règles métier
- Compartiments de stockage
- Serveurs MCP
- Tests d'Orchestrator
- Service de catalogue de ressources
- Intégrations
- Résolution des problèmes
Guide de l'utilisateur d'Orchestrator
When MCP Servers run locally (using uipath run), authentication happens at two separate layers:
- Runtime to cloud: the local runtime authenticates so that it can register the MCP Server with the cloud.
- Client to cloud: external clients authenticate when they call the cloud-facing MCP Server endpoint.
Layer 1: runtime to cloud (server registration)
The uipath run command needs its own token to register the MCP Server with the cloud. This is the developer's authentication, the identity of the person running the server locally.
# Authenticate the runtime — interactive login
uipath auth
# Or authenticate the runtime — client credentials
uipath auth --client-id "..." \
--client-secret "..." \
--base-url "https://cloud.uipath.com/{org}/{tenant}" \
--scope "OR.Default"
# Start the local server
uipath run mcp-server
# Authenticate the runtime — interactive login
uipath auth
# Or authenticate the runtime — client credentials
uipath auth --client-id "..." \
--client-secret "..." \
--base-url "https://cloud.uipath.com/{org}/{tenant}" \
--scope "OR.Default"
# Start the local server
uipath run mcp-server
The runtime uses this token to establish a SignalR connection to the cloud and register the server's tools.
Layer 2: client to cloud (calling the server)
External clients (such as MCP Inspector, cURL, an IDE, or any HTTP client) authenticate to the cloud through any of the four standard methods described in MCP Server authentication. The URL is the same as for any other MCP Server:
https://cloud.uipath.com/{org}/{tenant}/agenthub_/mcp/{folderKey}/{slug}
https://cloud.uipath.com/{org}/{tenant}/agenthub_/mcp/{folderKey}/{slug}
How requests flow
The client's Bearer token never reaches the local runtime. The cloud validates the token and forwards only the MCP protocol message through Redis. The local runtime and the MCP Server process do not see the token.
Applicable MCP Server types
Ground-to-cloud authentication applies to MCP Server types that have a local runtime:
- Self-hosted: always runs locally, always uses ground-to-cloud authentication.
- Coded and Command: use ground-to-cloud authentication when run locally through
uipath runduring development. Once deployed to Orchestrator, they run as cloud jobs and no local runtime is involved.
Client credentials with local servers
When using client credentials with uipath run, set the UIPATH_FOLDER_KEY environment variable. The Python SDK's GetFoldersForCurrentUser call does not support client credentials. For details, see Known limitation: GetFoldersForCurrentUser.