-
Notifications
You must be signed in to change notification settings - Fork 469
Dynamic Tool Filtering #703
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Dynamic Tool Filtering #703
Conversation
- Implemented unit tests for IToolFilter implementations including AllowAllToolFilter, DenyAllToolFilter, OAuthToolFilter, ToolNamePatternFilter, and RoleBasedToolFilter. - Added tests for various scenarios such as tool inclusion, execution authorization, priority settings, and exception handling. - Created integration tests for end-to-end tool filtering in MCP server operations, covering cases with no filters, deny all filters, pattern filters, and multiple filters with priority. - Ensured proper handling of exceptions during filtering and authorization processes.
- Implemented PowerShell script (test-all.ps1) to test various aspects of the MCP server including health checks, authentication, authorization, tool visibility, rate limiting, feature flags, error handling, and performance. - Created Bash script (test-all.sh) with similar functionality to ensure cross-platform compatibility. - Added detailed logging for test results, including success, failure, and warnings. - Included parameterization for test categories and server URL. - Implemented robust error handling and response validation for API requests. - Ensured tests cover both valid and invalid scenarios for API keys and tool execution.
Without having dived too deeply into it yet, I think it might be worth considering a unified mechanism for tools, resources, prompts - as any kind of auth convenience or drop-in filtering/dynamic listing that is relevant to tools is equally relevant to the other two (and potential future capabilities). It might be awkward in practice, or even infeasible. Caveat: I have only skimmed the PR. |
Thanks for your contribution! I'm also currently working on adding support for a comprehensive server-side middleware pipeline which is tracked by #267 supporting tools resources and prompts which we will very likely merge instead of this. It's not ready yet but expect a PR later this week, and I'll be sure to mention you so you can review it. As part of this, I'm working to make ASP.NET Core's |
Add comprehensive tool filtering and authorization system with dynamic configuration support, ASP.NET Core
integration, and educational sample demonstrating advanced filtering patterns.
Lowlevel implementation / proposal of IToolFilters.
Compressive Sample implementatino with alot of example/education to demonstrate possibiliites.
Work in progress - higher level abstractions is next step so a attribute based filtering can be done also.
Keeping it in draft until i have had time to try test it out in my own servers.
I would like feedback on the lowlevel IToolFiltering implementation, not so much the sample as it requires more work. But it only make sense if there ar consensus around this could be the lowlevel way we want to support dynamic tool filtering.
Motivation and Context
Problem: The MCP C# SDK currently lacks a comprehensive tool filtering and authorization system, making it
difficult for developers to implement fine-grained access control for MCP tools based on user roles,
permissions, scopes, or business logic.
Solution: This PR introduces a complete tool filtering framework that:
Use Cases:
How Has This Been Tested?
Comprehensive Test Suite:
Educational Sample Application:
business logic filters
Real-World Testing Scenarios:
Breaking Changes
✅ No Breaking Changes - This implementation is fully backward compatible:
New Optional Features:
IToolFilter
interface for custom filter implementationsIToolAuthorizationService
for filter coordinationAuthorizationResult
andAuthorizationChallenge
classesTypes of changes
Checklist
Additional context
Architecture Decisions:
Decorator Pattern Integration: The filtering system integrates with the existing MCP server decorator
pattern, applying filters to the combined tool result from all sources (original handlers + server collection)
to ensure consistent authorization across pagination.
Priority-Based Filter Chain: Filters execute in priority order (lower numbers first) allowing for
performance optimization where expensive filters run after fast-failing security checks.
ASP.NET Core Authorization Integration: Built on proven ASP.NET Core authorization patterns with proper
HTTP challenge responses, making it familiar to .NET developers.
Fail-Secure Design: Any filter denial immediately blocks access, and filter exceptions default to
denying access for security.
Service Abstraction: All filtering services use interfaces allowing for easy testing, mocking, and
production implementations (Redis, database, etc.).
File Structure:
src/ModelContextProtocol.Core/Server/Authorization/
├── Interfaces (IToolFilter, IToolAuthorizationService)
├── Core Services (ToolAuthorizationService, ToolFilterAggregator)
├── Result Classes (AuthorizationResult, AuthorizationChallenge)
├── Built-in Filters (AllowAll, DenyAll, Pattern, Role-based)
└── HTTP Integration (Challenge handling, exception types)
samples/DynamicToolFiltering/
├── Complete working sample with 19 tools
├── 6 advanced filter implementations
├── Multiple authentication schemes
├── Comprehensive documentation and testing guides
└── Production-ready configuration examples
Performance Considerations:
Security Features:
Educational Value:
This implementation provides a robust foundation for secure MCP tool access control while maintaining the
SDK's simplicity and extensibility principles.