Skip to main content

MCP servers are reached over HTTP and handed to the agent

Organizations connect their agents to MCP servers such as Linear or Datadog: a URL and how to authenticate, a bearer token or headers, plain or taken from a secret. Mission Control never runs an MCP server; it only knows them by URL. When a run's session opens, the server adds the enabled MCP servers its role has, given to it or to every role, to the session's MCP servers next to Mission Control's own, with their secrets decrypted, and the agent's runtime connects to them directly. Only owners set them up and give them to roles, as with secrets and environment variables; agents cannot, so no permission or tool covers them.

Considered Options​

  • Local (stdio) MCP servers, a command the organization sets: rejected; any organization owner could then run any program on the host as the server's user, which ADR 0006 rules out for runtimes for the same reason. A local server that is needed would come, as runtime kinds do, as one the server defines in code.
  • Mission Control as a proxy: its own MCP endpoint lists each server's tools and forwards calls to it. It would keep secrets on the server, allow a role to be given only some of a server's tools and record every call. Deferred: it costs a connection per organization and server, tool namespacing, and forwarding progress and cancellation, and nothing asks for those yet. Runs get their MCP servers from one place in the MCP server service, so a proxy would replace what that returns and nothing else.
  • A permission for agents to set up MCP servers or give them to roles: rejected; an MCP server is credentials, and those stay with people (ADR 0002). An agent with roles.manage could otherwise give its own role the organization's Datadog keys.
  • A status kept for each MCP server, checked in the background: rejected; nothing would act on it. Owners test a server's URL and authentication from its form instead, which lists its tools.

Consequences​

  • The agent's runtime holds the decrypted header values for the length of the session. The model is not shown them, but they are as exposed to the agent's process as environment variables taken from secrets already are.
  • A role gets all of an MCP server's tools. Narrowing them is done where the server allows it: in its URL (Datadog's toolsets) or in what its key may do (a Linear key with read access only).
  • A role's MCP servers are looked up each time its agent opens or continues a session, so a change reaches a run when its agent next starts: an agent kept running between turns keeps what it had.
  • Mission Control only sees an MCP server's tools being used through the tool calls a runtime reports on the run; a failing server shows up there, not in Mission Control.
  • Testing a server makes the Mission Control server request a URL an owner chose; it only ever initializes and lists tools, never calls one.
  • OAuth is one more way to authenticate, added beside bearer and headers, with Mission Control refreshing the token before it hands the server to a session.