Allow user-configured MCP servers in ACP sessions (Antigravity & ACP providers)

[iniTwakkie]

Summary

Currently, when T3 Code launches agent sessions via ACP (Agent Client Protocol) — such as the Antigravity provider using agy_acp_server.par — the mcpServers parameter passed during session/new is hardcoded to only register T3 Code's internal t3-code HTTP server (preview, devices, link_pull_request).

There is currently no mechanism for users or workspaces to declare custom external MCP servers (stdio, SSE, HTTP) to be passed into the ACP session lifecycle.

Code Investigation & Findings

1. ACP Protocol Capability:
   The ACP specification implemented in T3 Code (apps/server/src/provider/acp/ and the underlying ACP types in bin.mjs) already supports http, sse, and stdio (command, args, env) in McpServer:

   // McpServer supports:
   // - http: { type: "http", name, url, headers }
   // - sse:  { type: "sse", name, url, headers }
   // - stdio: { name, command, args, env }

2. Current Hardcoded Injection:
   In apps/server/src/provider/Layers/AntigravityAdapter.ts (and corresponding ACP provider runtimes), mcpServers is hardcoded:

   mcpServers: mcp ? [{
       type: "http",
       name: "t3-code",
       url: mcp.endpoint,
       headers: [{
           name: "Authorization",
           value: mcp.authorizationHeader
       }]
   }] : []

   Because ACP sessions rely entirely on the client handshake (session/new) to declare tools, the underlying agent runtime (agy_acp_server.par) never discovers or loads the user's external MCP servers (e.g. from ~/.gemini/antigravity/mcp_config.json or CLI registries).

Proposed Solution

1. Configuration Schema:
   Support an mcpServers dictionary in user settings (~/.t3/userdata/settings.json) and/or workspace settings (.t3/settings.json):

   {
     "mcpServers": {
       "context-gateway": {
         "command": "/usr/local/bin/my-mcp-gateway",
         "args": ["stdio"],
         "env": {}
       },
       "remote-tools": {
         "type": "http",
         "url": "https://mcp.internal.net/sse",
         "headers": { "Authorization": "Bearer ..." }
       }
     }
   }

2. ACP Session Setup:
   When AntigravityAdapter (and other ACP adapters) prepares the session/new payload, merge user-configured MCP servers alongside the internal t3-code server:

   const userMcpServers = resolveConfiguredMcpServers(settings, cwd);
   const mcpServers = [
       ...(mcp ? [{ type: "http", name: "t3-code", ... }] : []),
       ...userMcpServers,
   ];

Benefits

• Gives ACP providers (Antigravity, etc.) tool parity with CLI agents (Claude Code, Codex, OpenCode) that already load custom MCP servers from user configs.
• Allows users to connect local databases, knowledge bases, internal APIs, and custom workspace tools directly into T3 Code threads.

[iniTwakkie]

Update / Workaround for Antigravity Users

While investigating this further, we found a provider-level workaround that works today specifically for the Antigravity provider under T3 Code:

Even though T3 Code's ACP adapter only sends t3-code in the session/new payload, the Antigravity backend runtime (agy_acp_server.par) also independently checks for its own configuration file in its provider directory:

~/.t3/userdata/providers/antigravity/<provider-uuid>/config/mcp_config.json

If you symlink or write your standard MCP configuration (e.g. from ~/.gemini/config/mcp_config.json) into that directory:

for cfg in ~/.t3/userdata/providers/antigravity/*/config; do
  ln -sfn ~/.gemini/config/mcp_config.json "$cfg/mcp_config.json"
done

The Antigravity engine will automatically discover and load those servers, dynamically registering schemas and exposing all custom MCP tools alongside T3's built-in t3-code tools. We've verified this running live with custom stdio MCP servers.

Why native T3 Code support is still needed:

• The provider directory uses an opaque hash/UUID that isn't stable across fresh installs or provider updates.
• This workaround only functions for Antigravity; other ACP providers (Codex, Claude, custom agents) cannot use this mechanism and rely entirely on session/new.params.mcpServers.
• A proper mcpServers block in ~/.t3/userdata/settings.json remains the clean, cross-provider solution.

[raiomarco]

Adding the workspace case here, as asked in #18112, which was a duplicate of this.

Antigravity documents <workspace>/.agents/mcp_config.json as its workspace MCP config (docs). Under T3 it doesn't reach the session either.

Measured on Oct 11 2026 (Linux; T3 Code nightly 0.0.46 of 2026-10-10; T3-managed Antigravity ACP server --version 1.3.0, built 2026-09-29):

• Repo side: a git worktree created by T3, with an .agents/mcp_config.json holding 4 servers (1 stdio command, 3 remote serverUrl). No ~/.gemini/config/mcp_config.json on the machine.
• Session side: at startup the agent reports exactly one MCP server, t3-code. None of the 4 workspace servers appear.
• Not verified at runtime: reading the Python packaged in the ACP server, its MCP loader merges the global/provider config with session/new.mcpServers. We found no code that discovers the workspace file. So the fix would be on the client side.

Suggested fix:

• When building session/new, read <cwd>/.agents/mcp_config.json if it exists and append its entries next to t3-code.
• Map serverUrl to the ACP url (HTTP). Keep command/args/env for stdio.
• That keeps the workspace file working the same in T3 as in agy.

The broader version (project-scoped MCP, rules, skills and subagents for every provider) is in #14118.