[ruchirkemnaik]

Summary

This RFD proposes letting Clients see, and turn off for a session, the MCP servers an Agent loads from its own configuration (user and project settings, plugins). Today ACP only knows about the mcpServers a Client sends on session/new, so the Client never sees the rest.

The draft covers the problem and a direction, in two parts:

• Read path: list the Agent's own MCP servers with their identity, transport, and scope, ideally before session/new.
• Control path: let a Client turn some or all of them off for one session, without changing the Agent's stored configuration.

The wire format and method name are deliberately left open for discussion.

Why now

• The Codex and Claude adapters already work around this in their own ways: _meta strict-MCP options, their own rules for name clashes, and a /mcp slash command. See feat: add _meta.codex.strictMcpConfig for client-only MCP servers codex-acp#548, feat: report the MCP servers that the Codex config replaces codex-acp#587, fix: prefer compatible session MCP servers codex-acp#534, and feat: answer /mcp in chat with the MCP server status and a reconnect claude-agent-acp#1218.
• In v2, Clients are expected to provide file and terminal tools through mcpServers, so overlap with the Agent's own servers matters more.
• In review of docs(rfd): add dynamic MCP server updates in live sessions #582, @benbrandt asked for "a way to retrieve all currently configured MCPs in case there were some from other agent config?" This RFD takes up that question.

Related

• docs(rfd): add dynamic MCP server updates in live sessions #582: dynamic MCP server updates. Complementary: it covers changing the Client's servers mid-session.
• Configurable LLM Providers RFD: the closest precedent (providers/list, providers/disable).
• Zulip: Disabling built-in tools and Native Tool Discovery and Selection. Built-in tools are out of scope for this RFD.

Feedback wanted

I'd especially like to hear whether the problem statement matches what Client and Agent implementers see in practice. I'm happy to drive the design and schema work, and would welcome a champion to work with.

Changes

• Add docs/rfds/agent-configured-mcp-servers.mdx
• List it under the Draft RFDs in docs/docs.json

---

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY.

[mgoldsborough]

The read path and the per-session off switch are what a host needs from an agent, and doing it per session without touching the agent's stored config is right.

Built-in tools are the other half, and they matter more to us than config-loaded servers. We run agents as remote workers for many tenants. Every tool call has to go through the MCP servers we hand over at session/new, because that's where permissions, audit and the tenant boundary are enforced. An agent that also has its own shell or file tools can step around all three, and the host can't tell from ACP whether it will.

Agents already handle this, each in its own way. Goose takes an explicit extension set in _meta, claude-agent-acp has disableBuiltInTools, and codex-acp is discussing a strict mode in #548. So the behavior exists; what's missing is a way to ask for it and know it took. Could the control path cover built-in tools too, behind a capability the agent advertises at initialize? Then a host can refuse an agent that can't run with only the client's tools, instead of finding out from a tool call. I'm aware of the "90% of what Codex does is bash" point. An agent like that doesn't advertise the capability, and the host decides what to do about it.