startVersionBridge
startVersionBridge({ newServerUrl })
Starts an HTTP proxy that answers the old initialize handshake locally and forwards everything else, correctly shaped for the new server.
The 2026-07-28 MCP spec removed the initialize/initialized handshake entirely. A client written against it cannot talk to a pre-2026-07-28 server, and an old client cannot talk to a new server at all -- because the new server never implements initialize.
mcp-versionbridge answers one question: can an old MCP client reach a 2026-07-28 server without either side changing?
The bridge answers initialize LOCALLY -- never forwarded, since the new server doesn't implement that method -- then injects MCP-Protocol-Version and _meta.clientInfo on every forwarded call, merged with (not overwriting) any existing _meta.
import { startVersionBridge } from "mcp-versionbridge";
const bridge = await startVersionBridge({
newServerUrl: "https://my-2026-07-28-server.example.com/mcp",
});
// Point your old MCP client at bridge.url instead of the real server.
console.log(bridge.url);
await bridge.stop();
startVersionBridge({ newServerUrl })
Starts an HTTP proxy that answers the old initialize handshake locally and forwards everything else, correctly shaped for the new server.
bridge.url
Point your old-style MCP client here instead of the real server -- no client changes needed.
bridge.stop()
Shuts the proxy down cleanly.
As the MCP ecosystem migrates unevenly across spec versions, this is a real, immediate interoperability wall -- not a hypothetical one. A few projects patched this inside their own codebases as one-off fixes; there wasn't an independent, reusable bridge.
old client → initialize
bridge answers locally
old client → tools/call
bridge → injects MCP-Protocol-Version + _meta.clientInfo
new server → sees a native 2026-07-28 request