Return tool list based on context #1205

I am also trying to determine if MCP supports this concept. The are agent patterns that need a dynamic or hierarchical tool list. This is easy to accomplish when I control the completion loop but it doesn't seem like MCP currently supports this concept?

👋 I've seen a handful of issues around this - I have prototyped a possible solution in almostwhitehat/github-mcp-server#1 and would love feedback.

We have a need for a large based org to be able to do RBAC for tools / prompts / resources available to a specific group from a server. Is this something that would be considered building into the spec / sdks with existing technologies or is this something for the end developer to build themselves into their use case?

I can also think of this as being useful for a company exposing a commercial remote hosted mcp product to enterprise clients where an org customer can configure different permissioning schemes for different users within their org. Let's say for example slack has a commercially available remote mcp, they would want this mcp to be able to control permissioning. Now I guess you could argue that the actual service api would just handle this and if the authenticated user running a tool the service endpoint hit would just return a 403 to mcp and be responsible for the rbac; but mcp are way more than tools. There would be reasons that you don't even want the tools to be visible for user experience, prompts you would want to hide from users, resources you would only want to be made available to certain users such that rbac should be included on the mcp layer as well.

If this warrants its own discussion thread if there's not one yet I can open one too

One possible solution is to spin up additional MCP servers, each hosting a partitioned subset of tools, and configure clients to only be aware of the relevant subset. That said, it would still be ideal to have a simple field in the tools/list request to directly retrieve a specific subset of tools.

One solution would be to advertise only a single tool, "ask_for_tools" that requires user context to be shared, then you have a RAG implemented or more focused LLM select the tool calls based on the user context, and provide them to the client as a tools list change.

I am also facing this issue!

fastWorkflow (https://github.com/radiantlogicinc/fastworkflow) already supports the idea of context as a first class abstraction (including inheritance and abstraction)

Exposing workflows via an MCP server is in the roadmap, but with the current lack of support for dynamic tool lists and contexts in the MCP spec, we are reduced to hacks such as asking the agent the call a tool to update its tool list, or writing an MCP proxy server (which is the current plan)

Here is my relevant idea on how to dynamically filter and exclude tools, Please vote for the idea to update mcp client and server specifications.

#845

Here's my solution: MCP servers could return an updated tool list along with the response if the tool list has changed. If this parameter is not returned, it means the tool list is unchanged. Clients can look for this "updated_tool_list" key in the response and adjust accordingly

This requires a very minimal change to the protocol. Just introduce the notion of an "updated"tool_list" key in the MCP server response payload spec

We've limited Discussions in this repository to meeting notes and are closing this thread. To continue the conversation, pick a channel from Contributor Communication. Thanks for posting.

I've created a clear-your-tools app that injects only relevant tools based on the user prompt.
https://github.com/qdrddr/clear-your-tools

unreal with

uv tool install 'clear-your-tools[all]'