Copilot engine: <mcp-clis> omits CLI-mounted github/azure-devops while <github-mcp-tools> still assumes native tools → intermittent GitHub access / silent no-ops

[matiloti]

Summary

Under the Copilot engine (--disable-builtin-mcps), the generated agent prompt does not tell the agent how to reach the github (or azure-devops) MCP server. The <mcp-clis> block — populated from __GH_AW_MCP_CLI_SERVERS_LIST__ — lists only safeoutputs, even though github/azure-devops are also mounted as CLI wrappers on PATH. Meanwhile a separate static <github-mcp-tools> block still instructs the agent to "Use GitHub MCP tools" — native tools that --disable-builtin-mcps has removed. So the agent boots with no native github tools and no documented CLI path to them, and can only reach GitHub if it guesses that the github binary exists on PATH. That guess is non-deterministic, so GitHub access is intermittent.

Environment

• gh-aw CLI v0.82.9, engine copilot (CLI 1.0.70), gateway v0.4.1, github-mcp-server v1.5.0, GHES, self-hosted runner.

What the prompt contains (compiled)

<mcp-clis> (from the template's __GH_AW_MCP_CLI_SERVERS_LIST__ placeholder):

<mcp-clis>
The following servers are available as CLI executables on `PATH`. Invoke them from bash ...

- `safeoutputs` — run `safeoutputs --help` to see available tools

For `safeoutputs` and `mcpscripts`, always use the CLI commands above.
...
</mcp-clis>

<github-mcp-tools> (static, still present):

The GitHub MCP server is read-only. Use GitHub MCP tools for all GitHub reads ...
Do not use shell `gh` commands for GitHub API reads — `gh` is not authenticated.

But the mount step reports all three were CLI-mounted:

Mounting MCP servers as CLI tools...
Found 3 server(s) in manifest to mount as CLI tools
  ✓ Mounted as: .../mcp-cli/bin/azure-devops   (Found 14 tool(s))
  ✓ Mounted as: .../mcp-cli/bin/github          (Found 25 tool(s))
  ✓ Mounted as: .../mcp-cli/bin/safeoutputs     (Found 9 tool(s))

So github and azure-devops are on PATH but absent from the <mcp-clis> list, and the only other guidance (<github-mcp-tools>) points at native tools that don't exist under --disable-builtin-mcps.

Impact — intermittent GitHub access / silent no-ops

Every Copilot run boots noting "I don't have access to GitHub MCP tools — only local filesystem and bash." From there:

• Recovers if the agent independently reasons "if safeoutputs is a CLI on PATH, maybe github is too", runs ls .../mcp-cli/bin/, finds github, and calls it.
• Fails if it instead tries gh/REST (both 401 on GHES, as the prompt warns) and gives up.

Ground truth from rpc-messages.jsonl across runs (same engine/version, github served 25 tools at the gateway every time):

Run	Workflow	github tools/call	Outcome
A	Spec Review	0 — never discovered the CLI	✗ missing_data, no output (silent no-op)
B	Spec Review (same repo, +13h)	8 (issue_read, search) via .../mcp-cli/bin/github	✓ posted result
C	PR Triage	13 via CLI discovery	✓
D	Implement	5 via CLI discovery	✓

Run A's agent never ran ls .../mcp-cli/bin/ and never tried github <tool> — it had no documented reason to. It's indistinguishable from an intentional no-op.

We also found the failure rate correlates with whether the workflow's own prose happens to name a github tool (e.g. pull_request_read, get_issue) — workflows that do reliably trigger the CLI-discovery reasoning; workflows that don't (only "read the issue") flake. That's a strong signal the gap is the missing prompt documentation, not the mount.

Suggested fix

Under the Copilot engine, make the prompt consistent with the runtime:

1. Include CLI-mounted github/azure-devops in __GH_AW_MCP_CLI_SERVERS_LIST__ (the <mcp-clis> list), the same way safeoutputs is listed, so the agent is told github <tool> is a real command on PATH; and/or
2. Suppress/rewrite the native <github-mcp-tools> block when the engine is copilot (--disable-builtin-mcps), since it advertises native tools that don't exist and even discourages the only working fallback.

Either makes GitHub access deterministic instead of dependent on the agent guessing the binary exists.

Related

• github MCP tools never registered by Claude Code despite the server answering gateway RPC calls successfully #44844 — github MCP tools never registered natively (Claude); its CLI-mount fallback (fix: CLI-mount GitHub MCP server as fallback when native HTTP init fails #44976) is what mounts github here, but the prompt was never updated to advertise it under copilot.
• "MCP Servers Mounted as Shell CLI Commands" wrongly emitted as header #35921 — earlier <mcp-clis> block formatting fix (same block, different defect).

Happy to attach full prompts / run logs on request.

[github-actions]

🏷️ Issue Triaged

Hi @matiloti! I've categorized this issue as bug based on the following analysis:

Reasoning: The issue describes a broken behavior where agents using the Copilot engine cannot access GitHub MCP tools because the <mcp-clis> block omits CLI-mounted servers while <github-mcp-tools> still instructs agents to use native tools — resulting in intermittent failures and silent no-ops.

View Triage Details

Analysis

• Keywords detected: --disable-builtin-mcps, <mcp-clis> omits servers, intermittent GitHub access, silent no-ops
• Issue type indicators: Inconsistency between generated prompt blocks causing broken tool access; reproducible defect with clear root cause
• Confidence: High

Recommended Next Steps

• Investigate __GH_AW_MCP_CLI_SERVERS_LIST__ population to include all CLI-mounted MCP servers
• Reconcile <mcp-clis> and <github-mcp-tools> blocks so they agree on available tooling

References: Triage run §29590444262

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by 🔧 Issue Triage Agent · 18.9 AIC · ⌖ 5.46 AIC · ⊞ 4.7K · ◷