MCP Authentication

There are two ways to authenticate to the Xurrent MCP server.

• Sign in with OAuth. Your MCP client sends you to Xurrent to sign in, and receives a token on your behalf. Nothing is copied or pasted, and no long-lived credential is stored in a config file. Use this whenever your client supports it. Both Claude and Microsoft Copilot Studio do.
• Personal Access Token (PAT). A long-lived token you generate in Xurrent and paste into your client's configuration. Use this where a client cannot sign in with OAuth, or where you deliberately want an integration to act as a single service identity rather than as each individual user.

Before you start, either way: Sera AI must be enabled on the account the MCP server connects to. If it is not, MCP requests are refused with a 403. Enable it under Settings, Self Service Settings, Enable Sera AI.

Signing in with OAuth

The Xurrent MCP server publishes OAuth discovery documents, so a client that supports them needs no configuration beyond the endpoint URL. The client finds the authorization server, registers itself, and starts the sign-in flow on its own.

1. In your MCP client, add the Xurrent MCP endpoint for your region and environment as a remote MCP server or connector. The endpoints are listed on the MCP page.
2. The client discovers the Xurrent authorization server and registers itself automatically.
3. A Xurrent sign-in page opens. Sign in as you normally would, including through single sign-on if your account uses it.
4. Review what the client is asking for and approve it.
5. The client receives its token and the Xurrent tools become available.

What this means in practice:

• Nothing to copy. There is no token to generate, paste, or keep secret. The credential never passes through you.
• You are the identity. The client acts as you, with your roles and permissions, and the audit trail attributes actions to you rather than to a shared token owner.
• Short-lived access. Access tokens last one hour and the client refreshes them silently in the background.
• Scopes. The flow requests mcp:tools, mcp:resources, and mcp:prompts. You do not configure these; the client asks for them and you approve.

Prefer this route where you can. It removes the two most common sources of trouble: a mistyped or wrongly scoped token, and a long-lived secret sitting in a plain text config file.

Generating a Personal Access Token

Use a PAT where OAuth is not an option, or where a shared service identity is what you want.

Create it in a support domain account. This is the recommended setup, because the MCP server then resolves the account for you automatically.

1. Log in to your Xurrent account.
2. Click your profile picture in the top right, then My Profile.
3. In the left sidebar, click Personal Access Tokens.
4. Click New Token.
5. Give the token a descriptive name that says which integration uses it.
6. Add the scope described below.
7. Copy the generated token immediately. Xurrent will not show it again.

Required scope

A PAT used with the MCP server needs one scope:

• Effect: Allow
• Actions: MCP, with Tools, Resources, and Prompts all selected

That single scope covers the server's prompts, resources, and tools. What the server can actually read and change in Xurrent is governed separately by the roles of the person the token belongs to.

The order in which you add the actions does not matter. Xurrent stores a scope's actions in a fixed order regardless of how they were entered, so a token that is missing access is missing the scope itself, not the right sequence.

Account selection

A PAT that belongs to a support domain account needs no further configuration; the MCP server reads the account from the token.

A Directory Account token also works, but you then have to name the target account yourself by passing it in the X-Xurrent-Account header. The support domain token is recommended because it removes that step.

Token security

• Personal Access Tokens do not expire. There is no expiry date to set. A PAT stays valid until someone disables it, so revoking is the only way to end its access. Diarise a rotation if you need one.
• Treat a PAT like a password. Anyone holding it can act as you in Xurrent, within its scopes.
• Never paste a PAT into a conversation with an AI. It belongs in the client's configuration, and the AI has no use for it.
• Never include a PAT in MCP debug logs. It appears in plain text in the arguments. Scrub it before sharing a log.
• Use a separate PAT per client, so one can be revoked without breaking the others.
• To revoke one, go to My Profile, then Personal Access Tokens, and disable it.

These concerns are much reduced with OAuth, which issues short-lived tokens and never puts a credential in your hands. That is the stronger reason to prefer it where your client allows.

Related

See Connecting Claude Desktop and Connecting Copilot Studio for client setup, Troubleshooting for connection problems, and Personal Access Token for the PAT record itself.