Repository navigation
MCP bridge opt-in for agent jobs #1609
Description
Scenario
A Squad team running inside gh-aw wants agents to use the GitHub MCP server for richer issue/PR interactions (search, cross-reference, label management). Currently the shared component disables all MCP (--disable-builtin-mcps in the compiled lock) because of network restrictions in the default agent job environment.
This means Squad agents in CI have weaker tooling than interactive Squad sessions — they can't search issues, can't cross-reference PRs, can't manage labels programmatically. Triage and review quality suffers.
Proposal
Add vars.SQUAD_ENABLE_MCP=true flag in the shared component:
- When set, the shared component skips
--disable-builtin-mcpsin the compiled lock - Includes
.mcp.jsonin the workspace artifact so agents have MCP configuration available - Document which MCP servers work within gh-aw's network constraints (GitHub MCP server works; external APIs may not)
- Provide a curated
.mcp.jsontemplate optimized for CI use (rate-limit-aware, timeout-configured)
Value
Squad agents in CI get the same rich tooling as interactive Squad sessions — better triage, smarter PR review.
Activity
bradygaster commentedon Aug 20, 2026
Closing — fails the issue clarity bar: the foundational question is unanswered and cannot be resolved without evidence.
This feature proposes \�ars.SQUAD_ENABLE_MCP=true\ to enable GitHub MCP server access in gh-aw agent jobs. EECOM's verdict: unrelated to current correctness work.
More specifically: the issue itself identifies 'which MCP servers work within gh-aw's network constraints' as an open research item — and that question cannot be answered without running agents inside gh-aw's network and observing what succeeds. The feature premise ('GitHub MCP server works; external APIs may not') is documented as a hypothesis, not a verified finding. We cannot write meaningful success criteria for an MCP integration when the runtime network reachability of the MCP server is unknown.
This is not a deferral for capacity reasons — it's a deferral because the precondition (verified MCP reachability inside gh-aw CI) is unanswered. Filing actionable work on top of an unanswered precondition produces a feature that may not work when implemented.
Per Brady's 2026-08-20 decision: every open issue must have clear, observable success criteria. This one requires answering the MCP reachability question first.
When to refile: After the 2026-08-21 E2E series (or a dedicated MCP probe run) produces confirmed evidence that GitHub MCP server is reachable from inside a gh-aw agent job. At that point 'document which servers work' has an answer and the feature can be scoped against real data.