4 ms·

The "Tool Search Tool" is like a clever addition that could easily be added yourself to other models / providers. I did something similar with a couple of agent

The "Tool Search Tool" is like a clever addition that could easily be added yourself to other models / providers. I did something similar with a couple of agents I wrote. First LLM Call: only pass the "search tool" tool. The output of that tool is a list of suitable tools the LLM searched for. Second LLM Call: pass the additional tools that were returned by the "search tool" tool.

RobertDeNiro 10mo ago
Since its a tool itself, I dont see the benefit of relying on Anthropic for this. if anything it now becomes vendor lock in.
- michaelanckaert 10mo ago
  Correct, I wouldn't use it myself as it's a trivial addition to your implementation. Personally I keep all my work in this space as provider agnostic as I can. When the bubble eventually pops there will be victims, and you don't want a stack that's hard coded to one of the casualties.
- BoorishBears 10mo ago
  They can post-train the model on usage of their specific tool along with the specific prompt they're using. LLMs generalize obviously, but I also wouldn't be shocked if it performs better than a "normal" implementation.
stavros 10mo ago
When reading the article, I thought this would be an LLM call, ie the main agent would call `find_tool("I need something that can create GitHub PRs")`, and then a subagent with all the MCP tools loaded in its context would return the names of the suitable ones. I guess regex/full text search works too, but the LLM would be much less sensitive to keywords.
slimslenders 10mo ago
I think this is very true. Tool search tools can be model agnostic. And programmatic tool calling really just needs a code sandbox tool. We've provided some examples of these patterns on top of a local docker engine (oss project is here https://github.com/docker/mcp-gateway/ https://github.com/docker/mcp-gateway/ and blog is https://www.docker.com/blog/dynamic-mcps-stop-hardcoding-your-agents-world/ https://www.docker.com/blog/dynamic-mcps-stop-hardcoding-you...).

RobertDeNiro 10mo ago

Since its a tool itself, I dont see the benefit of relying on Anthropic for this. if anything it now becomes vendor lock in.

michaelanckaert 10mo ago
Correct, I wouldn't use it myself as it's a trivial addition to your implementation. Personally I keep all my work in this space as provider agnostic as I can. When the bubble eventually pops there will be victims, and you don't want a stack that's hard coded to one of the casualties.
BoorishBears 10mo ago
They can post-train the model on usage of their specific tool along with the specific prompt they're using. LLMs generalize obviously, but I also wouldn't be shocked if it performs better than a "normal" implementation.

stavros 10mo ago

When reading the article, I thought this would be an LLM call, ie the main agent would call `find_tool("I need something that can create GitHub PRs")`, and then a subagent with all the MCP tools loaded in its context would return the names of the suitable ones. I guess regex/full text search works too, but the LLM would be much less sensitive to keywords.

slimslenders 10mo ago

I think this is very true. Tool search tools can be model agnostic. And programmatic tool calling really just needs a code sandbox tool. We've provided some examples of these patterns on top of a local docker engine (oss project is here https://github.com/docker/mcp-gateway/ https://github.com/docker/mcp-gateway/ and blog is https://www.docker.com/blog/dynamic-mcps-stop-hardcoding-your-agents-world/ https://www.docker.com/blog/dynamic-mcps-stop-hardcoding-you...).