Session-scoped MCP over ACP: mcpServers is hard-rejected, though dsh-mcp-client already speaks streamable HTTP

[chyroc]

Summary

session/new rejects any non-empty mcpServers:

packages/acp/acp/src/index.ts:544
  if (params.mcpServers.length > 0) throw invalidParams('mcpServers is not supported')

We'd like a way for an ACP client to contribute an MCP tool surface to the session it creates. Filing this as the "we may be wrong about the shape" one of our notes — the capability plumbing already exists, so what's missing is mostly a policy decision, and that decision is yours.

Context: we run a multi-tenant agent platform with DSH as an inference backend, with real inference working over ACP.

Why this one stands out

The harness already has everything needed. @deepseek-ai/dsh-mcp-client (packages/mcp/mcp-client/) connects to external MCP servers and registers their tools on ctx.tools under mcp__<serverName>__<rawName>, and it already supports streamable HTTP as a first-class transport (packages/mcp/mcp-client/src/index.ts:78, schema at :120) alongside stdio (:52, :109).

The ACP SDK also already models this end of it: AgentCapabilities.mcpCapabilities (dist/schema/types.gen.d.ts:75) with { http?, sse?, acp? } (:2277), and per-server variants McpServerHttp (:2384), McpServerSse (:2411), McpServerStdio (:2438), McpServerAcp (:2344).

So the gap is that MCP servers are deployment-configured (a row in cordis.yml, fixed at process start) and cannot be session-scoped (supplied by the client at session/new). For a host serving many tenants from one harness process, that's the distinction that matters: different tenants need different tool surfaces, and the tool surface isn't known until the session is created.

Why we care about the vendor-neutral path specifically

We got our tools in — see the workaround below — so this isn't a blocker for us anymore. We're raising it because MCP-over-HTTP is the only vendor-neutral way to give DSH an external tool surface. Everything else means either patching the harness or coupling to a private interface, and the whole point of MCP is not having to do that.

Ask

In rough order of how much we'd expect you to want them:

1. Accept mcpServers at session/new for the HTTP transport only, and advertise mcpCapabilities: { http: true } at initialize. HTTP-only keeps the blast radius small: no child-process spawning from a client-supplied config, which we assume is a large part of why this is closed today. Stdio servers would keep rejecting, honestly advertised as { http: true, sse: false }.
2. Or a deployment-level allowlist — the deployment configures which MCP endpoints are permitted, and a client may select from them by name at session/new. This keeps the trust decision entirely with the operator, which may suit the automation-only posture better.
3. Or, if neither is wanted: document the intended path for giving an ACP-hosted session an external tool surface. Right now mcpServers is not supported reads as "not yet" rather than "by design, do X instead," and we spent a while looking for the X.

We'd note that (1) is the shape the official ACP spec expects and the one other ACP clients will already be written against, so it's also the least surprising to third parties.

Security caveats we'd want you to weigh

We don't want to hand-wave these, since they're presumably the reason for the current block:

• A client-supplied URL means the agent process makes outbound requests to a client-chosen endpoint — SSRF surface, and a sandbox-policy question if the deployment assumed no arbitrary egress.
• Client-supplied MCP tools land in the model's tool namespace, so name collisions and prompt-injection-via-tool-description both become live concerns. Server-qualified names already mitigate the first.
• Per-session MCP connections need lifetime tied to the session, which interacts with the connection-owned teardown in src/index.ts:450-510.

If those are the blockers, option (2) sidesteps all three and we'd be happy with it.

Our workaround

We externalize tools entirely: a single MCP server, configured as a deployment-level mcp-client row pointing at our own gateway, which then routes per-tenant. That gets us multi-tenant tool surfaces without session-scoped mcpServers, and it keeps tool execution off the harness host, which we wanted anyway for isolation. The cost is an extra hop and that the tool surface can't vary per session within one process — every session in a process sees the same tool names, and per-tenant differentiation has to happen behind our gateway rather than in the harness.

That workaround is sound enough that we're not asking for this urgently. We'd mostly like to know whether session-scoped MCP is "not yet" or "not ever," because the answer changes how we'd build the next layer.

Offer

Happy to prototype (1) or (2) if you'd take a PR, and equally happy to just get a documented answer for (3).

[denial123789]

The current source makes the ownership gap concrete: dsh-mcp-client is a Cordis plugin whose transport, reconnect loop, namespace reservation, and tool generation live at deployment scope; ACP creates Agents later and rejects non-empty mcpServers. Bridging the schema alone would therefore leave the harder lifecycle and authority questions open.

For a multi-tenant platform I see four distinct shapes:

1. Host per tenant/trust domain: strongest fit with today's ownership.
2. Deployment allowlist plus Session selection: the client selects reviewed names, never URLs/headers, and tool lookup must be Agent-scoped rather than merely hidden from prompts.
3. One authenticated Streamable HTTP gateway: practical today, but tenant identity must come from trusted execution context, not a model-controlled tool argument.
4. Direct client HTTP: requires resolved-address and redirect SSRF controls, secret references, quotas, atomic namespace rollback, Agent-owned registrations, and complete teardown. HTTP-only avoids local process spawning but is still arbitrary egress.

There is also a close-semantics dependency: rc.2 has connection-owned ACP teardown, not per-Session close. Native Session MCP needs to reject new calls, settle in-flight calls, stop reconnect timers, unregister tools, close transport, and only then dispose that Agent.

I wrote up the four designs and a twelve-case acceptance matrix here: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/integrations/acp-session-scoped-mcp.md

Disclosure: I maintain the SandBase community handbook.

[weijiafu14]

@denial123789 is right that the schema is the easy half and the lifecycle/authority questions are the hard half. I can contribute evidence on exactly that half, because an agent-scoped, runtime-supplied MCP tool surface already runs on DSH's public seams today — just not through dsh-mcp-client.

I maintain an out-of-tree compatibility engine, so treat this as an interested party's report; but the useful part is what it proves about the host, not about my package.

What is verified end to end on a real DSH loop (Web, stock dsh-TUI, and a third-party TUI, with a runnable example): a user adds and removes MCP servers at runtime, in a live session through a manager UI — stdio, Streamable HTTP and SSE, with OAuth (discovery/DCR/PKCE/localhost callback/refresh), a lazy proxy so dozens of servers do not eat context, plus resources, prompts, images, structured content, approval, elicitation, sampling and reconnect. The tools land on ctx.tools and the model uses them in the same session that added them.

Why that matters for your ask: it means "an MCP tool surface that arrives after the Agent exists, scoped to that Agent" is not a new lifecycle model that has to be invented for ACP. The seam already carries it. What is deployment-scoped in dsh-mcp-client is a property of that plugin's design, not a constraint of ctx.tools.

Two implementation landmines, both of which cost me real time, both relevant to whoever implements your ask #1:

1. Split the two halves by scope, and do it with agent/created, not with a per-surface handshake. The connection/credential/catalog half wants to be one shared thing anchored at the root context (one credential store, one login, one upgrade unit); the tool surface half must be per-Agent, mounted from agent/created into the public agent.ctx so that Agent disposal unwinds it automatically. I verified this against stock npm packages with a contract test. Two things I got wrong first: setup(agentCtx) is the creator's parameter and is unreachable from a root plugin; and agent/session-start is documented as explicitly unusable as a startup gate. A config-declared Agent also never goes through the creator's setup path at all — which for your multi-tenant case is the difference between "works for sessions my client creates" and "works".

2. assembly.tools is snapshotted before the system-prompt/assemble waterfall runs. So a tool surface registered even slightly late is absent from the model's tool list for that turn, with no error anywhere — it simply behaves as if the tenant has no tools, then works on turn two. The waterfall is awaited and its return value is authoritative, so the fix is to gate on mount completion inside system-prompt/assemble and re-read tools.schemas(agent) to top up the pre-waterfall snapshot; tools/pre-execute needs the same wait. For session/new + immediate session/prompt — which is the normal ACP shape — this is not a corner case, it is the default timing.

On your ask #1 vs #2: from where I sit, HTTP-only (#1) and the deployment allowlist (#2) are not really alternatives. The allowlist answers "who decided this endpoint is acceptable", and the session-scoped list answers "which of the acceptable ones does this tenant get". A multi-tenant host wants both, and #2 alone still leaves you unable to give two tenants different surfaces unless selection-by-name is per-session — which is #1's plumbing with a narrower value type. Worth saying explicitly in the proposal so they are not treated as an either/or.

What I cannot help with, plainly: we have never touched the ACP bridge and could not implement any of this. My evidence is about ctx.tools, agent scoping and assemble timing — the general seams — not about ACP, and none of it makes session/new accept mcpServers. That decision is DSH's, exactly as you said.