MCP servers in runs
Your workspace registers tool servers in Settings. This page is the other half: what happens between a registration and an agent calling one of its tools.
Which runs get them
Section titled “Which runs get them”Coding runs only. A run that drives a coding agent carries your servers; chat and huddle turns do not. Those surfaces have no shell of their own, and attaching arbitrary tool servers to them would change that property.
Within a coding run, the servers attached are the ones in scope for it:
- every tenant-scoped server that is Active,
- plus the position-scoped servers for the role the assigned agent holds,
- minus self-hosted only servers when the run is going to the managed pool.
The list is resolved when the run is dispatched, so a registry change takes effect on the next run rather than on one already in flight.
How a server reaches the agent
Section titled “How a server reaches the agent”- At dispatch, the resolved list rides on the run as references to credentials, never as credentials.
- At the start of the attempt, the runner that claimed the run asks the platform for the material behind those references. It gets it once, for that attempt; a second request for the same attempt is refused.
- During the run, your servers appear beside the agent’s built-in tools. Every call goes through a small proxy the runner starts, which is where the tool whitelist is enforced and where each call is recorded for the usage panel.
The proxy is why a server’s credential never reaches the coding agent’s own environment or configuration. It lives in a 0600 file in the attempt’s directory, outside the git workspace, and it dies with the attempt. See the security model for where each kind of server sits relative to the sandbox.
When a server is broken
Section titled “When a server is broken”A broken server does not fail a run. It disappears from that run, loudly:
| What happened | What the run does |
|---|---|
| The server is unreachable, or does not answer the MCP handshake | That server contributes zero tools; the rest of the run is unaffected |
| A stdio command the runner’s machine refuses to execute | The same: zero tools from that server, the run continues |
| The OAuth connection behind it was disconnected or removed | The same, and the runner names the server and the connection in its log |
| A stored secret the registration points at was deleted | The attempt fails with a clear reason naming the server, rather than running with a partial tool set |
The last row is deliberately different. Disconnecting an account is a routine act and a run should survive it; a secret vanishing under a live registration is a misconfiguration, and quietly running without it would hide the problem.
An OAuth-backed server that outlives its access token does not break either: the runner refreshes the token mid-run through the connection and the next call succeeds.
Where to look when a tool did not work
Section titled “Where to look when a tool did not work”- The run timeline shows tool calls as they happen, so you can see whether the agent called the tool at all.
- The usage panel on the server’s detail pane counts calls and failures over the last 24 hours.
- Test connection on the same pane answers whether the server is reachable right now.
A server with a passing handshake and rising failures usually means one specific tool is broken, or that the whitelist no longer matches what the server exposes.
Next steps
Section titled “Next steps”- MCP servers: register, scope, and install them.
- Coding agents: the adapters that receive them.
- The security model: the boundary they run inside.