Per-agent MCP server scoping via optional "agents" field in mcp.json
- Vorherrschende Sprache
- TypeScript
- Sterne
- 193k
- Forks
- 42.4k
- PR-Merge-Kennzahlen
- PR-Kennzahlen ausstehend
Beschreibung
**Problem**
MCP servers defined in mcp.json are loaded for the entire workspace regardless of which custom agent (.agent.md) is active. The existing tools: frontmatter on a custom agent only filters visibility of tools after the fact — it doesn't stop the underlying MCP server from starting or its tool schemas from being loaded into the model's context window.
This means every server pays its full context cost (tool schemas, descriptions, parameter definitions) on every single agent invocation in the workspace, even for agents that will never call those tools. On a workspace with several heavyweight servers (Playwright, GitHub, Context7, a DB server, etc.) this adds up quickly and is pure waste for agents that only need a narrow toolset (e.g. a "Manager" agent that only needs read/edit/execute + a local SQLite server).
Concretely: with 5 MCP servers averaging ~1.5–2k tokens of schema each, a workspace can be paying 7–10k tokens of fixed context tax per request before the model has seen a single line of the user's actual prompt — multiplied across every agent, even ones with no use for most of those servers.
**Proposed solution**
**_Add an optional agents field to each server entry in mcp.json:_**
`{
"servers": {
"playwright": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@playwright/mcp"],
"agents": ["Research"]
},
"github": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"agents": ["Research", "Reviewer"]
},
"sqlite": {
"type": "stdio",
"command": "npx",
"args": ["-y", "mcp-server-sqlite", "data.db"],
"agents": ["*"]
},
"filesystem": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem"]
}
}
}`
Semantics:
agents absent, empty, or ["*"] → current behavior, server loads for all agents.
agents: ["Research"] → server process is only started, and its tool schemas only injected into context, when the active agent's name matches an entry in the list.
Agent names should match the name (or filename-derived identifier) used by .agent.md custom agents, consistent with how the existing tools: field already references agent-visible tool names.
Expected behavior / lifecycle
Parse, don't start: mcp.json parsing should build a registry of server configs without immediately spawning processes for scoped servers.
Activate on agent switch: when the active agent in a chat session changes, VS Code computes the set of servers in scope (agents absent/*/matches current agent) and starts any not-yet-running servers in that set.
Deactivate when out of scope: servers exclusively scoped to agents no longer active anywhere in the workspace should be stopped and their schemas evicted from context. To avoid thrash from rapid agent switching, apply a short idle grace period (e.g. 60–90s) before actually tearing down a process.
Multiple concurrent agents: if two chat sessions have different active agents simultaneously, a server should stay running as long as it's in scope for at least one active session.
No behavior change for existing configs: any mcp.json without an agents field continues to load exactly as it does today — this must be purely additive.
Alternatives considered
Inline MCP definitions in .agent.md frontmatter (e.g. an mcpServers block per agent file). This avoids touching mcp.json's schema at all, but introduces a second source of truth and a conflict/dedup problem when the same server name appears both in mcp.json and inline in an agent file. Worth supporting eventually, but the agents field on mcp.json is the smaller, less ambiguous change and should land first.
Rely on tools: filtering alone: doesn't solve the actual problem, since schemas are already in context by the time tools: filtering happens. This is the status quo and is the reason for filing this request.
Manual enable/disable per workspace (already possible today via the Agent Customizations editor): works but is a manual, global toggle — it doesn't give per-agent automatic scoping, and users have to remember to flip it when switching workflows.
Use case
A workspace with a "Manager" agent (read/edit/execute tools + local SQLite only) and a "Research" agent (Playwright, web search, GitHub, Context7). Today both agents load all four heavy servers' schemas regardless of which one is active. With this change, "Manager" runs with a lean context footprint and "Research" only pays the cost when it's actually the active agent.
Additional notes
This should compose cleanly with the existing enable/disable toggle in the Agent Customizations editor — a server disabled globally should stay disabled regardless of agents scope; a server enabled globally should still respect agents scoping.
Should also compose with plugin-provided MCP servers (.mcp.json inside agent plugins), which use the same underlying config shape.
Happy to draft a PR for this if there's agreement on the shape of the agents field — wanted to open the discussion on the schema first given mcp.json's config format is shared surface area.
Beitragsleitfaden
Bewertung
Dieses Issue wurde noch nicht bewertet.