Follow Discord
Sweep 06 Nov 2026 · 01:32Z Build v2.1.319 537 read Stable v2.1.311 Latest v2.1.318 Next v2.1.319 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.267 ·

MCP tools can now be 'adopted' as passthrough tools instead of routed through the device bridge

Remote worker sessions can now adopt a machine's MCP tools directly under policy, tracked via new passthrough_adopted/declined telemetry

Group of 3 Nothing to try yet No documentation found In Development
JSON All of v2.1.267
Nothing to try yetTier: how much it should matter to you
3Useful: my rating, 1 to 5
3Signal: worth watching, 1 to 5
MCPArea: what it touches
In DevelopmentKind: in v2.1.267,
In DevelopmentSection of the release

What

  • A reworked remote-tools setup pipeline, gated by adoptMcpOverChannelSwitchOn, computes a machineMcpToolsPolicy (allowed/denied/pending/unavailable) for each MCP server and decides whether its tools are "adopted" as passthrough tools, used directly by a remote worker, instead of being routed through the device bridge. Adoption requires remote tool forwarding to be enabled, the channel switch to be on, policy to allow it, and the tool not to be disabled.
  • The remote-tools announce handler now computes passthrough_adopted and passthrough_declined (with reasons policy, pending, or unavailable) outcomes and reports them in telemetry.
  • The remote_tools_announce acknowledgement schema was extended with passthrough_adopted (count of MCP tools kept) and passthrough_declined fields, and ignored_tools now documents more reasons, including tools beyond the cap that the worker keeps.

Why Routing every MCP tool call through the device bridge adds overhead; letting a remote worker adopt and call MCP tools directly, when policy allows, should make those calls faster while keeping visibility into which tools were adopted versus declined and why.

Read from
Names in the bundleadoptMcpOverChannelSwitchOn

See this entry in the whole of v2.1.267 →

Feedback