- 入门指南
- 最佳实践
- 租户
- 注册表
- Cloud Robots
- Automation Suite 机器人
- 文件夹上下文
- 流程
- 作业
- Apps
- 触发器
- 日志
- 监控
- 索引
- 队列
- 资产
- 连接
- 业务规则
- 存储桶
- MCP 服务器
- Orchestrator 测试
- 资源目录服务
- 集成
- 故障排除
Orchestrator 用户指南
All MCP Server types in UiPath share the same authentication model. Every HTTP request to an MCP Server must include a valid bearer token in the Authorization header. There is no session-based authentication carry-forward, even within an established MCP session.
Supported authentication methods
Four authentication methods are supported:
- Interactive Login:
uipath authopens a browser, the user logs in, and a token is saved to the local environment. Best for development and local testing. - Personal Access Token (PAT): a long-lived, user-scoped token generated in the UiPath Cloud UI. Use it when a token is needed for an HTTP client without a browser flow.
- External Application (Client Credentials): OAuth 2.0 client credentials for unattended or automated callers, such as CI/CD pipelines and service accounts.
- MCP OAuth Flow: discovery-based OAuth handled automatically by MCP-aware IDE clients (for example, Visual Studio Code with GitHub Copilot).
For full setup details for each method, check the MCP Server authentication page.
所需权限
Across all server types, the caller's identity must have the MCPServers.View permission in the folder containing the MCP Server in order to connect.
Additional permissions depend on what the tools actually do. For example, invoking process-based tools requires the Processes.View and Jobs.Create permissions, because Orchestrator creates a job for each call.
Constraints by server type
The authentication model is uniform, but one additional constraint applies to UiPath MCP Servers that expose Integration Service activity tools. Those tool calls require user-context tokens (Interactive Login or MCP OAuth). Personal Access Tokens and external application client credentials can connect to the server, but activity tool calls made with them time out.