fix: forward ACP session mcpServers to the backend's session create/resume - #43
Merged
william0wang merged 3 commits intoAug 16, 2026
Merged
Conversation
…esume
session/new and session/resume accepted an mcpServers parameter but never
read it, so client-provided stdio servers were silently dropped — the
session only ever saw the local ~/.zcode-configured servers (verified with
a trivial stdio echo server: the tool never appeared, while local servers
loaded fine).
The backend's session/create and session/resume schemas accept the ACP
mcpServers array shape verbatim (stdio entries carry command/args/env as
[{name,value}] pairs; remote entries carry type/url; the stdio branch
rejects a "type" key, so entries are passed through unchanged). This change
- stores params.mcpServers on the lazy pending session in session/new and
replays it into session/create when the session materializes,
- forwards params.mcpServers on session/resume (schema-verified: an unknown
key is rejected before the session lookup, and mcpServers is not),
Verified end-to-end through Multica (daemon -> bridge -> zcode 0.16.3):
an agent-configured echo server now appears as mcp__echo__mcp_echo next to
the runtime's own local servers (context7, web_reader, ...), i.e. the merge
is additive and the local config is untouched.
Closes william0wang#42
- mcpServers on the pending session is acp.McpServer[] (the SDK's own union) instead of unknown[] - the create-path comment asserted "client entries winning on name clash is the backend's rule" — only the additive merge was verified, so the comment now says exactly that and leaves clash behaviour unasserted
Three tests per the contributing guide's fail-before/pass-after rule: - client mcpServers from session/new are replayed verbatim into the backend's session/create when the lazy placeholder materializes - session/create omits the key entirely when none were provided (no empty-array noise for the backend's strict schema) - resume-provided mcpServers reach the backend's session/resume 461 → 464 tests, all green.
lianxin255
force-pushed
the
fix/mcp-servers-forwarding
branch
from
August 14, 2026 16:32
9d0dcf1 to
fc10bab
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #42 (option 1 from there).
What
session/newandsession/resumeaccepted anmcpServersparameter but never read it, so client-provided stdio servers were silently dropped — a session only ever saw the local~/.zcode-configured servers.This PR:
params.mcpServerson the lazy pending session insession/newand replays it intosession/createwhen the session materializes,params.mcpServersonsession/resume.Entries are passed through verbatim: the backend's schema accepts the ACP mcpServers array shape as-is (stdio entries carry
command/args/envas[{name,value}]pairs; remote entries carrytype/url). One subtlety found while probing: the stdio union branch rejects atypekey, so no field renaming ortype: "stdio"injection is done anywhere.The
session/resumeschema was verified to accept the key (an unknown key is rejected by zod before the session lookup, andmcpServersis not).Verification
vitest run: 461/461 green.node mcp-echo.mjs, onemcp_echotool) now reports:mcp_echocalled withmessage=fixed-via-forwardingreturnedMCP-ECHO-SAID: fixed-via-forwarding;echoalongside the runtime's own local servers (4_5v_mcp,node_repl,web_reader, …) — local config untouched.Context: this unblocks Multica-side agent MCP configuration for the ZCode runtime family (the integration I mentioned in #41/#42).