Motivation and Context

The current streamablehttp_client doesn't support customizing the new client except header and timeout. I need to customize the httpx client because my MCP server integration requires mTLS connection, thus I need to setup certification during connection.

This allow to pass a http client or default to the existing factory.

I was able to "successfully" test my MCP integration by "monkey patching" the introduced mcp.shared._httpx_utils.create_mcp_client = my_custom_client_factory.

Also, this supports base_url support by httpx, which is minor, but for my case, URLs are injected as they vary on deployment.

How Has This Been Tested?

I tested my branch integrating with the deployed MCP, and it worked the same way with the monkey patch version, except that this became explicit.

Breaking Changes

This doesn't introduce any breaking change.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

This approach is similar to how other SDK configuration works, allow users to change the http client based on infrastructure requirements.

Why not kwargs? It felt that passing the client instance is more flexible than picking or passing the init constructors.

This couples with httpx.AsyncClient. Yes, in comparison to the current implementation that hides this detail. But, I didn't consider the scope of this PR, introducing a "wrapper" for the async client.

Update: I discovered a recent PR #734 after the PR opened. I didn't notice because I started to work prior it.