[FEATURE] Support disabling MCP for subagent only

[cmrenus]

Is your feature request related to a problem? Please describe.
Some tools/MCP like Atlassian include a lot of tools and are only used periodically. they pollute the context window.
In tools like Opencode, we can disable the toolset at the root level, and then create a subagent that has permissions to use those tools, effectively isolating that added context.

Describe the solution you'd like
I would like the option to use disable at an mcp or tool level within the APM config to effectively meet the same behavior.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[github-actions]

Triage decision

needs-design

What must be designed: (1) whether disable is a compile-time manifest exclusion flag or a runtime concept (outside APM's scope), (2) the schema change to apm.yml (global flag vs per-target override), (3) how the flag interacts with the existing apm-policy.yml governance layer.

Proposed labels

theme/governance
area/mcp-config
type/feature
status/needs-design

Milestone

null

Suggested next action

Author to clarify whether the desired behavior is (A) compile-time MCP exclusion from target manifests or (B) runtime per-subagent context management, so the design spec can be correctly scoped.

Suggested issue comment

Thanks for the feature request and the Opencode reference, @cmrenus -- the context-window pollution problem with large MCP tool sets is real and worth solving.

A quick clarification on APM's scope that will help us design this: APM manages install- and compile-time configuration, not agent runtime state. When you run apm compile, APM generates static target manifests (e.g., .mcp.json, .copilot/mcp.json). It does not run alongside the agent or manage which tools are visible during a session.

Given that, here are two interpretations of your request:

A. Compile-time exclusion -- a disabled: true flag in apm.yml that causes the MCP entry to be omitted from the compiled manifest. Effectively: the package installs the MCP but you opt it out of a specific compiled target. This is feasible in APM's model and worth designing.

B. Runtime per-subagent enable/disable -- dynamically toggling tool access within a running agent session, like Opencode's permission model. This is outside APM's scope today (APM generates static config files and exits). It would require the target harness itself to support context-scoped tool visibility.

Could you confirm which of these matches your need? If it is (A), we can spec out a disabled flag for MCP entries in apm.yml and how it interacts with per-target overrides. If it is (B), we can point you to the right place in the harness config instead.

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

The user's pain (context window pollution from large MCP servers) is real and widely experienced. The Opencode analogy is apt but maps to a runtime concept that APM does not own. A compile-time disabled flag would be discoverable and align with the package manager mental model. The request needs scope clarification before design can proceed.

Supply Chain Security Expert -- Risk-Surface Reviewer

No direct risk-surface implication. A disabled flag that omits the MCP from the compiled manifest is safe if it is a strict exclusion (the server entry is fully absent). Care should be taken that a disabled-but-installed MCP does not appear in the manifest in any form. No theme/security needed; theme/governance covers the config/policy surface.

OSS Growth Hacker -- Contributor-Tone Reviewer

cmrenus (NONE association, also author of #1666) is an engaged community member making multiple contributions. Tone is warm and clarifying, not dismissive. The response validates the pain point and explains APM's scope positively ("here is what APM can do") rather than defensively. Offering a concrete path forward (design the compile-time variant) keeps the contributor engaged.

Python Architect -- Architecture Reviewer

Implementing a disabled: true flag requires: (1) adding the field to MCPDependency or a wrapper, (2) filtering disabled entries out before the compile step writes the target manifest, (3) deciding whether the flag is global or per-target (per-target is more complex). A design doc should specify the schema change to apm.yml before code lands. status/needs-design is correct.

Doc Writer -- Documentation Reviewer

If a disabled flag is added, the MCP config docs and apm.yml reference must be updated. area/docs-site would ride as a secondary label in the implementing PR. Not adding it now since the design is not settled.

APM CEO -- Triage Arbiter

The feature request is strategically aligned with APM's governance/config surface -- controlling which MCPs appear in compiled manifests is a natural extension of the install model. The scope clarification (compile-time vs runtime) is the critical gate before design can start. Growth potential: context window management is a top pain point, and solving it at the package manager layer differentiates APM from manual config editing.

{
  "decision": "needs-design",
  "decision_detail": "Must design: (1) compile-time exclusion vs runtime concept, (2) schema change to apm.yml (global vs per-target), (3) interaction with apm-policy.yml governance layer.",
  "theme": "theme/governance",
  "areas": ["area/mcp-config"],
  "type": "type/feature",
  "status": "status/needs-design",
  "priority": null,
  "preserved_labels": [],
  "milestone": null,
  "next_action": "Author to clarify whether they need compile-time MCP exclusion (A, feasible in APM) or runtime per-subagent context management (B, outside APM scope), then scope the design spec."
}

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Generated by Triage Panel · sonnet46 6.5M · ◷