github/github-mcp-serverPublic

NotificationsYou must be signed in to change notification settings
Fork3.2k
Star25.3k

Add generic filtering mechanisms to registry package#1620

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Jump to bottom

Merged

SamMorrowDrums merged 3 commits intoSamMorrowDrums/registry-builder-patternfromcopilot/add-generic-filtering-mechanisms

Dec 16, 2025

Merged

Add generic filtering mechanisms to registry package#1620

SamMorrowDrums merged 3 commits intoSamMorrowDrums/registry-builder-patternfromcopilot/add-generic-filtering-mechanisms

Dec 16, 2025

+545 −6

Conversation

Copy link

Contributor

CopilotAI commentedDec 16, 2025•
edited
Loading

Closes:#1618

Description

Adds two generic mechanisms for flexible tool filtering without coupling to domain-specific logic:

1. Tool self-filtering via`Enabled` field

ServerTool.Enabled func(ctx context.Context) (bool, error) allows tools to filter themselves based on request context
Optional field—nil means enabled by default
Errors logged and treated as disabled

2. Cross-cutting filters via`Builder.WithFilter`

ToolFilter func(ctx context.Context, tool *ServerTool) (bool, error) type for builder-level filters
Multiple filters can be chained—all must pass
Filters applied after feature flags but before toolset checks

Filter evaluation order

Tool.Enabled (if set)
FeatureFlagEnable/FeatureFlagDisable (existing)
Read-only filter (existing)
Builder filters (new)
Toolset/additional tools (existing)

New API

Registry.FilteredTools(ctx context.Context) ([]ServerTool, error) provides explicit filtered tools access (currently aliasesAvailableTools for consistency)

Usage

// Tool with self-filteringtool:= registry.ServerTool{Tool:myTool,Toolset:myToolset,HandlerFunc:myHandler,Enabled:func(ctx context.Context) (bool,error) {user:=mypackage.UserFromContext(ctx)returnuser!=nil&&user.HasPermission("use_tool"),nil    },}// Builder with cross-cutting filterreg:=registry.NewBuilder().SetTools(tools).WithFilter(func(ctx context.Context,tool*registry.ServerTool) (bool,error) {return!shouldHideForCurrentAuth(ctx,tool),nil    }).Build()// Get filtered tools per-requestenabledTools,err:=reg.FilteredTools(ctx)

Tradeoffs

FilteredTools returns same result asAvailableTools for now—kept as alias rather than consolidating to preserve clear API surface for future divergence
Filter errors logged to stderr rather than returned—maintains existing error handling pattern for feature flag checks

Original prompt

Summary
Add two generic mechanisms to the registry package for flexible tool filtering without coupling to specific domain concepts:
Enabled function onServerTool - Allows tools to self-filter based on request context
WithFilter method onBuilder - Allows cross-cutting filters to be applied to all tools
Motivation
Consumers of the registry (like github-mcp-server-remote) need to filter tools based on various conditions:
User permissions and policies
Request context (e.g., which client is calling)
Feature flags with complex logic (AND/OR combinations)
Runtime availability of dependencies
Currently, consumers must do this filtering externally before passing tools to the registry, which leads to complex orchestration code. By adding generic filter hooks, consumers can encapsulate their domain-specific logic while the registry remains agnostic.
Implementation
1. AddEnabled field toServerTool struct inpkg/registry/tool.go:
typeServerToolstruct {Tool              mcp.ToolToolsetToolsetMetadataHandlerFuncHandlerFuncFeatureFlagEnablestringFeatureFlagDisablestring// Enabled is an optional function called at build/filter time to determine// if this tool should be available. If nil, the tool is considered enabled// (subject to FeatureFlagEnable/FeatureFlagDisable checks).// The context carries request-scoped information for the consumer to use.// Returns (enabled, error). On error, the tool should be treated as disabled.Enabledfunc(ctx context.Context) (bool,error)}
2. AddToolFilter type andWithFilter method toBuilder inpkg/registry/registry.go:
// ToolFilter is a function that determines if a tool should be included.// Returns true if the tool should be included, false to exclude it.typeToolFilterfunc(ctx context.Context,tool*ServerTool) (bool,error)// WithFilter adds a filter function that will be applied to all tools.// Multiple filters can be added and are evaluated in order.// If any filter returns false or an error, the tool is excluded.func (b*Builder)WithFilter(filterToolFilter)*Builder {b.filters=append(b.filters,filter)returnb}
3. UpdateisToolEnabled in the builder to check these in order:
Check tool's ownEnabled function (if set)
CheckFeatureFlagEnable (existing behavior)
CheckFeatureFlagDisable (existing behavior)
Apply builder filters (new)
4. Add a context-aware method to get filtered tools:
// FilteredTools returns tools filtered by the Enabled function and builder filters.// This should be called per-request with the request context.func (r*Registry)FilteredTools(ctx context.Context) ([]ServerTool,error)
Example Usage
// Tool with self-filtering logictool:= registry.ServerTool{Tool:myTool,Toolset:myToolset,HandlerFunc:myHandler,Enabled:func(ctx context.Context) (bool,error) {// Consumer's domain-specific logic hereuser:=mypackage.UserFromContext(ctx)returnuser!=nil&&user.HasPermission("use_tool"),nil    },}// Builder with cross-cutting filterreg:=registry.NewBuilder().SetTools(tools).WithFilter(func(ctx context.Context,tool*registry.ServerTool) (bool,error) {// Cross-cutting concern like scope filteringreturn!shouldHideForCurrentAuth(ctx,tool),nil    }).Build()// Get filtered tools for a requestenabledTools,err:=reg.FilteredTools(ctx)
Testing
Add tests for:
Enabled function returning true/false/error
WithFilter with single and multiple filters
Interaction betweenEnabled, feature flags, and filters
FilteredTools method with various filter combinations
Backwards Compatibility
All new fields are optional with nil/empty defaults
Existing code continues to work unchanged
FeatureFlagEnable/FeatureFlagDisable remain fully functional

💬 We'd love your input! Share your thoughts on Copilot coding agent in our2 minute survey.

Initial plan

8e014a5

CopilotAI assignedCopilot andSamMorrowDrums

Dec 16, 2025

Copilotstarted work on behalf ofSamMorrowDrums

December 16, 2025 10:05

View session

Add generic tool filtering mechanisms to registry package

6572d38

- Add Enabled field to ServerTool for self-filtering based on context- Add ToolFilter type and WithFilter method to Builder for cross-cutting filters- Update isToolEnabled to check Enabled function and builder filters in order:  1. Tool's Enabled function  2. Feature flags (FeatureFlagEnable/FeatureFlagDisable)  3. Read-only filter  4. Builder filters  5. Toolset/additional tools check- Add FilteredTools method to Registry as alias for AvailableTools- Add comprehensive tests for all new functionality- All tests pass and linter is cleanCloses#1618Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>

CopilotAI changed the title~~[WIP] Add generic mechanisms for tool filtering in registry package~~Add generic filtering mechanisms to registry package

Dec 16, 2025

CopilotAI requested a review fromSamMorrowDrums

December 16, 2025 10:18

Copilotfinished work on behalf ofSamMorrowDrums

December 16, 2025 10:18

SamMorrowDrums marked this pull request as ready for review

December 16, 2025 10:27

SamMorrowDrums requested a review froma team as acode owner

December 16, 2025 10:27

CopilotAI review requested due to automatic review settings

December 16, 2025 10:27

Copilotstarted reviewing on behalf ofSamMorrowDrums

December 16, 2025 10:27

View session

CopilotAI reviewed

Dec 16, 2025

View reviewed changes

Copy link

Contributor

CopilotAI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Pull request overview

This PR adds two generic filtering mechanisms to the registry package to enable flexible, context-aware tool filtering without coupling to domain-specific logic. The implementation adds anEnabled field toServerTool for self-filtering and aWithFilter builder method for cross-cutting filters, along with a newFilteredTools method for explicit filtered tool access.

Key changes:

Tool-level self-filtering via optionalEnabled function field onServerTool
Builder-level cross-cutting filters via newWithFilter method
NewFilteredTools method as an explicit API for accessing filtered tools

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
pkg/registry/server_tool.go	Added`Enabled func(ctx context.Context) (bool, error)` field to`ServerTool` struct for tool self-filtering
pkg/registry/builder.go	Added`ToolFilter` type and`WithFilter` builder method for applying cross-cutting filters
pkg/registry/registry.go	Added`filters []ToolFilter` field to`Registry` struct and propagated it in`ForMCPRequest`
pkg/registry/filters.go	Updated`isToolEnabled` to evaluate new filter mechanisms in correct order; added`FilteredTools` method
pkg/registry/registry_test.go	Added comprehensive test coverage for new filtering mechanisms, including edge cases and interaction tests

pkg/registry/filters.goShow resolvedHide resolved

docs: improve filter evaluation order and FilteredTools documentation

cc94b25

- Add numbered filter evaluation order to isToolEnabled function doc- Number inline comments for each filter step (1-5)- Clarify FilteredTools error return is for future extensibility- Document that library consumers may need to surface recoverable errorsAddresses review feedback on PR#1620

SamMorrowDrums merged commit418c52b intoSamMorrowDrums/registry-builder-pattern

Dec 16, 2025

15 checks passed

SamMorrowDrums deleted the copilot/add-generic-filtering-mechanisms branch

December 16, 2025 18:47