- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- Configuring automation capabilities
- Solutions
- Audit
- Settings
- Registry
- Cloud robots
- Automation Suite Robots
- Folders Context
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Indexes
- Queues
- Assets
- Connections
- Business Rules
- Storage Buckets
- MCP Servers
- Orchestrator testing
- Resource Catalog Service
- Integrations
- Troubleshooting
MCP Connections for authenticating Remote MCP Servers to external services, using a shared default connection or per-user connections.
An MCP Connection is an Integration Service connection that a Remote MCP Server uses to authenticate outbound calls to the external server it proxies. You authorize the connection once against the remote service, then attach it to the Remote MCP Server. Because a connection is tied to a specific URL, it can only be used with a server whose URL matches.
At call time, Orchestrator requests a fresh access token from the connection and sends it to the remote server in the Authorization header. The credentials are held by the Integration Service connection, and the MCP Server stores only a reference to it, never the token or password itself.
Your UiPath bearer token is never forwarded to the remote server. The remote server only sees the credentials supplied by the connection, or by custom headers, so your UiPath identity never leaves the platform. For setup steps, check Creating a remote MCP Server and Managing MCP Connections.
How a Remote MCP Server authenticates outbound
A Remote MCP Server supports three ways to authenticate to the endpoint it proxies. The right one depends on how the remote service expects to be called.
| Method | How it's configured | When it applies |
|---|---|---|
| No outbound authentication | Headers and connection are both left empty. | The remote server is open, or it authenticates through a mechanism that doesn't need to be supplied here. |
| Custom headers | Header lines added on the server, for example Authorization: Bearer ... or X-Api-Key: .... An Orchestrator asset reference avoids storing the value in plain text, for example Authorization: %ASSETS/MyApiKey%. | The remote service uses a static token or API key. |
| MCP Connection | An Integration Service connection attached to the server, either as a default for everyone or per user account. | The remote service uses OAuth, or different users need to act with their own credentials. |
When a connection is attached, it supplies the Authorization header for every call. Any Authorization header also set in custom headers is ignored in that case, so only the connection's token is sent. For details on asset-backed headers, check Using Orchestrator Assets in MCP Servers.
Default and per-user connections
A Remote MCP Server can use connections at two levels:
- Default connection: a single connection set on the server and shared by everyone who calls it. Only connections from a shared folder can serve as the default. If the connection is in a different folder than the MCP Server, the caller needs access to both folders.
- Per-user connections: connections mapped to individual user accounts. When a user calls the server, their own connection is used instead of the default. A per-user connection can come from a shared folder or from that user's Personal Workspace.
At call time, UiPath selects a connection in the following order:
- The caller's own per-user connection, if one is configured.
- The server's default connection.
- No connection. UiPath falls back to the custom headers, or sends no authentication if none are set.
A default connection is enough when one shared identity serves every caller. Per-user connections are appropriate when each user must act as themselves against the remote service.
Connection status
The Connections per user account page shows a status for each configured user, indicating at a glance whether that user's calls will authenticate.
| Status | Meaning | Resolution |
|---|---|---|
| Active | The connection is authorized and ready. Calls from this user use it. | None needed. |
| Requires authentication | No working connection is available for this user: none is configured, or the user's own connection needs to be authorized again. | The user, or an admin, adds or reconnects a connection for this user. |
| Unavailable | The shared default connection is missing, disabled, expired, or unreachable. | An admin fixes or replaces the server's default connection. |
| Inactive | The server isn't active, or the connection is disabled. | The server is activated, or the connection is enabled in Integration Service. |
For steps to configure and verify connections, check Managing MCP Connections.
Connection versus Connection Type
The Remote MCP Server form has two settings whose names look similar but serve different purposes:
- Connection is authentication: the Integration Service connection used to authenticate to the remote server, as described on this page.
- Connection Type is network routing: Standard reaches the remote server directly over the public internet, while Private (Relay) reaches an on-premises server through UiPath Relay without opening inbound ports.
Connection Type doesn't affect which credentials are sent.