Connect Agents to Other MCP Servers
A harness agent always has XPT Tracker's own tools. With connectors it can also use other MCP servers: search a Notion workspace, read a Slack channel, work with any other service that offers an MCP server. A workspace admin adds each server once, connects it, and chooses which agents may use it.
This is the other direction from the rest of this section. There, your own AI client connects into XPT. Here, an agent inside XPT connects out to another service.
How it works
| Rule | What it means |
|---|---|
| One connection per workspace | A connector is connected once, by an admin, and shared by every agent it is given to. Agents work unattended, for example in scheduled jobs, so there is no one to ask for a sign-in at the moment of the call. |
| It acts as the account that connected it | Whatever an agent does through a connector, the provider sees as the account an admin signed in with. The agent reaches what that account reaches, whoever mentioned the agent. |
| Credentials stay in XPT | Tokens and secrets are stored encrypted by XPT. The agent's sandbox never receives them: its calls go to XPT, which adds the connector's credential and forwards them to the provider. |
| All tools of the server | An agent given a connector can use every tool that server offers. |
| Harness agents only | Connectors work with harness agents (Claude Code and Codex). Server-side agents cannot use them yet. |
Because a shared connection acts as one account, connect with an account whose access fits the agents' work, such as a dedicated service account, rather than a personal account with broad access.
Who can do what
| Action | Who |
|---|---|
| Add, connect, reconnect, edit and delete connectors | Workspace admins |
| Give a connector to an agent, or take it away | Workspace admins |
| See which connectors an agent has, and their status | Every member, on the agent's page |
Connectors appears in workspace settings for admins only, in the MCP group. Members who open it from a link see that connectors are managed by workspace admins.
Add a connector
In Settings → Connectors, choose Add connector and fill in the dialog:
| Field | What to enter |
|---|---|
| Name | How the connector is shown, for example Notion |
| Key | Suggested from the name, for example notion. Agents see the server's tools under this name. Lowercase letters, digits and single hyphens; xpt is reserved. The key cannot be changed later |
| Server URL | The provider's MCP address, for example https://mcp.notion.com/mcp. It must be an https address on the public internet; addresses in private networks are refused |
| Authentication | OAuth, Bearer token or No authentication. Fixed once the connector is added |
| Authentication | When to choose it | What happens next |
|---|---|---|
| OAuth | The provider has you sign in. Most hosted MCP servers work this way | Add and connect takes you to the provider (see below) |
| Bearer token | The provider gives you a fixed token or API key | Paste it into Token. The connector is ready at once |
| No authentication | The server is open to anyone who can reach it | The connector is ready at once |
Connect with OAuth
Add and connect (or Connect on a connector's row) sends your browser to the provider. Sign in there and approve access for XPT Tracker. The provider then returns you to the Connectors page. The connector shows Connected, with who connected it and when.
From then on XPT keeps the connection fresh by itself: it renews the provider's short-lived tokens as needed, one renewal at a time, so parallel agent turns do not disturb each other.
When the provider needs a registered app
Most MCP servers let XPT register itself as a client automatically. Some providers require an app that you register with them yourself. In that case Connect stops with The provider needs a registered app, and the connector's Edit dialog opens with the advanced part expanded:
- In the provider's developer settings, create an OAuth app.
- Add the Redirect URL to register with the provider that the dialog shows. It is the same for every connector.
- Copy the app's client id and secret into Client ID and Client secret.
- Choose Save and connect.
You can also enter a client in advance, under Advanced: a client registered with the provider in the Add dialog. A client you enter is always used instead of automatic registration.
If connecting fails
The row shows what went wrong and what to do. The most common cases:
| Message | What it means |
|---|---|
| The server offers no OAuth sign-in | The server does not support OAuth. If the provider gives you a token, add the server as a Bearer token connector instead |
| The server could not be reached | Check the URL, and that the server is available on the internet |
| The provider needs a registered app | See above |
| The provider refused to register XPT | The provider declined automatic registration. Register an app yourself, as above |
| Access was not granted | The sign-in was cancelled or declined at the provider. Connect again and approve |
| This connection attempt is no longer valid | The attempt expired (after 10 minutes) or was already used. Choose Connect again |
A failed or abandoned attempt changes nothing: a connector that was connected stays connected with its current account.
Give a connector to an agent
Open the agent on the Agents page (AI Studio → Agents in the sidebar). A harness agent has a Connectors section:
- Add connector lists the workspace's connectors the agent does not have yet, each with its status.
- The × on a row takes a connector away from the agent.
- A connector that is not connected says that the agent's calls to it fail until it is connected, with a link to it in settings.
Changes apply from the agent's next turn. In that turn the agent finds the connector's tools under its key, next to XPT's own tools, and uses them when the work calls for it. You do not name the tools yourself: ask in plain language, for example "@analyst find last week's launch notes in Notion and turn the open points into tasks".
Agents on a self-hosted runner need a current runner version; an older runner runs the agent's turns without connectors.
Status and reconnecting
Each connector shows its status in settings and on every agent it is given to:
| Status | Meaning | What to do |
|---|---|---|
| Connected | Ready to use | Nothing |
| Not connected | An OAuth connector that has not been connected yet, or whose URL or client was changed | Choose Connect |
| Needs reconnect | The provider no longer accepts XPT's connection, for example because access was revoked there or the account lost it | Choose Reconnect and sign in again |
| Degraded | The provider failed to answer for a moment. The connection is kept and XPT tries again on the next call | Nothing. If it persists, check the provider's status |
When a connector needs reconnecting, every workspace admin is told: in the Inbox (filter Connectors, "Needs to be reconnected") and in the email digest. Both link straight to the connector in settings. Until it is reconnected, the agent's calls to it fail with a message saying that an admin must reconnect it; the agent's other tools keep working.
Any admin can reconnect. The connection then acts as the account of the admin who reconnected, and the previous access is revoked at the provider. Reconnect is also in a connected row's ⋯ menu, for example to move the connection to another account.
Change or remove a connector
From the ⋯ menu of a row:
| Action | What it does |
|---|---|
| Edit | Change the name or the server URL, and for OAuth the registered client. Changing the URL or the client of an OAuth connector disconnects it until it is connected again |
| Replace token | Bearer connectors: enter a new token. Only the first and last characters of the current one are shown. The new token applies from the next agent turn |
| Delete | Removes the connector. The dialog names the agents that lose it; for a connected OAuth connector XPT also revokes its access at the provider. This cannot be undone. The key becomes free for a new connector |
A bearer connector stays Connected even if the provider stops accepting its token. The agent's calls then fail with a message that the token must be replaced. Replace it when the provider rotates or revokes it.
Credentials and data
| Question | Answer |
|---|---|
| Where are the credentials? | In XPT, encrypted at rest: the provider's tokens, a client secret, a bearer token. Settings shows masks only |
| Does the agent ever see them? | No. The sandbox calls XPT with a token that is valid for that one turn and that agent only. XPT checks that the agent was given the connector, adds the credential, and forwards the call. The credential never enters the sandbox |
| Can an agent reach a connector it was not given? | No. A call for a connector the agent does not have is refused |
| Whose data does the agent see? | What the connected account can see at the provider. The XPT permissions of the person who mentioned the agent do not narrow it |
| Is there a record of the calls? | Yes. XPT records every tool call an agent makes through a connector: the connector and tool, the agent, the turn, when, and whether it succeeded |
| What does the provider receive? | The agent's tool calls, with the connected account's credential. Nothing about your workspace beyond what the agent puts into a call |
Examples
Notion. Notion offers a hosted MCP server at https://mcp.notion.com/mcp. Add it with OAuth, choose Add and connect, sign in to Notion with the account the agents should act as, and approve access. Give the connector to the agents that work with your Notion pages.
Slack. Slack may require an app registered in your Slack workspace before it lets another service connect over OAuth. Add the connector with OAuth and the server URL from Slack's documentation. If Connect answers The provider needs a registered app, create the app in Slack's developer settings with the redirect URL the dialog shows, then enter its client id and secret and choose Save and connect.
For any other provider, look for its "MCP server" documentation: it gives the server URL and says whether it uses OAuth or a token.