rl client from Client setup.
Before you begin
- You need the organization developer or admin role to change an agent or test a server. See Organizations and roles.
- The server must use the Streamable HTTP transport at a public
httporhttpsURL. Servers on private, loopback, or link-local addresses are refused. Local servers that run over stdio aren’t supported. - If the server needs a token, have it ready. The token goes in a vault. If the service is one of the 164+ apps in Integrations, you can connect it there instead and choose its tools, without handling a token.
How a session uses an MCP server
- When a session starts, it reads the MCP servers on its agent version.
- For each server, it looks for an MCP API token in the session’s granted vaults whose server URL matches.
- It connects, lists the server’s tools, and fixes that list and the tool schemas for the whole session.
- The agent calls a tool as
<server name>__<tool name>. The token is attached to every call outside the sandbox.
Add an MCP server to an agent
Each server entry has aname and a url.
If the server
project-tracker offers list_issues, the agent sees project-tracker__list_issues. The prefix keeps two servers from clashing.
MCP servers belong to the agent version, so adding one creates a new version. Running sessions keep the tools they started with.
- Console
- TypeScript
- cURL
- In the sidebar, click Agents and open the agent.
- On Configuration, find Tools and click Add MCP server.
- Enter a Server name, then choose a server from the list or type its Server URL. The list suggests common servers, such as GitHub, Notion, Linear, Sentry, Context7, and Slack, and says what kind of token each needs.
- Click Save new version.
skills, tool settings, vault defaults, and every other field you want to keep. See Agents.
Authenticate the server
Store the server’s token in a vault as an MCP API token (bearer_token) whose server URL matches the agent’s url. Then grant the vault to the agent with default_vault_ids, or to a session with vault_ids. If you narrow grants with credential refs, include this credential.
How matching works:
- URLs match after lowercasing the scheme and host, dropping a default port (
:443or:80), and ignoring a trailing slash. A different path, subdomain, or port is a different server, so the token isn’t sent there. - The token is sent as
Authorization: Bearer <token>by default. If the credential setssecret_name, the token is sent as-is in a header with that name instead, for servers that read a header such asX-Api-Key. - If two granted vaults hold a token for the same server, the vault listed first in the session’s grants wins.
- If no token matches, the session connects without one. That works for public servers and fails for servers that need authorization.
vault-... prefix. To keep a server out of a session, don’t grant the vault that holds its token, or leave the credential out of the credential refs.
Tokens that you paste are stored as-is and aren’t refreshed. If the server issues short-lived OAuth access tokens, rotate the credential before it expires.
Test a server before you use it
probeMcpServer makes one live connection using the same URL matching and vault lookup as a session. It creates and changes nothing. Omit vault_ids to test without a token.
- Console
- TypeScript
- cURL
- In the sidebar, click Credential vaults and open the vault.
- Expand the server’s MCP API token row. It shows whether the server is reachable and how many tools it offers.
- Click Test again to run a new test.
A failed test still returns
200. Read the body:
A test gives up after 15 seconds. A server on a private, loopback, or link-local address is refused before anything is sent, so the test returns
reachable: false with the reason in error.
What success means: a passing test proves the server is reachable and that the token lets you list tools. It doesn’t prove that every tool call will succeed; permissions, arguments, and the server’s own state still matter.
Choose which tools an agent gets
A session receives every tool the server lists for its token. You can’t hide individual tools of a server. To limit what an agent can do, give it a token whose scopes allow only what it needs, or point it at a server that offers fewer tools.What happens when a server fails
- At session start: an unreachable server or rejected token doesn’t stop the session. Other servers still load, and the session’s events record an
mcp_discovery_failedwarning naming the servers. Fix the URL, server, or token, then start a new session. Running sessions don’t rediscover tools. - During a call: each request to the server has a 60-second timeout, and a response can be at most 8 MiB. A failed call returns an error to the agent as the tool result, and the agent can decide what to do next.
What can go wrong
For all error codes, see Errors. For limits, see Limits.
Next steps
Vaults and credentials
Store MCP API tokens and control which sessions receive them.
Agents
Publish a new agent version with its MCP servers attached.
Tools
See the built-in tools every session can use.
Events
Read discovery warnings and MCP tool calls in the session timeline.