Sharing of the OpenEvolve program database

[petermchale]

As I understand it, the program database that is evolved in OpenEvolve is a local database. If that database could be opened up to the world, then users could combine code snippets that others have evolved with their own evolved code snippets. That might increase diversity and lead to more "open-ended" evolution (a la Ken Stanley et al).

The Model Context Protocol (MCP) is an emerging standard that could be used to serve and consume code snippets from users' OpenEvolve program databases, similar to the "MCP Box" of Alita (https://github.com/CharlesQ9/Alita), though that project hasn't yet released any open-source code. If a MCP client were incorporated into OpenEvolve, or could be easily plugged into OpenEvolve, then users could expand their local program databases by consuming code snippets served by a third party over MCP.

[BradKML]

This vibes too close to the individuals of "Devin" Cursorrules, where they practice making their own tools. I think any common-sense agent like OpenHands would also have best practices in coding up new MCPs... https://github.com/grapeot/devin.cursorrules
But inherently there is an issue: tool-routing itself is a hard problem RooCodeInc/Roo-Code#2893 RooCodeInc/Roo-Code#6289 (comment)

Definitely check the following out, there needs to be a patch on MCP-Proxy TBXark/mcp-proxy#38

[petermchale]

@BradKML, I agree that one would want to have a mechanism to serve a small number of code snippets that are relevant to a user query. As you allude to, there are many proxy MCP servers that could accomplish this, e.g.,

https://github.com/metatool-ai/metamcp 
https://github.com/Dumbris/mcpproxy
https://github.com/smart-mcp-proxy/mcpproxy-go
https://github.com/pratikjadhav2726/Unified-MCP-Tool-Graph
https://github.com/samanhappy/mcphub
https://github.com/VeriTeknik/pluggedin-app

[qdrddr]

The problem with semantic search and filtering by the MCP Server is with the fact that LLM needs to do a lot of guesswork, guessing if it needs to invoke the search_tool on this MCP Server, which tools available ahead of time. To address this search must be done before LLM call.

With either implementing Semantic Tool Search/Filtering prior LLM on the McP Client side. Or needs MCP protocol to support search capability (which it does not currently).

[petermchale]

@qdrddr, others don't seem to be intimidated by the challenge:

https://smithery.ai/blog/tool-calls-are-the-new-clicks

cc: @calclavia and @kamath

[BradKML]

Tool filtering/routing will need some tweaks to truly work, and I can't wait

[qdrddr]

This approach of cause works, but makes more retries and LLM tokens burned. Versus if Semantic Ftool filtering is implemented on MCP Client before LLM call, then less retries and less guessing, less money, better quality results.

And as I was saying remote/federated semantic tool search/filtering on the MCP Server end could be possible when MCP protocol will have search specification added (it’s not approved yet).

[petermchale]

Any interest in pursuing this @codelion ?

[codelion]

I will need to think more on how this can work. One concern I have is that this can allow untrusted code from others to be evaluated in the system.

[BradKML]

We need a sandboxing protocol for resource usage and not overwriting the system. If there are MCP or API calls from the internet, make sure there are proxy filters so that harmful stuff won't "get in" similar to how PiHiole can replace Chromium + uBlock Origin (Lite for official Chrome) OR Brave Browser + SlimBrave / Debloatinator.

[TomLucidor]

I have written this to Aixiv, it's a good paper aixiv-org/aiXiv#16 (comment)