Workspace-scoped MCP registration — or is CLI + workspace skill the intended pattern?

[Matthew-Laplace]

Ask: a supported way to scope an MCP server registration to the workspace a session runs in — or explicit confirmation that "CLI + workspace skill" is the intended pattern for workspace-local capabilities.

Why

Two MCP servers registered at the profile root (a pair of EDA bridges) put 18 tools / 12,486 characters of schema ≈ 3.1k–4.2k tokens into every request of every session in that profile, including sessions in workspaces that will never call them. Measured in a live session with cordis_inspect_query, Host Tool.listTools:

source	tools	schema chars	≈ tokens/request
github MCP	90	109,132	27.3k–36.4k
builtin	39	30,608	7.7k–10.2k
bridge A	14	9,106	2.3k–3.0k
bridge B	4	3,380	0.85k–1.1k
total	147	152,226	38k–50.7k

(chars/4 … chars/3 over schema text; not a tokenizer count.) The point is not the absolute number but that it is unconditional: there is no way to say "this capability belongs to this workspace".

What I can see in 0.2.0-rc.2 (desktop, macOS)

• @deepseek-ai/dsh-mcp-client's config is serverName / command / args / env / cwd / toolCallTimeoutMs / failOnStartupError / maxInstructionBytes / reconnect (Host Config.listConfigs). cwd is the child process's working directory, not a visibility filter.
• Registration is scoped to the Agent scope: the client README says "reserves the serverName inside the current registration scope", "An empty caller scope adds no MCP tools or prompt text", "Independent Agent scopes may reuse the same namespace because their tools and transports are isolated".
• @deepseek-ai/dsh-agent-preset is {id, name, description, order, plugins[]}, and the bundled editing-cordis-compositions skill states "Preset plugins contribute scoped tools". So the knob that exists is per preset, and presets are selected per session — not per workspace.
• skill-filesystem and agent-instructions do resolve workspace roots (per-workspace .git), but MCP does not participate in that resolution.

Questions

1. Is a workspace-conditional registration meant to be expressible at all? Right now !!js in a preset's child entries is evaluated when the child plugin activates (agent creation), where there is no workspace context — so !!js cannot currently mean "only when this session's workspace is under X". Is that a deliberate boundary, or a gap worth a feature request?
2. If it is a deliberate boundary, is "CLI + workspace skill" the intended pattern for workspace-local capability? If so, one sentence in the MCP client docs (or in editing-cordis-compositions) would save each user from rediscovering it — today the obvious reading is "just register an MCP server", which is exactly the choice that taxes every session in the profile.
3. If per-preset is the intended granularity: is deriving a preset from another one planned? A preset's plugins is a complete list with no inheritance, so scoping a single MCP row to one preset currently means forking a shipped preset and re-syncing it on every upgrade.

Workaround I am using meanwhile

Move the MCP rows out of the profile into a dedicated preset (keeps tool-shaped access, costs a forked preset), and/or drive the same engines through their CLIs from a workspace skill (the CLIs already exist; the MCP servers are thin adapters). Both work; neither is a way to say "this workspace only".

Happy to turn any of this into a concrete proposal or a patch to the docs if that helps.

[mcmichealkaluna-debug]

Adding measured evidence from the same gap, one level up — agent presets.

We run three custom presets in one profile: work (daily), travel (adds the map/rail MCPs), dsh (harness maintenance). Measured with Tool.listTools in live sessions:

preset	MCP tools visible
work	11
travel	72

So the unconditional cost you measured applies at the preset level too: every session pays for the capability set of whichever preset happens to be the profile default.

We then tried to close it with a plugin, and hit a wall worth reporting.

Our host plugin listens on agent/created, reads agent.session.header.cwd, looks up a workspace→preset map, and calls ctx.agentPresets.select(agent, presetId). The log says it works:

✔ Travel: dsh → travel (source=resume)

…but the next new session fails to start:

gateway/internal: failed to create session:
Error: tool "subagent" is already registered in this scope

select() at agent/created time re-composes an agent whose first composition has already registered tools, and the two collide.

The API documentation points at the correct moment — mount(ctx, id):

"Bind an unpublished Agent to the current preset revision. @PARAM ctx — Agent context from its setup callback."

but that setup callback is supplied by DSH's own session-creation path, and no extension point lets a plugin participate in it.

Ask — either would remove the need for a plugin on the session-creation path:

1. an extension point that runs before the first composition, so a plugin can choose the preset from workspace facts; or
2. a declarative workspace→preset map in the profile (sibling to default / selectedDefault), applied at session creation.

Your question 1 also applies here verbatim: !!js in a preset's child entries is evaluated at child activation, with no workspace context.

Environment: dsh 0.2.1-alpha.4 · Windows 11 · profile web.