Q: would having more tools be better?

[BradKML]

I saw the following repo being packed full of tools, it makes we wonder if that is even necessary to do comprehensive database debugging https://github.com/furey/mongodb-lens?tab=readme-ov-file#tools

[github-actions]

Thanks for opening this issue. The ticket MCP-93 was created for internal tracking.

[kmruiz]

Hey @BradKML,

Agents usually have a limit on the amount of tools that can be enabled at the same time and right now it seems that there is no scalable approach to add new tools freely. A few days ago, vscode implementing virtual tools, that should free some context for other most used tools: microsoft/vscode#258360

We want to add more functionality, and we are working on adding more tools in the short term, but we are trying to be as mindful as possible when adding new tools to ensure we don't overload the context.

[BradKML]

@kmruiz I had these notes in RooCode, hope you can check out dynamic tool loading, might be useful but I am not sure. RooCodeInc/Roo-Code#6289 (reply in thread)

[nirinchev]

@BradKML to better understand your ask - is there functionality in the official MongoDB MCP client (i.e. this repo) that you're missing on? Looking at the tools available in https://github.com/furey/mongodb-lens, they seem to offer similar functionality to what we're offering, just have a different structure.

[BradKML]

To put this in reverse, I like to mix in data orchestration MCPs, project management/memory MCPs etc... And some IDEs only accept ~40 functions, which is a bit frustrating. If I need to mix in more tools, fewer options would be needed. But if there are fewer options, the difference between each tool would get more significant.
Would having more tools like MongoDB Lens, and then getting a router, be better than being limited by this MCP but having all the tools availible, even when some of them won't fit the current use case (asssuming I really want to use automated agents)

[nirinchev]

I'm sorry - I don't understand what you mean here. The mongodb-lens MCP seems to offer similar functionality as what the official MCP server offers, it's just structured differently and spread across more tools. I don't see an advantage to bloating the number of tools as that impacts the ability of some clients to take full advantage of them.

Can you clarify what:

being limited by this MCP

means here? I skimmed through the mongodb-lens list of tools and don't see a huge functional difference - it's just that they offer a different model (e.g., they have the notion of a "current database", while we rely on the model to keep track of this, etc.). At the end of the day, it's your call to choose the tool that best fits your workflows - our aim with the official MongoDB MCP server is to build something that is useful for the broadest subset of use cases. If there's a specialized 3rd party server that fits your workflows much better, then you're of course free to use that instead.

[BradKML]

Have people discovered what the characteristics of a well-structured MCP tooling are? KInd of a weird question to ask