MCP connections

Connection lifecycle

Instance servers connect when the plugin loads, and both the connection and the tool discovery are limited by the connect timeout. Personal remote servers connect when one of their tools is first called; until then their tools are listed from the last successful discovery, and a server without a saved discovery has to be reconnected before its tools appear.

Personal tools are registered only for the account that owns them. Instance tools are available to every conversation, and account tool permissions can still restrict individual tools.

Retry policy

A connection attempt that fails on the network, times out, or answers with HTTP 408, 429 or a server error is retried a bounded number of times, and the server's status reports the attempt in progress.

A server that needs sign-in, refuses the request with HTTP 401 or 403, or answers with a protocol error is not retried. The operator reconnects it once the cause is fixed.

Project-bound servers

A stdio server created while a managed Project is selected is bound to that Project and runs there; the binding cannot be changed later, and saving it checks the current access to the Project even when the server is disabled. Central environment values cannot be imported into a managed Project, so its credentials are configured inside the Project.

After a successful reconnect of a project-bound server, the result reports it as verified in its project rather than connected: its connection status stays disconnected because each operation opens and closes its own connection, and Reconnect all counts these verified servers separately from live connections and failures.

Paired computer execution

HTTP and API-only MCP operations remain usable in local conversations. For a selected paired computer, stdio servers run on that computer with its installed commands and working directory, so the command must be installed there.

Each operation opens and closes its own connection and process, including initialization, so a later turn starts a new operation. Centrally stored command environment variables are refused, because their values belong to the host; credentials for such a server are configured on the computer itself.

A disconnected operation fails with LOCAL_EXECUTION_LOST and is never replayed or run on the daemon host.

Scope and name rules

apiContract.mjs is the pure declaration source for the nine authenticated management/OAuth routes. Runtime registration spreads its descriptors and uses their exact schemas with lazy request parsers; importing declarations starts no clients and reads no database or vault. JSON management bodies deliberately retain their unrestricted wire shape: scope ownership is checked before the existing server/domain validation, and changing that order would change errors and authority. Raw JSON syntax failures retain the existing 409 management response. Named OAuth operations use exact decoded names; server update/delete use the existing trimmed lookup. No new agent or personal-token gate is added.

The browser MCP server page is the real management consumer. Optional expectedRevision remains optional, PATCH merges the current specification before normalization, and transfer and PATCH use distinct revisions. Server creation can return 201; management and OAuth results otherwise retain their existing JSON/status contracts. No live registration exists when plugin initialization fails. Native bridge snapshots, remote tools and execution leases are not exported by this JSON API.

A server name can be reused across the personal and instance scopes but not twice within one scope. Because instance servers are visible to every account, a personal server cannot take the name of an instance server.

A remote HTTP server can move between the instance scope and the acting account's personal scope; a move never transfers it to another account. A stdio server cannot move, so it is created again in the target scope.