[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.

[ruchirkemnaik]

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.

Thanks, this is really helpful, and the multi-tenant case is a stronger motivation.

I like the shape you're describing: a capability the Agent advertises at initialize saying it can run a session with only the Client's tools, so a host can refuse an Agent that doesn't support it before creating any session, instead of finding out from a tool call. As a backstop, if a session asks for it and the Agent can't honor it for that session, for example because of the project's or organization's settings, the Agent should fail session/new rather than quietly ignore the request. That also handles the Codex case cleanly, since an Agent that can't separate its built-ins just doesn't advertise it.

My inclination would be to treat this as a second, separate switch next to the one for the Agent's configured MCP servers, each with its own capability. Many Clients want to drop the Agent's MCP servers but keep its built-in tools, and some Agents can only support the first, so bundling them would lose both cases. A host that needs strict isolation, like yours, would turn both off. Per-tool discovery and selection of built-ins feels like a bigger design question, which also came up in this Zulip thread.

One small note on agentclientprotocol/codex-acp#548: as far as I can tell, it turns off the MCP servers in Codex's config, plus the apps, plugins and skill features that add servers, but not Codex's own shell. For built-in tools, the closest switches I found are:

• Goose: _meta.enabledExtensions on session/new sets the session's full list of extensions, so an empty list turns off both its built-in tools and its configured servers.
• claude-agent-acp: _meta.disableBuiltInTools: true turns off all built-in tools. The preferred way to do the same is _meta.claudeCode.options.tools: [].

A question for you: with built-in tools turned off, would you expect the Agent to drop everything, including things like planning tools or asking the user a question, or are there Agent-side tools you'd still want allowed? That affects how strict the definition needs to be.

I've also posted about this RFD on Zulip, where Ben said he'd take a look and would "like to revamp a lot of this". So before changing the RFD's scope, I'd like to hear from him and the other maintainers on whether built-in tools belong in this RFD or in a separate one.

[mgoldsborough]

I think two switches should work for us. We'd turn both off, and failing session/new when the agent can't honor it is the right backstop.

On what "off" should mean: the line we care about is whether a tool can reach anything outside the agent process. Shell, files, network, and any server the agent loaded itself all have to go, since those are the ways around permissions, audit and the tenant boundary. Planning or todo state that lives only in the session can stay. Asking the user can stay too, as long as it goes through the client (session/request_permission or whatever the elicitation path becomes), because then the client sees it.

So I'd define it as: no tool that touches anything outside the session except through the client.