{"version":"2.1.239","anchor":"mcp-servers-supplied-by-a-remote-bridge-wired-up-entirely-st","canonical_anchor":"mcp-servers-supplied-by-a-remote-bridge-wired-up-entirely-st","heading":"MCP servers supplied by a remote bridge: wired up, entirely stubbed","tier":"soon","area":"MCP","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.239\/e\/mcp-servers-supplied-by-a-remote-bridge-wired-up-entirely-st","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.239","markdown":"### MCP servers supplied by a remote bridge: wired up, entirely stubbed\n\nA remote bridge could hand your session MCP servers during handshake, but it is entirely stubbed.\n\n**What**\n\nCode exists for a remote bridge session to install MCP servers handed over by the server during its opening handshake, and to swap them later over the control channel. Every part of it is inert in this build, so no bridge session gains servers this way.\n\n**Details**\n\n- The enabling check is a local `return !1`; the module holding the function that derives the servers from the handshake payload is declared as null; the apply step returns an empty added\/removed pair; the release and refresh hooks have empty bodies.\n- The bridge passes no handler for setting servers, so an `mcp_set_servers` control request over the bridge is answered with an explicit unsupported error.\n- Telemetry slots for the failure modes (\"handshake_threw\", \"payload_rejected\", \"relinquish_threw\", \"refresh_threw\") are already present under a single event name.\n- There is no flag or setting that turns any of this on; it is disabled at build time.\n\n**Evidence**\n\n`mcp_set_servers is not supported in this context (onMcpSetServers callback not registered)`\n\n- Area: MCP\n- Tier: Nothing to try yet\n- Useful: 1\/5\n- Signal: 4\/5\n- Present in the build but not switched on"}