You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I'm always frustrated when a shared team repo declares its MCP servers in dependencies.mcp: and there is no way to make them available outside that repo. The servers are general developer tooling (docs fetchers, issue tracker, code quality, browser automation), so they should be available in every repo a developer works in — but they are only configured when the shell is inside the team repo.
There is no command that deploys a project's MCP list to user scope. apm install -g reads ~/.apm/apm.yml and never the project's own apm.yml, so the entries cannot get there. The practical effect is that "one shared repo declares the tooling, every developer runs one command and has it machine-wide" is not expressible today, even though both halves of it exist separately.
Describe the solution you'd like
A flag on the existing command that keeps the project manifest as the source while writing at user scope:
apm install --only mcp -g --from-project
Read dependencies.mcp: from the project manifest, merge into the user manifest (upsert by server name, leaving unrelated user entries untouched), then deploy through the existing user-scope pipeline and runtime capability filtering. No new deployment logic — only the source of the entries changes.
The naming is secondary; the capability is what matters: use the project manifest as the source while writing at user scope.
Describe alternatives you've considered
apm install --only mcp -g — deploys correctly, but only entries already present in ~/.apm/apm.yml. No supported way to get the project's entries in there in the first place.
Depending on the team repo as a global package (apm install -g <repo>) — MCP entries only propagate transitively for whole-package dependencies, which requires --trust-transitive-mcp and additionally deploys the repo's agents and instructions globally into every unrelated project. Too blunt.
What we actually do: a script in the team repo that splices the project manifest's mcp: block into ~/.apm/apm.yml between marker comments (so the developer's own entries survive), then shells out to apm install --only mcp --target <runtime> -g for the deployment half. It is idempotent and works well, but it hand-edits a file APM owns and will break silently if the manifest schema or nesting changes.
Additional context
Add any other context or screenshots about the feature request here.
Is your feature request related to a problem? Please describe.
I'm always frustrated when a shared team repo declares its MCP servers in
dependencies.mcp:and there is no way to make them available outside that repo. The servers are general developer tooling (docs fetchers, issue tracker, code quality, browser automation), so they should be available in every repo a developer works in — but they are only configured when the shell is inside the team repo.There is no command that deploys a project's MCP list to user scope.
apm install -greads~/.apm/apm.ymland never the project's ownapm.yml, so the entries cannot get there. The practical effect is that "one shared repo declares the tooling, every developer runs one command and has it machine-wide" is not expressible today, even though both halves of it exist separately.Describe the solution you'd like
A flag on the existing command that keeps the project manifest as the source while writing at user scope:
Read
dependencies.mcp:from the project manifest, merge into the user manifest (upsert by server name, leaving unrelated user entries untouched), then deploy through the existing user-scope pipeline and runtime capability filtering. No new deployment logic — only the source of the entries changes.The naming is secondary; the capability is what matters: use the project manifest as the source while writing at user scope.
Describe alternatives you've considered
apm install --only mcp -g— deploys correctly, but only entries already present in~/.apm/apm.yml. No supported way to get the project's entries in there in the first place.apm install -g --mcp NAMEper server — single server, imperative. Our servers are self-defined (registry: false), so this means restating everycommand/args/envon the command line, duplicating what the projectapm.ymlalready declares and leaving two copies to drift apart. (This path is also currently rejected — [BUG]apm install -g --mcpis rejected outright: "MCP servers are project-scoped" #2548, fix in flight in fix: allow global direct MCP installs (closes #2548) #2734 — but even once fixed it does not address this request.)Depending on the team repo as a global package (
apm install -g <repo>) — MCP entries only propagate transitively for whole-package dependencies, which requires--trust-transitive-mcpand additionally deploys the repo's agents and instructions globally into every unrelated project. Too blunt.What we actually do: a script in the team repo that splices the project manifest's
mcp:block into~/.apm/apm.ymlbetween marker comments (so the developer's own entries survive), then shells out toapm install --only mcp --target <runtime> -gfor the deployment half. It is idempotent and works well, but it hand-edits a file APM owns and will break silently if the manifest schema or nesting changes.Additional context
Add any other context or screenshots about the feature request here.