MCP Servers
The bot can attach to remote Model Context Protocol servers. Each server you configure exposes a set of tools to the coding agent — reading tickets, fetching observability data, querying internal services, anything an MCP server can expose. The agent decides when to call them.
This is repo-level only. There is no org-level fallback.
How it works
Section titled “How it works”- Open the repository’s settings in the dashboard.
- Go to the MCP Servers tab.
- Click Add server and fill in:
- Name — a short slug used to identify the server (lowercase letters, digits, underscores, hyphens). The agent calls its tools as
mcp__<name>__<tool>. - URL — the server’s HTTPS endpoint. Local stdio servers are not supported.
- Headers — optional. Most hosted MCP servers want an
Authorizationheader with a bearer token.
- Name — a short slug used to identify the server (lowercase letters, digits, underscores, hyphens). The agent calls its tools as
- Save.
The next task the bot runs on this repo will attach to the server and have access to its tools.
When servers are active
Section titled “When servers are active”A configured MCP server is loaded for every task the bot runs on the repo: coding, analysis, code review, anything else. The agent only calls a server’s tools when it judges them useful, but the tools are always advertised to the model.
To stop using a server, delete or replace its entry in the dashboard. There is no per-task toggle.
Example shape
Section titled “Example shape”The fields the dashboard expects for a remote MCP server:
| Field | Value |
|---|---|
| Name | a short slug, e.g. tickets |
| URL | the server’s HTTPS endpoint, e.g. https://mcp.example.com/mcp |
| Headers | the auth header your provider expects, e.g. Authorization: Bearer <your-token> |
Check your MCP server provider’s docs for the exact endpoint URL and the token to put in the header.
Authentication: what works
Section titled “Authentication: what works”The bot configures auth by sending the headers you set on every request. That works for any MCP server that accepts a static token (an API key, a personal access token, a service-account credential) in a request header.
OAuth-based MCP servers will not work. Some providers gate their remote MCP behind an interactive OAuth flow rather than a static token. The bot runs the coding agent headlessly with no UI to click through an OAuth prompt at task time, so there’s no way to complete the handshake. If your provider’s docs only mention OAuth and don’t offer a token-based path, that server isn’t usable here today.
Caveats
Section titled “Caveats”- Tool definitions cost tokens. Each tool a server exposes is advertised in the model’s prompt on every task. Configuring many servers at once shrinks the working context.
- Server downtime is silent. If a remote MCP server is unreachable when a task starts, the agent proceeds without it and logs a warning. A task that should have used the server may quietly finish without that context.
- Rate limits live on the server side. Heavy use of a single MCP server across many tasks can hit its API limits. Watch the provider’s dashboard.
What’s not supported
Section titled “What’s not supported”- Local stdio MCP servers. The bot runs in a managed environment and cannot host arbitrary local processes. Use the remote/hosted endpoint instead.
- Org-level config. MCP servers are configured per repository. Two repositories that want the same server must both configure it.
- Per-task opt-in. Once configured, a server is active for every task type. Remove it from the config to stop using it.