IHttpContextAccessor stopped working since 0.1.0-preview.10

[xiaomi7732]

Describe the bug
Refer to #185, there's an example fetching request info from IHttpContextAccessor.

It worked in 0.1.0-preview.9 but not working in preview 10 and 11.

To Reproduce
Steps to reproduce the behavior:

1. Add service:

   builder.Services.AddHttpContextAccessor();

2. Inject and use:

   [McpServerToolType]
   public class EchoTool(IHttpContextAccessor contextAccessor)
   {
       private readonly IHttpContextAccessor _contextAccessor = contextAccessor ?? throw new ArgumentNullException(nameof(contextAccessor));
   
       [McpServerTool, Description("Echoes the message back to the client.")]
       public string Echo(string message)
       {
           return $"hello {message}, {_contextAccessor.HttpContext?.Request.Path ?? "(no HttpContext)"}";
       }
   }

Expected behavior
The _contextAccessor.HttpContext is not null, and provides current httpContext.

It is in preview 10 and preview 11. (Same code works in preview.9).

Logs
Having IHttpAccessor allows checking authorization header until the official authorization middleware is in place.
Looking forward to #349 .

Additional context

[halter73]

IHttpContextAccessor still works if you connect to the "/sse" endpoint. We have a test verifying this continues to work here:

csharp-sdk/tests/ModelContextProtocol.AspNetCore.Tests/MapMcpSseTests.cs

Lines 39 to 66 in e913d80

	Builder.Services.AddMcpServer().WithHttpTransport().WithTools<EchoHttpContextUserTools>();
	Builder.Services.AddHttpContextAccessor();
	await using var app = Builder.Build();
	app.Use(next =>
	{
	return async context =>
	{
	context.User = CreateUser("TestUser");
	await next(context);
	};
	});
	app.MapMcp();
	await app.StartAsync(TestContext.Current.CancellationToken);
	var mcpClient = await ConnectAsync();
	var response = await mcpClient.CallToolAsync(
	"EchoWithUserName",
	new Dictionary<string, object?>() { ["message"] = "Hello world!" },
	cancellationToken: TestContext.Current.CancellationToken);
	var content = Assert.Single(response.Content);
	Assert.Equal("TestUser: Hello world!", content.Text);

csharp-sdk/tests/ModelContextProtocol.AspNetCore.Tests/MapMcpTests.cs

Lines 98 to 108 in e913d80

	[McpServerToolType]
	protected class EchoHttpContextUserTools(IHttpContextAccessor contextAccessor)
	{
	[McpServerTool, Description("Echoes the input back to the client with their user name.")]
	public string EchoWithUserName(string message)
	{
	var httpContext = contextAccessor.HttpContext ?? throw new Exception("HttpContext unavailable!");
	var userName = httpContext.User.Identity?.Name ?? "anonymous";
	return $"{userName}: {message}";
	}
	}

However, what I think you noticed was the change in behavior to change the default endpoint to use the new #330 Streamable HTTP transport. Unlike with SSE, there is no single HTTP request that last the duration of an MCP session that we can give you via the IHttpContextAccessor 😢

However, fear not! HttpServerTransportOptions.RunSessionHandler allows you to read whatever information you desire from the initialize request's HttpContext, and then store that in your own async local for future use.

var builder = WebApplication.CreateBuidler();

builder.Services.AddMcpServer()
    .WithToolsFromAssembly()
    .WithHttpTransport(options =>
    {
        options.RunSessionHandler = async (httpContext, mcpServer, cancellationToken) =>
        {
            MyAsyncLocalTool.MyHeaderValue.Value = httpContext.Request.Headers["my-header"];
            await mcpServer.RunAsync(cancellationToken);
        };
    });

var app = builder.Build();

app.MapMcp();

app.Run();

[McpServerToolType]
public static class MyAsyncLocalTool
{
    public static AsyncLocal<string?> MyHeaderValue { get; } = new();

    [McpServerTool(Name = "read-my-header")]
    public static string? ReadMyHeaderValue() => MyHeaderValue.Value;
}

[grippstick]

Should all of the tools we create be static? This solution feels really not thread safe.

If we do not have access to the HttpContext is there some other context that can be passed around?

If I am missing something and AsyncLocal<string?> takes care of the problem, please let me know and I will start researching.

[halter73]

The tools themselves don't need to be static. I just did that in the sample for convenience. The AsyncLocal could live outside of the [McpServerToolType] class.

I do understand the hesitation against using AsyncLocals since the flow of the execution context can be hard to reason about particularly when it goes through library code you don't fully control before calling back into your code, but I don't think there are any thread safety issues caused by the usage of AsyncLocal.

For right now, I do think the using an AsyncLocal does solve your problem even if it's not the most elegant solution. If you aren't already very familiar with AsyncLocals or the execution context, I recommend looking at @stephentoub's excellent blogpost on How async/await Really Works in C# and paying particular attention to the "ExecutionContext" section.

There is currently a thread safety issue where the HttpContext passed to RunSessionHandler for stateful Streamable Http sessions is disposed before the handler completes. I'm looking at reworking the API to avoid that, but this is unrelated to AsyncLocals. Just trying to access the HttpContext directly in the RunSessionHandler after IMcpServer.RunAsync completes is enough to reproduce this issue, so I'm still looking to rework this API. As part of that, I might add some sort of items bag (e.g. Dictionary<string, object?>) to IMcpServer or somewhere else to allow you to flow state from the HttpContext of the initialization request to later tool calls without using an AsyncLocal or the execution context.

And while we haven't shipped this feature yet, if you want the HttpContext for a given Streamable HTTP tool call POST request, you will soon be able to configure HttpServerTransportOptions.Stateless = true once #392 is merged and shipped which will not only make IHttpContextAccessor work again, but it will now give you the HttpContext for the HTTP tool call POST request instead of always giving you the same "/sse" GET request the way the older HTTP + SSE transport does. This will disable some advanced features like client sampling which aren't supported in stateless which is why it won't be enabled by default. But if your tools are like the majority of tools don't need to do client sampling, query client roots, or otherwise send server-to-client requests, stateless could be a good option that will be easier to scale horizontally.

[grippstick]

Completely understood and I think you are taking a good direction. I saw the context being used to separate reader and write streams with HttpDuplexPipe, but couldn't figure out why HttpContext was null. Adding logging everywhere it still looks like the request is alive on the initial call of the tool.

[grippstick]

I am not sure if I should put this here or start a new ticket.

I am building a http based Server. Where should I put authentication? I would normally check add an attribute to my endpoint or put a check inside of the tool method, but as we have discussed, I do not have access to the IHTTPContextAccessor. Should I go the AsyncLocal route and store the user in there?

Put it directly in the RunSessionHandler?

    var mcpBuilder = builder.Services
        .AddMcpServer()
        .WithHttpTransport(options =>
        {
            options.RunSessionHandler = async (httpContext, mcpServer, cancellationToken) =>
            {
                //authentication here?

                await mcpServer.RunAsync(cancellationToken);
            };
        })

@halter73 is there a way to get the service provider in setting up WithHttpTransport with HttpServerTransportOptions? Trying to see if I can get the HttpContext and send it to a service that holds the AsyncLocal object to hold the headers for the current call.

[halter73]

I am building a http based Server. Where should I put authentication?

I'd recommend using MapMcp().RequireAuthorization() and using standard ASP.NET Core auth handlers like the JwtBearerHandler for now and treat it like any other Web API if you control the client and are able to acquire a valid JWT access token. Cookies could also work if you control the client and can do the sign in flow to set the authentication cookie.

If you don't control the client, you should take advantage of the latest MCP auth specification based on OAuth that let arbitrary clients discover the right Identity Provider and scopes and acquire the right access token automatically. For that, I recommend looking at the PR we currently have up to add support for this. #377

It's still very early, and the auth spec is still in draft and being regularly updated. And there is no standard for things like incremental consent for per-tool authorization or anything like that. You currently authenticate the entire session up front.

is there a way to get the service provider in setting up WithHttpTransport with HttpServerTransportOptions?

There're a few ways. The easiest would be probably to wait until your handler is called and use HttpCotnext.RequestServices, but if you need the service provider while initially configuring the HttpServerTransportOptions normally configured in the WithHttpTransport callback, you can use the Options pattern. I provide an example below, but there are many other approaches including implementing IConfigureOptions<HttpServerTransportOptions> and constructor injecting any services you need.

builder.Services.AddOptions<HttpServerTransportOptions>()
    .Configure<MyService>((options, myService) =>
    {
        // Not that this is what you'd actually do, but this shows using services to configure options.
        options.IdleTimeout = myService.IdleTimeout;
    });

I question the need to combine AsyncLocals with a stateful service though. That is a pathway to madness since it'd be very easy to introduce race conditions or reference stale state. If you're going to use an AsyncLocal, just use it directly on a static variable or via a very simple service type with absolutely no state other than the static AsyncLocal. You'll notice that even HttpContextAccessor is just a thin wrapper around a single static field.

I talked to @stephentoub about a way of making IHttpContextAcessor work with all Streamable HTTP requests, not just stateless ones, by manually capturing and flowing the ExecutionContext through the transport, and he's on board, so hopefully all of this will be easier soon.

@halter73 I got the following working to consume the httpContext. It is only invoked on the initial call to establish the connection. The calls to execute the tools do not refresh the httpContext. I assume that is expected with Streamable HTTP requests?

    builder.Services.AddMcpServer().WithToolsFromAssembly().WithHttpTransport(options =>
    {
        options.RunSessionHandler = async (httpContext, mcpServer, cancellationToken) =>
        {
            var myService = mcpServer.Services.GetRequiredService<IMyService>();
            myService.DoSomething(httpContext);
    
            await mcpServer.RunAsync(cancellationToken).ConfigureAwait(false);
        };
    });

[halter73]

It is only invoked on the initial call to establish the connection. The calls to execute the tools do not refresh the httpContext. I assume that is expected with Streamable HTTP requests?

Exactly. If you enable the stateless mode that's still in PR (#392) RunSessionHandler will run per request/tool invocation, but what you're seeing is the expected default behavior for Streamable HTTP.

[kaniosm]

To this context, I'm trying to figure out how to determine the MCP session from within the tool, and limit access to tools for different users.
From what I understand "MapMcp().RequireAuthorization()" will make all MCP endpoint require authentication. But what if I want specific users to list and call only specific tools? Maybe through list and tool handlers, but this will require reimplementing tool parsing and calling.
As for the session, I understand that this is stored in "StreamableHttpHandler", which is also in the dependency container. Can this class be unsealed and therefore injected in the scope of the tool call to help get the mcp session id?

Sorry guys, we are all new to this, therefore we have lot's of questions!

[halter73]

As for the session, I understand that this is stored in "StreamableHttpHandler", which is also in the dependency container. Can this class be unsealed and therefore injected in the scope of the tool call to help get the mcp session id?

@kaniosm Can you give us an example of what code you would write if StreamableHttpHandler was unsealed? I'm not exactly sure how that would make it any easier to list specific tools for specific users.

If I were trying to do that today, I would probably configure McpServerOptions.Capabilities.Tools.ToolCollection in HttpServerTransportOptions.ConfigureSessionOptions using McpServerTool.Create. You have access to both HttpContext.User and a per-session instance of McpServerOptions in your ConfigureSessionOptions callback, so you should have all you need to create a custom listing of tools per user per session.

Maybe through list and tool handlers, but this will require reimplementing tool parsing and calling.

You don't have to implement the list and tool handlers yourself to configure a custom collection of tools per-user and/or per-session. You can customize the ToolCollection at the beginning of the session in ConfigureSessionOptions as I mentioned above.

However, if you did want to implement the list and tool handlers yourself, you still would not need to reimplement any tool parsing or calling, you can use McpServerTool.Create and McpServerTool.ProtocolTool to do most of the heavy lifting of generating schemas and parsing JSON for you even in these low-level handlers.

If you're interested in a video that demonstrates some of these low-level details of the library, I recommend watching this ASP.NET Core community standup we broadcast a couple weeks ago. In it you'll see I go even lower level and implement the Streamable HTTP MCP transport using plain minimal APIs and the JSON DTOs from this SDK. I linked directly to the timestamp where I demonstrate using McpServerTool.Create and McpServerTool.ProtocolTool to help handle the "tools/list" and "tools/call" JSON-RPC requests, but you can use the exact same APIs to help you implement WithListToolsHandler and WithCallToolHandler, it will just be even easier.

YouTube - ASP.NET Community Standup - Building MCP Servers with ASP.NET Core @ 46:22

[kaniosm]

Many thanks for the update @halter73.
Yes, I've seen the configure examples... Capabilities.Tools is the way I'm implementing my use case today...
Initially I thought I could intercept the list from the list handler, and filter out the tools parsed by .WithTools extension, but then realized that the tools already registered in the container are returned in all cases and I was ending up with duplicates.

The video helped a lot understanding the library.
Thanks again!