Skip to content
mcp-versionbridge

Old handshake in, new protocol out.

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?

$ npm install mcp-versionbridge

One proxy, zero client or server changes

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.

src/bridge.ts
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();

One function does the bridging

01

startVersionBridge

startVersionBridge({ newServerUrl })

Starts an HTTP proxy that answers the old initialize handshake locally and forwards everything else, correctly shaped for the new server.

02

bridge.url

bridge.url

Point your old-style MCP client here instead of the real server -- no client changes needed.

03

bridge.stop

bridge.stop()

Shuts the proxy down cleanly.

Why this exists

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

What mcp-versionbridge doesn't do

  • v1 is one direction only.
    Old-client-to-new-server. The reverse is a real, distinct need, tracked as v1.1.
  • HTTP transport only.
    stdio transport is out of scope for v1.
  • No server/discover-based negotiation.
    That RPC's schema isn't public yet -- capabilities pass through as declared.

Stop maintaining two MCP client codepaths

Free and open source under the MIT license.

$ npm install mcp-versionbridge