MCP servers

Settings → AI Configuration → MCP Servers is where your workspace decides what outside tools its agents may call. An MCP server is a service that exposes tools over a standard protocol, so registering one is how an agent gets a capability specific to your company without anybody writing an integration for it.

Viewing the registry needs mcp:servers:view; installing, changing and probing servers need the matching mcp:servers:create, mcp:servers:update, mcp:servers:delete and mcp:servers:discover permissions, which admins hold by default.

Two ways in

Install from the catalog when the tool is one we already know the recipe for: Figma, GitHub, Playwright and a couple more, listed at the top of the page. Installing one prefills the transport, the address and the credential style that tool needs, leaving you the account it should use. What lands is an ordinary registration, badged From catalog and editable like any other.

Add a custom server for anything else, with the same form starting empty.

The catalog is curated, not a marketplace

Catalog entries ship with the product and are reviewed like code. There is no third-party submission and nothing is fetched from a remote feed at runtime, so installing from the catalog cannot introduce a server we have not looked at.

Two kinds of server

The transport decides what you register.

Remote (HTTP or SSE). A server reachable by URL. The URL must be https; plain http is accepted only for localhost addresses. Remote servers can carry authentication:

• Bearer token or a custom header for services that expect a key. The form asks for the value, which is write-only: stored encrypted, never shown again, and handed to the runner assigned a run exactly once per attempt.
• OAuth connection, pointing at one of your connected integrations. An install runs the connect flow inside the form when there is no connection yet; a provider never registered here blocks the install with a link to Integrations rather than dead-ending. The registration stores the connection, never a token: each attempt gets that connection’s current access token, refreshed if the provider expired it.

Stdio. A command your runner launches inside its sandbox, such as npx @modelcontextprotocol/server-filesystem. You register the command, its arguments, and the names of any environment variables it needs. Enter their values to store them (write-only, released per attempt), or leave them blank to use the runner machine’s own environment. The registration only shows the names, and the control plane never executes the command.

Stored secrets appear in the detail pane as metadata only. Replace value rotates one in place; the current value is never displayed.

Scope and host affinity

Scope	Reaches
Tenant	Every agent in the workspace
Position	The holder of one named role

Tenant suits an analytics reader any agent might want. Position suits a server that is genuinely one function’s tool: pick that role in the form.

Some tools run on a person’s own machine: Figma’s Dev Mode server lives inside the desktop app, on a localhost address. Mark those self-hosted runners only. The form suggests it for any localhost URL, and catalog presets that need it arrive with it set. Such a server reaches runs on your own runners and is skipped for the managed pool, where a localhost address points at nothing.

The tool whitelist

The whitelist names the tools an agent may call, comma separated. Leaving it empty allows everything the server exposes.

Fill it in. A server’s tool list is set by whoever runs the server, so an empty whitelist means “whatever that service exposes next month” rather than “the three tools I checked”. It is enforced where the call happens: a tool outside the list is never offered to the agent, and a call for it is refused before your server is contacted.

Test and discover

The detail pane holds two probes:

• Test connection answers whether a remote server is reachable right now: reachable (it answered the MCP handshake), unreachable (nothing answered), or not an MCP server (something answered, but it does not speak the protocol).
• Discover tools asks a remote server what tools it has, over the protocol’s own tools/list call.

Stdio servers get neither probe: they run inside your runner’s sandbox, so they are testable only in a run, and the page says so rather than pretending to check.

Discovery lists, it does not grant

Discover asks the server what tools it has and shows them. It does not add them to the whitelist. That separation is the point: seeing a tool and allowing it are two different acts.

Usage

The detail pane shows what agents actually did with a server over the last 24 hours: calls made, calls failed, and when the last one happened. A server nobody has called shows zeros and “Never called”. The numbers are real, not estimates.

Every call is recorded as it happens: the runner reports it, the platform writes one entry to the audit trail, and this panel counts those entries. Only the tool name, the outcome, and the timing are recorded; arguments and results never are.

Read the failure count the way you read Test connection: rising failures with a passing handshake usually means one tool is broken, or that the whitelist no longer matches what the server exposes. Viewing the panel needs mcp:usage:view, which admins and viewers hold by default.

Next steps

• MCP servers in runs: which runs get these servers, and what happens when one is broken.
• The integration registry: where an OAuth-backed server’s account is connected.
• Roles: where a position scope points.