β¨ feat(desktop): execute tunneled stdio MCP calls from the gateway#15470
Merged
arvinxx merged 1 commit intoJun 4, 2026
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Codecov Reportβ
All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## feat/gateway-tunnel-type-discriminator #15470 +/- ##
===========================================================================
- Coverage 89.21% 70.84% -18.37%
===========================================================================
Files 892 3255 +2363
Lines 108158 321102 +212944
Branches 10605 28385 +17780
===========================================================================
+ Hits 96495 227499 +131004
- Misses 11481 93421 +81940
Partials 182 182
Flags with carried forward coverage won't be shown. Click here to find out more.
π New features to boost your workflow:
|
8bffb3c to
da7f909
Compare
fd027b0 to
af4389f
Compare
da7f909 to
6af0271
Compare
af4389f to
258fa57
Compare
6af0271 to
f944d42
Compare
Contributor
π Desktop App Build Completed!Version: π¦ Release Download Β· π₯ Actions Artifacts Build Artifacts
Warning Note: This is a temporary build for testing purposes only. |
e09d95d to
138f5fc
Compare
2 tasks
138f5fc to
a421583
Compare
2e2b657 to
50360df
Compare
Receiving half of the gateway stdio-MCP work. When the cloud server tunnels a stdio MCP tool call to this device (a `tool_call_request` carrying `mcpParams`), run it locally instead of falling through to the builtin local-system tool switch (which keys on apiName and has no MCP context, so it rejected these as "not available on this device"). - `gatewayConnectionSrv`: add a dedicated `mcpCallHandler` + `setMcpCallHandler`; `handleToolCallRequest` routes on the presence of `toolCall.mcpParams`, sharing the existing response-envelope path. - `GatewayConnectionCtr`: wire `setMcpCallHandler` β `executeMcpCall`, which maps the wire payload to `McpCtr.runStdioMcpTool`. - `McpCtr`: extract `runStdioMcpTool` core from the `callTool` IPC method so both the renderer and the gateway tunnel share one stdio execution path (no SuperJSON round-trip for the in-process caller). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
a421583 to
ca724ac
Compare
e85d011
into
feat/gateway-tunnel-type-discriminator
31 of 32 checks passed
arvinxx
added a commit
that referenced
this pull request
Jun 4, 2026
β¦ls (#15473) * β¨ feat(gateway): add explicit type discriminator to tunneled tool calls The device-gateway relays builtin local-system calls and tunneled stdio MCP calls over one `tool-call` channel. The device was meant to tell them apart by sniffing whether `toolCall.params` exists β fragile: any future builtin tool that grows a `params` field would be misrouted to the MCP client. Add an explicit `toolCall.type` discriminator (`'builtin' | 'mcp'`). The HTTP client stamps it: `executeToolCall` β `'builtin'`, `executeMcpCall` β `'mcp'`. The device routes on `type`, never on payload shape. Optional + back-compatible: an older server that omits it is treated as `'builtin'`. The desktop receiver switches to this discriminator in a follow-up. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * β¨ feat(desktop): execute tunneled stdio MCP calls from the gateway (#15470) Receiving half of the gateway stdio-MCP work. When the cloud server tunnels a stdio MCP tool call to this device (a `tool_call_request` carrying `mcpParams`), run it locally instead of falling through to the builtin local-system tool switch (which keys on apiName and has no MCP context, so it rejected these as "not available on this device"). - `gatewayConnectionSrv`: add a dedicated `mcpCallHandler` + `setMcpCallHandler`; `handleToolCallRequest` routes on the presence of `toolCall.mcpParams`, sharing the existing response-envelope path. - `GatewayConnectionCtr`: wire `setMcpCallHandler` β `executeMcpCall`, which maps the wire payload to `McpCtr.runStdioMcpTool`. - `McpCtr`: extract `runStdioMcpTool` core from the `callTool` IPC method so both the renderer and the gateway tunnel share one stdio execution path (no SuperJSON round-trip for the in-process caller). Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
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
1 participant
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.
π» Change Type
π Related Issue
Stacked on #15469 (server side). Base is
feat/gateway-stdio-mcp-server, notcanaryβ retarget tocanaryafter #15469 merges.π Description of Change
The receiving half of gateway stdio-MCP support. #15469 makes the cloud server tunnel a stdio MCP tool call to a connected device (a
tool_call_requestcarryingmcpParams); this PR makes the desktop run it.Previously the device's tool-call handler only knew the builtin local-system switch (keyed on
apiName), so any tunneled MCP call hit the "tool not available on this device, skip" fallback. Now:gatewayConnectionSrv: dedicatedmcpCallHandler+setMcpCallHandler.handleToolCallRequestroutes on the presence oftoolCall.mcpParams(otherwise unchanged), sharing the same response-envelope path.GatewayConnectionCtr: wiressetMcpCallHandlerβexecuteMcpCall, which maps the wire payload (command/args/env/name) toMcpCtr.runStdioMcpTool.McpCtr: extractsrunStdioMcpToolcore from thecallToolIPC method, so the renderer path and the gateway tunnel share one stdio execution path β no SuperJSON round-trip for the in-process caller.The desktop already had full stdio-MCP spawn capability (used by renderer chat); this just connects it to the gateway tunnel.
π§ͺ How to Test
Desktop type-check clean (no new errors in touched files).
GatewayConnectionCtr.test.tsextended to 59 tests: routing onmcpParams, success envelope, and error envelope. End-to-end: with the server PR deployed, configure a local stdio MCP, run a Task that calls it from a connected device β the call now spawns the MCP locally and returns results.π Additional Information
Follow-ups (not in this PR): CLI device (
lh connect) parity formcp_call, and optional tool-visibility gating (hide stdio MCP from the model when no device is online). Both are non-blocking β without them, an offline-device call degrades gracefully (server-side spawn error / graceful skip).π€ Generated with Claude Code