Logical grouping tools across MCP servers

[isbee]

If we have many servers/tools, LLM can be overwhelmed with too many tools and function calling performance will goes down. mcpjungle is more exposed to this problem because it is a MCP gateway.

So we need concept like modelcontextprotocol/modelcontextprotocol#334 (comment).

[duaraghav8]

I agree with this.

At the moment, you can use a "hack" in mcpjungle to achieve this.

You can create an authenticated client and only assign it specific MCP servers.
Then when you use this client's access token in your mcp client, it will only see tools from that server.

# start mcpjungle in production mode and initialize it
$ mcpjungle start --prod
$ mcpjungle init-server


# create a client which is only allowed to access tools from the "calculator" and "python" MCP servers
$ mcpjungle create mcp-client math-agent --allow calculator,python
MCP client 'math-agent' created successfully!
Servers accessible: calculator,python

Access token: TfGu4doTI2eRzSUJbaDknpt5rg-sxaQqRMsW5aTcOfs
Your client should send this token in the `Authorization: Bearer {token}` HTTP header.

---

But a proper solution can be to create groups of tools like you suggested and expose these groups at dedicated endpoints.

For eg, I create a group math-tools containing tools calculator/multiply and python/execute_script.

Then I can supply the following mcpjungle endpoint to my Claude:
http://localhost:8080/group/math-tools/mcp

My claude will only be able to see the tools inside this group and nothing else.

I'm open to your thoughts on this.

[duaraghav8]

@isbee The latest release v0.2.4 introduces Tool Groups to solve for this.
You can checkout the documentation and give it a try.
I'm going to keep this discussion open for feedback and further improvements.

Thanks

[isbee]

Looks good.

Actually I adopted namespace approach in MetaMCP on my project. This one is similar with Tool Groups, but it groups mcp 'server' and then control tool visibility. Then you just need included_servers, not included_tools which is simpler. (you need to turn off tools though)

There is tool groups discussion on mcp repo. But this SEP has been around for a while and keeps getting pushback. Probably won't get accepted. Some people say just use a search tool to reduce tool count without spec changes. (my summarization on this, and other folk opinion)

Same logic applies to agent tool - seems like the most model-centric approach.

For now though, we can use namespaces/groups because it's easy to implement.

[duaraghav8]

Got it. Just so I'm understanding it correctly, you would find it more convenient to add 1 or more whole MCP servers, and then optionally disable a few tools from them. Rather than having to add each tool individually. Is that correct?

[isbee]

In my opinion, yes. Let's say we have two MCP server and both have 10 tools. If you use included_tools you would write 10~20 tools on included_tools. If you use included_servers then you just write 2 server in included_servers and disable some tools.

• But if you only use a very small number of tools, included_tools may actually be easier.

Additionally, you can explicitly specify which MCP servers are registered to which Tool Group, thereby highlighting the MCP gateway role.

[duaraghav8]

Thanks! This is good feedback for me and I'll figure out a way to solve this problem as well.

[duaraghav8]

Version 0.2.13 is now released and it solves this by adding support for included_servers and excluded_tools fields in Tool Group configuration.

This allows you to include all tools in a server and optionally exclude a few tools.
eg-

{
  "name": "claude-tools",
  "description": "All tools from time and deepwiki servers except time__convert_time",
  "included_servers": ["time", "deepwiki"],
  "excluded_tools": ["time__convert_time"]
}

Docs - https://github.com/mcpjungle/MCPJungle?tab=readme-ov-file#creating-a-tool-group

Thanks for your insights here @isbee!

[duaraghav8]

Version 0.2.13 adds support for this.
I'll keep this discussion open for a while in case of any issues/questions.