Add filtering for MCP tool list - #1108
Open
Kehrlann wants to merge 2 commits into
Open
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
Kehrlann
marked this pull request as ready for review
August 26, 2026 11:26
Kehrlann
force-pushed
the
dgarnier/tool-filters
branch
from
6d8dbaf to
50cdb3d
Compare
August 26, 2026 11:49
6 tasks
9 tasks
Kehrlann
force-pushed
the
dgarnier/tool-filters
branch
from
50cdb3d to
08b9fdd
Compare
August 27, 2026 06:40
Signed-off-by: Daniel Garnier-Moiroux <git@garnier.wf>
Kehrlann
force-pushed
the
dgarnier/tool-filters
branch
from
08b9fdd to
836277b
Compare
August 27, 2026 13:41
tzolov
requested changes
Aug 27, 2026
| * @return This builder instance for method chaining | ||
| * @see #addToolFilter(McpAsyncListFilter) | ||
| */ | ||
| public AsyncSpecification<S> toolFilters( |
Copy link
Copy Markdown
Contributor
There was a problem hiding this comment.
Not convinced about the practicality of such flexibility. It exposes the builder's internal mutable list. Perhaps a plain toolFilters(List<McpSyncListFilter<Tool>>), or deferring the method until demand appears, would be the safer?
Sorry, something went wrong.
Comment thread
mcp-core/src/main/java/io/modelcontextprotocol/server/McpAsyncListFilter.java
Outdated
Comment thread
mcp-core/src/main/java/io/modelcontextprotocol/server/McpAsyncServer.java
Outdated
Comment thread
docs/server.md
Outdated
Comment thread
mcp-core/src/main/java/io/modelcontextprotocol/server/McpServer.java
Outdated
Comment thread
mcp-core/src/main/java/io/modelcontextprotocol/server/McpServer.java
Outdated
Signed-off-by: Daniel Garnier-Moiroux <git@garnier.wf>
Kehrlann
force-pushed
the
dgarnier/tool-filters
branch
from
4797f17 to
e8d7718
Compare
August 28, 2026 14:55
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
The SDK lacks capabilities for dynamically returning tools, resources, prompts, etc (see #578).
A full implementation in the current state (2.x, 2025-11-25) spec would be complex, as it'd need to target [sync | async] x [stateful | stateless] = 4 variants. We'd need to address the bridges between sync and async, make it coexist with current server's tool management (array list of tools, .addTool method).
We are currently focusing on the implementation of the 2026-07-28 spec, which will bring an entirely new, breaking API. It would be a perfect opportunity to bring in repositories as described in #578 .
In the meantime, we recognize users have been asking for capabilities for a long time. The majority of the asks are centered around filtering the list of tools (#997 , #525, examples in #593, #746, #608, etc). While we recognize there are other asks (dynamic tool generation, other primitives than tools), we think they'd be better addressed by a full #578 implementation. In the meantime, we decided exposing filter capabilities for tools, in this PR.
Scope
This PR is focused on tool list filtering only, while opening the door for filtering other resources if necessary. It addresses filtering in every variant mentioned above.
⚠️⚠️ The filtering only applies to tools listing. It does NOT apply to tool calling, as this can already be achieved in the tool handler. Similarly, it does NOT apply to notifications/tools/list_changed notifications, as these notifications are session-scoped, and not request-scoped. It is recommended that you DO NOT use notifications when using filters.
Closes #997
Closes #525 (with caveats, the main discussion is in #578)
Closes #593 (with caveats, the main discussion is in #578)