Feature: Client option to add http headers

[wagnerjt]

Is your feature request related to a problem? Please describe.

I do not believe we can hook into the underlying JSONRPCRequest and in the http.Client to add additional http headers being sent to the MCP server without relying on the Transport and implementing a RoundTripper.

Additional context

I am looking how we can send auth and other headers with this client. From the design doc, I see there are middleware options, but I believe the params are for the body of the request.

[chriscasola]

I would also benefit from some ability to modify all outgoing HTTP requests without providing a custom transport. The documentation for http.RoundTripper states that RoundTrip should not modify the request, so I'm not sure that is the best place to inject additional headers into the outgoing request.

Could the API look something like this?

options := &mcp.StreamableClientTransportOptions{
    Middleware: func(req *http.Request) (
        req.Header.Set("custom-header", "value")
    },
}
transport := mcp.NewStreamableClientTransport("http://", options)

[jba]

The documentation for http.RoundTripper states that RoundTrip should not modify the request, so I'm not sure that is the best place to inject additional headers into the outgoing request.

Clone the request. For example, https://cs.opensource.google/go/x/oauth2/+/refs/tags/v0.30.0:transport.go;l=50.

[chriscasola]

It's unfortunate to have to deep copy the request, and go through the overhead of creating a custom transport, and client, just to set some headers.

Other SDKs frequently provide functionality for setting headers. For example the openai SDK.

[jba]

In this case you can modify the request directly. It will always be a fresh http.Request.

[wagnerjt]

Thanks again for the guidance and context. Since it technically is resolved, will anything like @chriscasola be supported? I could imagine it is probably a much lower priority since the rest of the implementation is being worked on.

I would be happy to add additional FAQ or How-to in the design dir for questions like this if this is not the case. What do you think @jba

[jba]

When we have settled on a path forward for auth, we can revisit. If that's the only significant use case, we won't need a special feature.