mcp-client: streamable-http transport is rejected with HTTP 403 by WAF-fronted MCP servers (version-negotiation probe)

[serg2k-rgb]

mcp-client: streamable-http transport is rejected with HTTP 403 by WAF-fronted MCP servers (version-negotiation probe)

Environment

• DSH 0.2.1-rc.5, desktop profile, Windows 11 (PowerShell 7)
• @deepseek-ai/dsh-mcp-client with bundled @modelcontextprotocol/client@2.2.0
• Remote server: Tavily MCP — https://mcp.tavily.com/mcp/?tavilyApiKey=…, serverInfo: tavily-mcp 4.1.4

Expected

A bundle entry with

- id: tavily-mcp
  name: '@deepseek-ai/dsh-mcp-client'
  config:
    serverName: tavily
    transport: streamable-http
    url: https://mcp.tavily.com/mcp/?tavilyApiKey=…
    failOnStartupError: true

connects, lists tools and registers them on ctx.tools.

Actual

tavily-mcp (@deepseek-ai/dsh-mcp-client): Error: mcp-client(tavily): initial connection or tool synchronization failed
SdkHttpError: Version negotiation failed: the server denied access (HTTP 403)

It is the client, not the server or the key

Same URL, same machine, same moment:

curl -s -o /dev/null -w "%{http_code}" -X POST "$URL" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  --data '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"1.0"}}}'
# 200, SSE body with a valid initialize result

• DSH streamable-http → 403 (HTML body from the WAF, not a JSON-RPC error).
• mcp-remote (MCP SDK 1.x proxy, stdio → http) with the identical URL → works: tools/list returns 5 tools, tavily_search returns results.
• DSH stdio + mcp-remote → works and has been stable for repeated calls.

So the failing part is the request(s) the v2 client issues around initialize — the version-negotiation probe — and the WAF rejects that shape.

Additional data points

• Accept header matters on this endpoint: Accept: application/json alone (without text/event-stream) returns 406.
• A burst of ~20 probe requests in a couple of minutes got the IP rate-limited: during that window everything returned an HTML 403 — including the plain REST API https://api.tavily.com/search. After ~5 minutes the block cleared and curl was 200 again, while the DSH client still returned 403. So the client-side failure is not explained by the temporary block.

Suggested fix

1. Treat a 4xx/5xx response to the negotiation probe as "negotiation unsupported" and fall back to a plain initialize with the spec-default protocol version, instead of failing the whole connection.
2. Or expose it as config: negotiateProtocolVersion: false.
3. Optionally allow extra headers on the probe (browser-like User-Agent / Accept-Language) — many WAF-fronted MCP endpoints appear to expect them.

Workaround for users

Use the stdio bridge, e.g.

transport: stdio
command: node
args:
  - <path>/node_modules/mcp-remote/dist/proxy.js
  - https://mcp.tavily.com/mcp/?tavilyApiKey=…

This is what I am running now; everything works, but it costs an extra process and is a separate failure point (the bridge has already dropped with SdkError: Connection closed on its own once).

[lubenkov]

The mcp-remote comparison is a useful workaround. For a fix, I’d avoid falling back on every 403: it can also mean genuinely denied access, and an automatic retry may hide that.
Could you capture the failing probe’s method, headers and response separately from the successful initialize request? That would help distinguish a WAF rule from an authentication failure. An explicit opt-in to skip negotiation seems safer than a blanket fallback.

[TasfiqSami]

Could this be related to how the client handles the initial handshake?

Since mcp-remote works against the same server, I'd be curious whether the SDK is sending something different during initialization. Maybe compare the actual HTTP requests from both clients, especially the headers and the first request sent to the endpoint.

Also, does the 403 response include any WAF headers or request ID? That might help narrow down whether the server is rejecting the request itself or something about the SDK's handshake.

Just a thought, but I think comparing those two requests would be a good starting point.

[serg2k-rgb]

Thanks both — I went and captured the probe instead of guessing. Two findings, and one of them corrects my original framing.

1. What the probe actually is

Reading dsh-mcp-client/lib/index.js (0.2.1-rc.5) shows the client is constructed with hardcoded options:

new Client({ name: "dsh-mcp-client", version: "0.0.1" }, {
  capabilities: {},
  versionNegotiation: { mode: "auto" },
  listChanged: { tools: { autoRefresh: false, debounceMs: 0 } }
});

So DSH opts into negotiation explicitly; the SDK default is legacy. With mode: "auto" and @modelcontextprotocol/client@2.2.0, the first request on the wire is:

POST https://mcp.tavily.com/mcp/?tavilyApiKey=…
accept: application/json, text/event-stream
content-type: application/json
mcp-method: server/discover
mcp-protocol-version: 2026-07-28

{"jsonrpc":"2.0","id":"server-discover-probe-1","method":"server/discover","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientInfo":{"name":"probe-v2-auto","version":"1.0.0"},
  "io.modelcontextprotocol/clientCapabilities":{}}}}

That is the request behind the Version negotiation failed … (HTTP 403) message.

2. The endpoint does not reject that request

I reproduced the exact setup in a standalone Node 24 process (same SDK 2.2.0, same versionNegotiation: { mode: "auto" }) against the same URL:

• probe -> 200 application/json, body {"result":{"supportedVersions":["2026-07-28"],...}} — the server is a modern-era server and negotiates cleanly;
• the client then switches to the modern wire (mcp-method / mcp-protocol-version headers on every request), tools/list -> 200, five tools returned.

Checked from the same host as well: POST with mcp-method: server/discover + mcp-protocol-version: 2026-07-28 returns 200, and UA variants (curl/…, node, Electron/40.2.0, empty) all return 200.

So the probe shape itself is fine, and "the WAF blocks the version-negotiation probe" (my original title) is wrong as a general claim. The 403 is specific to the request as issued from the DSH host process. That part I still cannot see from outside the app, and it is the only missing piece.

3. On the 403 body — one real capture

Earlier, while the IP was rate-limited, the same endpoint answered with a bare ALB page and no WAF request id:

403 text/html; no x-amzn-requestid; no Server header exposed
<html><head><title>403 Forbidden</title></head><body><center><h1>403 Forbidden</h1></center></body></html>

That one was a temporary rate-based block (cleared after ~5 minutes, curl returned 200 again). It is not the same failure as the persistent host-side 403, which reproduces while curl succeeds in the same second — worth keeping the two distinct.

4. Agreed on not falling back on 403

For a fix, I'd avoid falling back on every 403: it can also mean genuinely denied access, and an automatic retry may hide that.

Agreed, and the SDK already refuses to treat 403 as retryable for that reason.

The minimal fix looks smaller than a fallback: pass versionNegotiation through as plugin config. dsh-mcp-client hardcodes { mode: "auto" }; the SDK supports legacy (its default), auto, and { pin }, and the reconnect path already rebuilds the client per attempt. A config shape like

config:
  serverName: tavily
  transport: streamable-http
  url: …
  versionNegotiation: legacy   # or auto | "2026-07-28"

gives an explicit, documented opt-out where the modern handshake misbehaves, without turning a 403 into "retry differently". Happy to test whichever build exposes it.

Would a host-side capture help you more than this? If you tell me what to instrument — or expose a debug flag on dsh-mcp-client that logs the probe's status, headers and body — I will reproduce and paste the request context as seen from inside the app.

[lubenkov]

Agreed, the probe isn't the problem, the two 403s stay separate, and versionNegotiation as plugin config beats any fallback. Default it to legacy (the SDK's own default) so the modern handshake is an explicit opt-in, and log the effective mode + negotiated version once at connect - this failure was expensive to diagnose mainly because the mode was invisible.
On the capture: you don't need to wait for a debug flag. You've already shown the identical request succeeds from standalone Node and fails from the host in the same second - that points at the host's HTTP stack, not the SDK's request construction. First thing to check is which fetch dsh-mcp-client passes to the SDK. If it's Electron's net-backed fetch rather than undici, the probe goes out through Chromium's stack: different header order/casing, sec-fetch hints, possibly an origin: null on a POST - any of which a WAF can 403 on, and a Node repro can't show it.
Minimal trace worth having, if you instrument: negotiation mode + SDK version, headers as actually serialised on the wire, transport (h1/h2, proxy, TLS interception), response status/headers + first 1 KB, correlated per attempt. And try legacy locally - if it connects, that confirms server/discover as the specific failing request.