MCP Providers Configuration

Some built-in MCP tools require OAuth authentication — Google, LinkedIn, Microsoft, and Jira services. For these you configure a Client ID and Client Secret per provider.

General Setup

For every provider you register an OAuth application and set an authorized redirect URI. The Xagent format is:

https://<YOUR_XAGENT_DOMAIN>/api/auth/<provider>/callback

Replace <YOUR_XAGENT_DOMAIN> with your deployment domain and <provider> with google, linkedin, microsoft, or jira. Locally it may be https://sg-origin.cloud.xagent.co/api/auth/<provider>/callback.

Google (Drive, Gmail, …)

  1. In the Google Cloud Console, create a project and enable the APIs you need (Google Drive API, Gmail API).
  2. Configure the OAuth consent screen and add the required scopes (e.g. https://www.googleapis.com/auth/drive).
  3. Create an OAuth client ID of type Web application, and add the Xagent callback URL as an authorized redirect URI.
  4. Copy the generated Client ID and Client Secret into your Xagent configuration.

LinkedIn & Microsoft

LinkedIn and Microsoft follow the same pattern — register an OAuth app on the provider, set the matching /api/auth/<provider>/callback redirect URI, and copy the Client ID/Secret into Xagent.

LinkedIn scope restriction

LinkedIn strictly enforces API scopes: the r_member_social scope (needed to read posts) requires the Community Management API product, which is mutually exclusive with the standard Sign-In products. If your integration must read posts, plan the LinkedIn app's product selection accordingly.

Jira

Configure an Atlassian OAuth 2.0 (3LO) app, then set JIRA_CLIENT_ID, JIRA_CLIENT_SECRET, and JIRA_REDIRECT_URI for your deployment, matching the general pattern above with provider jira. Once configured, Jira appears as a Productivity connector: agents can search issues with JQL, read and create issues and comments, view an issue's dependencies (linked issues and subtasks), transition issues through their workflow, and browse projects and users.

Re-consent on scope changes

Atlassian does not silently re-prompt for consent when your app's requested scopes change the way most providers here do, so a user who previously authorized a narrower scope set can otherwise be handed a token still limited to the old grant. Xagent forces the Atlassian consent screen on every Jira connection for this reason.

Keep secrets safe

Client secrets grant access to the connected accounts. Store them through your deployment's secret management, not in source control.

Next Steps