SseClientTransport AdditionalHeaders not work

[gamma-chen-avepoint]

Describe the bug
By checking code, look like when use the sse Transport, the header should pass like this

TransportOptions = new Dictionary<string, string>
{
    ["header.ACCESS_TOKEN"] = ""
}

then the header key and value pass to a property named AdditionalHeaders. But this property not be used when send request.

[essenbee2]

I was just about to add the same issue! I am trying to pass an API Key to an ASP.NET Core SSE server, but the additional headers do not show up on the server when I examine the HTTP headers in my middleware.

[stephentoub]

cc: @halter73

[fxvarga]

I am facing the same issue with this looks like the SseClientSessionTransport is making the call but only sends in text/event-stream mediatype header. I'm assuming this is where we can map the additional options?

csharp-sdk/src/ModelContextProtocol/Protocol/Transport/SseClientSessionTransport.cs

Line 197 in 3b26bf8

request.Headers.Accept.Add(new MediaTypeWithQualityHeaderValue("text/event-stream"));

[halter73]

It looks like nothing is currently reading SseClientTransportOptions.AdditionalHeaders. I'll fix that. In the meantime, you should be able to work around this using this SseClientTransport constructor that takes a custom HttpClient you can configure DefaultRequestHeaders on.

[taimurlak]

Btw guys, anyone know how can we read the header in mcp server Tool:

let's suppose this is the code of my tool, how can i read the token and validate, or what is the way to authenticate the user in SSE.

[halter73]

@taimurlak This is something I'm actively looking into. As of a few minutes ago (see #225), I added a Func<HttpContext, McpServerOptions, CancellationToken, Task>? configureOptionsAsync = null parameter to MapMcp. This gives you the HttpContext from the initial request to the /sse endpoint, and you can read headers there to configure tools if you need to.

This is far from a complete solution though. It doesn't give you the headers from the JSON-RPC request to invoke the tool (although this often doesn't matter), and it isn't easy to get at from a [McpServerToolType], so this is definitely an area we're looking to improve on.

It'd be nice if HttpContextAccessor worked, but that doesn't play super well with reading from a Channel.

[taimurlak]

@halter73 Thanks you so much for quick response. can you please show me the example code so i can understand it well.

[halter73]

I just confirmed that with the latest preview7 package, IHttpContextAccessor works. The ExecutionContext flows from the /sse request to the call to McpServer.RunAsync into the McpSession.ProcessMessagesAsync loop that ultimately calls the tool. This is despite the fact that the incoming JSON-RPC messages are coming in on a separate messages endpoint.

using ModelContextProtocol.Server;
using System.ComponentModel;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddHttpContextAccessor();
builder.Services
    .AddMcpServer()
    .WithToolsFromAssembly();

var app = builder.Build();

app.MapMcp();

app.Run("http://localhost:3001");

[McpServerToolType]
public class EchoTool(IHttpContextAccessor contextAccessor)
{
    [McpServerTool, Description("Echoes the message back to the client.")]
    public string Echo(string message)
        => $"hello {message}, {contextAccessor.HttpContext?.Request.Path ?? "(no HttpContext)"}";
}

⚠️ WARNING ⚠️

Be careful how you use this. MapMcp() is not in a state where you should be accepting untrusted connections. For example, it will not verify that the incoming /message requests come from the same HttpContext.User as the initial /sse request the IHttpContextAccessor gives you access to.

[taimurlak]

@halter73 Thanks alot dude 🙌