Wrapper for MCPs

[juienpro]

Hi,

According to my understanding, the current MCP architecture is not very good. Each time we call ->tools() on the McpConnector,, all tools are loaded and transmitted to the backend LLM. The only way to make it lighter is to use only() / except().

This is a massive issue for MCP with a lot of tools.

I think we should tackle this issue by adopting the pi-mcp-adapter implementation:

1. All tools from MCP are loaded independently of the agent, and cached/refreshed according to the user needs through a McpConnector::refresh() or something like that.

2. Then a unique tool is exposed to the LLM: mcp, allowing the agent to search for a particular tool within the MCP servers.

3. Prefixing strategy of each tool can be choosen by the developer. This is important as it would allow the usage of two same MCPs but with different configurations, without naming conflicts.

Main advantages:

1. we don't send hundred of tools to the LLM each turn, but a unique one
2. we improve the overall performances as we decorrelate the discovery of MCP tools from the agent.

That's not difficult to implement for a developer, so it might not be an "urgent" problem. But still, I think it would be good to make it native.

Let me know if I have a bad understanding!

Thanks

[ilvalerione]

It could be an interesting addition to the MCPConnector. More in general your post is making me think of a tool-search tool. So this strategy could be applied not only to MCP but to the entire tool suite you want to attach to the agent. It should make tools availbale to the model dynamically, that's the most relevant problem in the architecture.

[juienpro]

Yes. I think it would make sense to have two layers.

1. Frequent tools (typically read_file) sent to the LLM and included each turn. So we avoid a step and a possible misalignment for frequent operations.

2. Other marginal tools, not used very frequently.

It would solve also the Toolkit issue where we don't have a progressive discovery I think. Adding Calculator and Calendar toolkits makes your prompt > 3000 tokens I believe, for instance.

So, yes, implementing a DiscoverabilityStrategy for each tool/mcp/toolkit would be fantastic: Direct for tools included in each turn, Searchable for others. It would also pave the way for a future vector search.

I've just seen it's how it is implemented by Claude.

https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool

[ilvalerione]

I Introduced a new middleware. With a global middleware it was quite straightforward: https://github.com/neuron-core/neuron-ai/releases/tag/3.4.11

It can be used with tools, toolkit, and MCP, while you can still provide the core tools the model will always see in the normal tools() method.

Let me know what you think.

[ilvalerione]

Here is a demo: https://www.youtube.com/watch?v=qYmidHAXEYM