#242 MCP access for members should be topology-aware with feature-flag control

[Anonymous]

Originally created by: kumaakh

Background

Issue [#219] identified that Gemini members incorrectly load the apra-fleet MCP server. PR [#228] attempted to fix this but is ineffective — local Gemini members still have all 26 fleet-mcp tools loaded today.

Root cause: apra-fleet install --llm gemini writes apra-fleet into the global ~/.gemini/settings.json, so it loads in every Gemini session by default. PR [#228]'s fix used incorrect field names (mcpServers: {} instead of mcp.excluded, and --allowed-mcp-server-names "" which is ambiguous).

Problem with a blanket "disable all MCP" fix

Disabling fleet-mcp for all members is too aggressive. Remote members may legitimately act as sub-orchestrators in tree/forest agent patterns — a remote member receiving a large complex task should be able to fan out to a sub-fleet. This is a valuable product use case we must not lock out.

Architectural vision

MCP access should be topology-aware and feature-flag controlled, not hardcoded per role:

Member topology	fleet-mcp default	Overridable?
Local member (any LLM)	Disabled	Yes, via flag
Remote member (any LLM)	Enabled	Yes, via flag
Local member explicitly granted orchestrator rights	Enabled	Yes, via flag

This should work identically across all LLM providers (Claude, Gemini, Codex, etc.) — provider-agnostic.

Tactical fix needed (immediate)

Local Gemini members should not load apra-fleet MCP, exactly as local Claude members currently do not.

Fix required in src/providers/gemini.ts → composePermissionConfig:

Current (broken):

const settings = { mode, mcpServers: {} };

Should be (pending verification of correct Gemini CLI field):

const settings = { mode, mcp: { excluded: ["apra-fleet"] } };

The --allowed-mcp-server-names "" flag in buildPromptCommand also needs verification — empty string behaviour is ambiguous; correct value may be "none" or the flag should be dropped in favour of settings.json alone.

Needs verification: mcp.excluded vs admin.mcp.enabled — there is conflicting information between docs/research-219-gemini-mcp.md and live Gemini CLI 0.40.1 behaviour on fleet-dev2. The correct field name must be confirmed with a live test before shipping.

Acceptance criteria

• [ ] Local Gemini members do not load apra-fleet MCP tools on startup (verified live)
• [ ] Remote Gemini members can load apra-fleet MCP tools (fan-out use case preserved)
• [ ] Member config supports an explicit allow_fleet_mcp flag to override the default
• [ ] Behaviour is consistent across Claude, Gemini, and any future LLM provider
• [ ] All combinations are possible via config — no options are permanently locked out

References

• Issue [#219] (original report)
• PR [#228] (broken fix)