In the StreamableHttp mode MCP server, Scoped type dependencies are not properly injected into classes marked with [McpServerToolType].

[wesley-wws]

Describe the bug

I'm trying to access RouteValues from HttpContext by adding a Middleware that stores them in an Argument class, registered as Scoped in the DI container. However, when invoking the MCP tool method, I can't retrieve the correct Argument instance in the TestTools class. The logs indicate that the Argument instance differs between the Middleware and the TestTools.

// Program.cs
var builder = WebApplication.CreateBuilder(args);
// Add McpServer services
builder.Services.AddMcpServer()
    .WithHttpTransport()
    .WithToolsFromAssembly();

builder.Services.AddScoped<Arguements>();

var app = builder.Build();
app.UseRouting();

app.Use((context, next) =>
{
    // The Middleware to capture route values and set them in Arguements
    var arguements = context.RequestServices.GetRequiredService<Arguements>();
    arguements.SetRouteValue(context.Request.RouteValues["value"]?.ToString());
    return next();
});

app.Map("/", (Arguements arguements) => arguements.Guid.ToString());
app.MapMcp("mcp/{value}");
app.Run();


[McpServerToolType]
public class TestTools
{
    private readonly Arguements arguements;

    public TestTools(Arguements arguements, ILogger<TestTools> logger)
    {
        this.arguements = arguements;
        logger.LogInformation($"TestTools created.");
    }

    [McpServerTool]
    [Description("Test")]
    public Task<string> TestAsync(CancellationToken cancellationToken = default)
    {
        return Task.FromResult($"RouteValue: {arguements.RouteValue}");
    }
}


public class Arguements
{
    private readonly ILogger<Arguements> _logger;

    public Guid Guid { get; private set; }

    public string? RouteValue { get; private set; }

    public Arguements(ILogger<Arguements> logger)
    {
        this._logger = logger;
        Guid = Guid.NewGuid();
        logger.LogInformation($"Arguements created ID: {Guid}");
    }

    public void SetRouteValue(string? value)
    {
        RouteValue = value;
        _logger.LogInformation($"RouteValue set to: {RouteValue}");
    }
}

To Reproduce
Steps to reproduce the behavior:

1. Start the ASP.NET Core project
2. Use the MCP debug tool - MCP Inspector, connect to http://localhost:xxxx/mcp/abc and call the Test tool
3. The return value is RouteValue:

Expected behavior
The return value should be RouteValue: abc

Logs

info: CS.API.Arguements[0]
      Arguements created ID: f7616e71-1756-43c1-aed6-5f085f817e99
info: CS.API.Arguements[0]
      RouteValue set to: abc
info: ModelContextProtocol.Server.McpServer[570385771]
      Server (CS.API 1.0.0.0), Client (mcp-inspector 0.14.3) method 'tools/call' request handler called.
info: CS.API.Arguements[0]
      Arguements created ID: 6c51f94c-51e0-4ad9-ad44-cdbe722b1e64
info: CS.API.TestTools[0]
      TestTools created.
info: ModelContextProtocol.Server.McpServer[1867955179]
      Server (CS.API 1.0.0.0), Client (mcp-inspector 0.14.3) method 'tools/call' request handler completed.

Additional context

The log details show that the Arguments are created and RouteValues are correctly assigned in the Middleware. However, when resolving TestTools, a new Argument instance is created. It seems TestTool is resolved in a different scope from the HTTP request pipeline, which is confusing.

[eiriktsarpalis]

cc @halter73

[halter73]

Currently, both the SSE and Streamable HTTP transports create the McpServer using the default of McpServerOptions.ScopeRequests value of true, because there is a single McpServer instance for multiple requests, and we haven't yet introduced an API to specify an IServiceProvider scope per RPC message at the transport level. This means by default, each tool invocation gets its own unique scope independent of the request scope. These scopes only live for the duration of the tool call, so it's still generally safe to use services like scoped EF DbContexts, but the tool invocation scope will not share any state with the request scope.

However, if you set HttpServerTransportOptions.Stateless to true, we create an McpServer per RPC message using HttpContext.RequestServices and set McpServerOptions.ScopeRequests to false so you can resolve services from the request scope in your tools.

Stateless mode does disable some lesser-used features like sampling, but I think it works well for most MCP servers. Does this seem like an option for you?
#365 (comment) goes into more detail about how some of this works.

[wesley-wws]

@halter73 Thank you for your support. I tried using stateless mode, but the Argument instances are still different between the Middleware and ToolClass. However, I can now consider using IHttpContextAccessor as an alternative to get Route information.

[halllo]

#590 describes the same problem.

It seems to be a duplicate of #365

IHttpContextAccessor not providing access to the current HttpContext is an indicator that is running outside the request scope.

I will stay with SSE transport until that is resolved.

[halllo]

It works for me with @halter73 suggestion to go stateless:

builder.Services.AddMcpServer()
	.WithHttpTransport(o =>
	{
		o.Stateless = true;
	})
	.WithToolsFromAssembly();

[nkarg90]

Indeed, #590 refers to the same underlying issue. Our goal is to preserve access to services and user context tied to the original request scope without switching to stateless mode—since going stateless disables session-related features (root and sampling) & SSE.

[houlongchao]

+1. We encountered the same problem. We need to inject the same Scoped data in the McpTool through the constructor as we do in the Middleware, and use the Scoped data to record some information about the current request.