Skip to content

feat(acp): Honor MCP servers passed from ACP clients #6111

@codefromthecrypt

Description

@codefromthecrypt

Please explain the motivation behind the feature request.

Per the ACP specification, agents MUST support stdio MCP servers passed from clients via NewSessionRequest.mcp_servers. Currently, goose ignores this field entirely in acp.rs:new_session, making it non-compliant with the protocol.

This matters because:

  1. Editors like Zed allow users to configure MCP servers that should be available to all agents
  2. Users expect consistent tool availability across different agents in their editor
  3. The spec is clear: "All Agents MUST support the stdio transport" (session-setup docs)

Describe the solution you'd like

In new_session, merge editor-provided MCP servers with goose's configured extensions, taking care to behave like --with-extension which scopes an MCP server addition, not persisting it forever.

Recommended behavior: Union with ACP wins - editor-provided servers are added to goose's built-in extensions. On name conflict, editor-provided servers win (override). This is the same behavior across claude-code-acp, gemini-cli, qwen-code, codex-acp, opencode, and openhands-cli.

Describe alternatives you've considered

  1. Replace all: Editor servers replace goose's built-ins entirely - too disruptive
  2. Goose wins on conflict: Built-ins override editor servers - violates user expectations
  3. Error on conflict: Reject sessions with conflicting names - poor UX

Additional context

The McpCapabilities in goose's initialize response currently sets http(false) and sse(false), which is correct for now, but should be implemented to close this issue. The first gap to fill is that even stdio servers (which are mandatory) are ignored.

  • I have verified this does not duplicate an existing feature request

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestp2Priority 2 - Medium

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions