Allow external custom agents (installed from plugins) to access globally configured MCP servers

[czambrano-pragma]

Describe the feature or problem you'd like to solve

When a custom agent is installed from an external plugin, its .agent.md file is owned by the plugin author and cannot be modified by the end user. The only current mechanism to grant an agent access to an MCP server is to declare it explicitly in the agent's frontmatter under mcpServers:. This works for locally authored agents, but breaks entirely for plugin-distributed agents where the frontmatter is immutable from the user's perspective. The user may already have MCP servers registered and working in their primary Copilot CLI session via ~/.copilot/mcp-config.json, but a plugin-installed agent cannot inherit that access — even though the user's intent to use those servers is already explicitly declared at the environment level.

Proposed solution

Option A — Layered MCP resolution (zero-config)

Introduce a MCP server resolution order similar to how configuration inheritance works in most developer tooling:

1. Agent frontmatter (agent-specific, highest priority)
2. Workspace config — .copilot/mcp-config.json at repo root
3. Global user config — ~/.copilot/mcp-config.json (lowest priority, user-wide)

When a custom agent declares a tool namespace (e.g. mcp-hello-world/*), the runtime walks this chain until it finds a matching server definition. If
found at any level, the server is made available to that agent for the session — no frontmatter modification required.

Option B — Explicit CLI flag

Introduce a --load-all-mcp flag to the copilot command that forces all servers registered in ~/.copilot/mcp-config.json to be available to every
agent running in that session, regardless of frontmatter declarations:

copilot --allow-all-tools --load-all-mcp
copilot --model claude-haiku-4.5 --allow-all-tools --load-all-mcp

This gives the user explicit, opt-in control at invocation time — no changes to plugin files, no global config side effects. It also works as an escape
hatch during development or debugging when the user wants to quickly grant full MCP access without editing any configuration file.

Option A is preferred for day-to-day use as it requires no change to invocation habits. Option B complements it by providing a runtime override that is
transparent and auditable.

Both approaches are fully backwards-compatible.

Benefit: Plugin authors can ship agents that declare tool namespaces, and users can wire those namespaces to their own MCP servers via global config or
CLI flag — without either party needing to touch the other's files.

Example prompts or workflows

1. A user installs a plugin and immediately uses its agent without any manual configuration, because the MCP server they already registered globally is
   automatically available to the new agent.

2. A team shares a plugin internally. Each developer has their MCP server running at a different local path. Each developer registers it once in
   ~/.copilot/mcp-config.json and the plugin's agent resolves it automatically — no per-agent setup needed.

3. A plugin ships an agent that uses mcp-hello-world/* tools. The user runs:

gh copilot plugin install https://github.com/org/my-plugin

Then asks the agent a question. The agent calls mcp-hello-world/greet successfully because mcp-hello-world is already in the user's global MCP config —
zero additional configuration required.

4. A workspace .copilot/mcp-config.json defines a project-specific MCP server. Any plugin-installed agent used in that workspace automatically gets
   access to it, scoped only to that project.

5. A user switches between two projects, each with a different MCP server registered at workspace level. The same plugin-installed agent resolves the
   correct server depending on which workspace is active.

Additional context

• Copilot CLI v0.0.420, macOS Darwin
  • The primary Copilot CLI session already inherits all servers from ~/.copilot/mcp-config.json — this request asks for parity between the primary session
    and agents running inside it.
  • There is currently no workaround that doesn't require modifying a plugin-managed file, which would be overwritten on the next plugin update.