Uh oh!
There was an error while loading. Please reload this page.
Per RouteValue Tools Sample - #724
Conversation
Co-authored-by: PederHP <127606677+PederHP@users.noreply.github.com>
Co-authored-by: PederHP <127606677+PederHP@users.noreply.github.com>
Co-authored-by: PederHP <127606677+PederHP@users.noreply.github.com>
…b-c4b4779d276e Add ASP.NET Core MCP server sample showcasing per-user tool filtering
Uh oh!
There was an error while loading. Please reload this page.
…s with route-based filtering Co-authored-by: PederHP <127606677+PederHP@users.noreply.github.com>
Co-authored-by: PederHP <127606677+PederHP@users.noreply.github.com>
…a-1d92ba914d7b Rename AspNetCoreMcpServerPerUserTools to AspNetCoreMcpPerSessionTools with route-based filtering
PederHP
commented
Aug 22, 2025
I've updated the sample as per @halter73 's suggestion to use route as the criteria instead of a header - to avoid any confusion with the mechanisms provided by the upcoming authorization convenience. The sample should show how to use arbitrary criteria to modify the Tools collection in the ConfigureSessionOptions delegate. |
halter73
left a comment
There was a problem hiding this comment.
Alternatively, we could filter out the tools, but starting from an empty list does seem simpler. If we wanted to improve this further, we could have a ConcurrentDictionary<string, McpServerTool[]> to look up the tool types more efficiently so we don't have to do a bunch of reflection at the start of each session.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Stephen Halter <halter73@gmail.com>
PederHP
commented
Aug 26, 2025
Applied your suggested changes to start from an empty list without clearing, but hadn't noticed that this means the capability isn't initialized when configuring the session options. To make the sample reasonably simply, I added this back rather than manually configure the capability. I could change it to add a basic tool that's always there, but that might add more confusion than benefit. |
halter73
commented
Aug 26, 2025
I think the better bet is to manually initialize the capabilities. That way, the ConfigureSessionOptions callback doesn't need to null-check it either making it slightly shorter while also getting rid of all the // Configure per-session options to filter tools based on route categoryoptions.ConfigureSessionOptions=async(httpContext,mcpOptions,cancellationToken)=>{vartoolCategory=httpContext.Request.RouteValues["toolCategory"]?.ToString()?.ToLower()??"all";// Get pre-populated tools for the requested categoryif(toolDictionary.TryGetValue(toolCategory,outvartools)){mcpOptions.Capabilities=new();mcpOptions.Capabilities.Tools=new();vartoolCollection=mcpOptions.Capabilities.Tools.ToolCollection=new();foreach(vartoolintools){toolCollection.Add(tool);}}};@jozkee Is looking at moving where we put the [JsonIgnore]'d properties on the capabilities types like the collections and handlers so they aren't so deeply nested which could make this look even nicer. Another thing that might help tighten this up is just removing the OpenTelemetry dependencies from this sample. I think it's enough to leave that in the AspNetCoreMcpServer sample and keep this one a little more focused on the per-session options. |
halter73
commented
Sep 3, 2025
Are you okay with me removing the |
PederHP
commented
Sep 4, 2025
Absolutely. I haven't tested it without it yet, but feel free to change as you see fit. |
Uh oh!
There was an error while loading. Please reload this page.
Had Copilot help create a sample of how to use ConfigureSessionOptions to make tools dynamic and client/user specific. See #714.