[FEATURE]: Claude-style Tool Search Tool Implementation in OpenCode

[famitzsy8]

• I have verified this feature I'm about to request hasn't been suggested before.

One feature that the Claude API offers, and that has seen recent integration into Claude Code, is the Tool Search Tool. Now there are multiple issues talking about dynamic MCP tool loading here, but I have seen no issue that tries to tackle an all-out deferred tool-loading option for built-in tools, plug-in's and MCP tools. Here in this fork there lives an attempt of mine to do so, and I wanted to ask the community what tests would need to be run to validate proper working of the OpenCode CLI, and how the feature itself should be adapted in order to start a proper pull request. Looking forward to inputs.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [Feature Request] MCP Tool Search - Lazy Loading for 85% Token Reduction #9350: [Feature Request] MCP Tool Search - Lazy Loading for 85% Token Reduction
• [FEATURE]:ToolSearch #9407: [FEATURE]:ToolSearch
• [FEATURE]: Lazy/dynamic loading for mcp tools #8277: [FEATURE]: Lazy/dynamic loading for mcp tools
• [FEATURE]:Add mcp search tool, reduce mcp tool occupying a lot of context #8625: [FEATURE]:Add mcp search tool, reduce mcp tool occupying a lot of context

All of these issues discuss implementing Claude-style tool search/lazy loading functionality for MCP tools to reduce context window consumption. Feel free to ignore if your specific implementation approach differs from these.

[DeveloperJose]

This is the 3rd proposed implementation suggested that I know of, I am listing the other 2 below

#8771
#4717

[DeveloperJose]

I like the bus context events API idea, I've been working on #6152 and save the context messages to the storage but having events so others can make plugins is probably the better approach. But isn't that outside the scope of this feature request? The PR should focus on just the tool search tool in my opinion

[famitzsy8]

@xHeaven @DeveloperJose As Jose said, if we are serious about this we should consolidate all our ideas into one issue/PR that gets more attention.

For that some design questions:

1. Do we want to focus only on MCP servers or on all (custom) tools that one can have/build?
2. What do we want to have loaded/configured by default?
3. What are other nice-to-have features that we could implement?

As for me, I would suggest that we build the equivalent to Claude' Tool Search Tool where you have the freedom to defer loading of all possible tools. (Q1) We should also make whatever Tool Search we implement optional to use, such that the default still corresponds to all tools being eagerly loaded. (Q2) Some other features could be a /context shortcut that allows you to look at the (saved) context. (Q3)

But I'm open to discuss and let us bring this forward! Also @thdxr if you could give some feedback on how to proceed, it would be greatly appreciated.

[famitzsy8]

Another thing we would have to do is to modify and enhance the prompting such that tool search is being used correctly across all models

[xHeaven]

1. Do we want to focus only on MCP servers or on all (custom) tools that one can have/build?

I feel like we should focus mainly on MCP servers, but we can probably extend the scope to non-MCP tools as well. I'd prefer that in a separate approach, though.

2. What do we want to have loaded/configured by default?

Built-in tools should always be loaded into context entirely. Plugin-tools should have the option to be deferred.

MCP server names (and perhaps tool names as well) should always be loaded into context as well.