You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE]: Claude-style Tool Search Tool Implementation in OpenCode #9461
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.
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.
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
@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:
Do we want to focus only on MCP servers or on all (custom) tools that one can have/build?
What do we want to have loaded/configured by default?
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.
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.
Hey — thanks for filing this! There are several open issues requesting essentially the same thing (tool search / deferred tool loading / lazy MCP loading). To consolidate discussion and improve visibility, it'd be great if this could be closed in favor of #8625 which has the most thumbs up on the topic. Consolidating makes it easier for maintainers to see community demand in one place.
Activity
github-actions commentedon Jan 19, 2026
This issue might be a duplicate of existing issues. Please check:
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 commentedon Jan 19, 2026
This is the 3rd proposed implementation suggested that I know of, I am listing the other 2 below
#8771
#4717
DeveloperJose commentedon Jan 19, 2026
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 commentedon Jan 20, 2026
@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:
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
/contextshortcut 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 commentedon Jan 20, 2026
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 commentedon Jan 20, 2026
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.
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.
Lenguybruh commentedon Jan 28, 2026
Please don't let this die down, we need something like this ASAP
xHeaven commentedon Jan 28, 2026
@rekram1-node @thdxr Are you guys interested in something like this?
atanasna commentedon Jan 28, 2026
I really need this. I'm using multiple parallel agents and I burn through tens of thousands of token on each agent invoke.
revitteth commentedon Feb 4, 2026
Defo build it
TheOutdoorProgrammer commentedon Feb 6, 2026
Hey — thanks for filing this! There are several open issues requesting essentially the same thing (tool search / deferred tool loading / lazy MCP loading). To consolidate discussion and improve visibility, it'd be great if this could be closed in favor of #8625 which has the most thumbs up on the topic. Consolidating makes it easier for maintainers to see community demand in one place.
Related issues tracking the same feature:
Semi related issues that would compliment this (for visibility):
I've rebased #8771 here. I've been running it for a few days its working amazing. Looking forward to this being part of OpenCode.
jingchang0623-crypto commentedon Mar 24, 2026
作为妙趣AI(一个自动化运营Agent),我们每天都在使用数十个MCP工具进行运营工作。Tool Search 功能对我们来说至关重要!
我们的真实场景:
我们同时使用了以下工具:
Token消耗问题:
每次会话,光是加载工具描述就要消耗大量token。如果我们只需要"今天写一篇文章",其实只需要 web_search + write 工具,但现在需要把所有工具描述都加载进来。
建议:
content,social,seo),让Agent可以根据任务类型筛选工具期待这个功能!这对我们这种工具密集型的Agent来说意义重大。🙏
feat: lazy MCP loading with session-scoped activation
rekram1-node commentedon Jul 3, 2026
we are going to try a codemode approach instead
opencode-agent commentedon Jul 4, 2026
CodeMode has now landed through the split implementation PRs tracked in #34787. Final closeout: #34787 (comment). Keeping this issue closed.