MCP servers

MCP servers give agents tools and data. There are two ways to provide them.

Registry MCP servers

Register an mcp manifest and install it at a scope:

{
  "id": "playwright",
  "name": "Playwright MCP",
  "version": "1.0.0",
  "type": "mcp",
  "permissions": ["browser.control", "network.outbound"],
  "mcp": { "transport": "stdio", "command": ["npx", "@playwright/mcp@latest"] }
}

transport is stdio (with command and optional env), http or sse (with url). Before an agent receives them, servers are checked with the real protocol handshake (initialize, then tools/list) within ten seconds; results are cached for five minutes. A failing server is left out, the task continues without it, and the timeline records which server was skipped and why.

Registry MCP servers are passed to agents that support MCP — today Claude Code, via --mcp-config.

Worker-local MCP servers

MCP servers configured on a worker are listed in the worker UI under MCP servers and advertised as mcp:<id> tool tags, so tasks that require them are scheduled only on workers that have them. They are checked when saved, at start-up and every ten minutes; only healthy ones are advertised.

Credentials

The platform passes mcp.env values to the server as written; it does not resolve secret:NAME references there. A token in an MCP manifest is therefore stored in the registry. For servers that need a token:

• prefer a worker-local server configured in the agent's own settings on that machine (for Claude Code, claude mcp add --scope user …), listed in the worker UI so tasks requiring mcp:<id> go there; or
• use a narrowly scoped, read-only token if you put it in a registry manifest.

Security

An MCP server is code running with the worker user's permissions. Review every third-party server before you register it: it is maintained upstream, not by us.