Support for Runtime Tool Filtering and/or Multiple MCP Endpoints for Persona-Based Tool Sets in ASP.NET Core

I have a scenario where I need to expose different sets of MCP tools/prompts for different personas (e.g., end user, admin, support/developer) within the same ASP.NET Core application. Ideally, each persona would have access only to the tools relevant to them.

Requirements:

• (Ideal) Ability to filter the set of discovered/exposed tools/prompts at runtime, based on the caller’s identity, claims, or other contextual information. This would allow a single MCP endpoint to dynamically present the appropriate tool set for each persona.
• (Alternative) Ability to register multiple MCP servers/endpoints, each with a different set of tools/prompts, and route requests accordingly (e.g., /mcp/user, /mcp/admin, /mcp/dev).
  • Preferably, the ability to filter tools at registration time (e.g., via a predicate or attribute).
  • Each endpoint (if using multiple) should be independently routable (e.g., via MapMcpServer("/mcp/admin", ...)).

Benefits:

• Enforces least-privilege access to tools.
• Cleanly separates tool sets for different user roles.
• Avoids leaking admin/dev tools to end users.
• (With runtime filtering) Simplifies routing and endpoint management, and enables more flexible, context-aware tool exposure.

Related Issues:
#611: Host several MCP in one ASP.Net application
#591: expose multiple http MCP endpoints in same aspnet core app

I’d be happy to help test or provide more details about our use case. Thanks for considering this feature!

Start by reviewing related issues #611 and #591, then inspect the existing MCP endpoint registration and routing entry points referenced by MapMcpServer. Determine whether runtime filtering or independently routed endpoints should be pursued first, and define completion around persona-specific tool and prompt exposure without leaking other sets.