fix: allow custom Content-Type header in StreamableHTTPTransport

[guoyangzhen]

Fixes #2375

Problem

StreamableHTTPTransport._prepare_headers() hardcodes Content-Type: application/json, which overwrites any user-configured header (e.g. application/json; charset=utf-8). Users who pass custom headers via httpx.AsyncClient(headers=...) find them ignored because request-level headers take precedence over client defaults in httpx.

Solution

Add an optional headers parameter to both StreamableHTTPTransport.__init__ and streamable_http_client. User-supplied headers are merged after the MCP defaults, so they take precedence. This is backward-compatible — existing code with no headers argument behaves identically.

Usage

async with streamable_http_client(
    url,
    headers={'Content-Type': 'application/json; charset=utf-8'},
) as (read, write):
    ...

Changes

• StreamableHTTPTransport.__init__: new headers dict param, stored as self._user_headers
• _prepare_headers(): calls headers.update(self._user_headers) after setting defaults
• streamable_http_client(): new headers kwarg, forwarded to transport

[km-anthropic]

@claude review

[dsabana-clgx]

There is a bigger issue of not allowing any custom headers/values at all. Maybe we need to enable forwarding custom headers. This will cover your use case as well.

[maxisbey]

The linked #2375 was closed as not planned — application/json is UTF-8 by default per the JSON RFC, so a Content-Type override isn't something the client transport takes on; other headers already pass through a caller-supplied http_client. Closing this as part of a wider backlog cleanup following the v2 launch. Feel free to reopen if this is still relevant.

_{AI Disclaimer}