[TypeScript] MCPToolProvider sse transport passes headers option that SSEClientTransport ignores

[cornelcroi]

Problem

mcpToolProvider.ts constructs the SSE transport as:

transport = new SSEClientTransport(new URL(serverConfig.url), {
  headers: serverConfig.headers ?? {},
});

But the SDK's SSEClientTransportOptions has no top-level headers key — it takes authProvider / eventSourceInit / requestInit. So custom headers configured on a TS sse server (e.g. Authorization) are most likely silently dropped. The Python side passes headers correctly (sse_client(url, headers=...)), so this is a TS-only parity bug.

Found during review of #632, where the new streamable-http branch does it correctly via requestInit.

Proposal

Pass headers through both requestInit.headers (POST requests) and eventSourceInit (the SSE GET stream needs a custom fetch/EventSource init to carry headers — check the SDK version's exact mechanism), with a test asserting the constructed options shape.

Behavioral note for the changelog: users' headers on TS SSE configs will start being sent — that is the documented intent, but it is a change in effective behavior.

[koi-lee]

This appears to be resolved by #642 on current main.

I verified the published @modelcontextprotocol/client@2.0.0 package, not only the type declaration. SSEClientTransport._commonHeaders() normalizes requestInit.headers; _startOrAuth() uses those common headers for the initial GET event stream, and _send() uses the same headers for recurring POST requests. Therefore the current provider shape:

{ requestInit: { headers: serverConfig.headers } }

already carries configured headers on both channels. mcpToolProviderV2.test.ts also protects the transport options shape added in #642.

Unless a different SDK version or behavior is intended, #640 can be closed as completed by #642.