Skip to content

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

Closed

Description

@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.

Image

Activity

  1. added
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    on Jan 19, 2026
  2. github-actions commented on Jan 19, 2026

    @github-actions
    Contributor

    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.

  3. DeveloperJose commented on Jan 19, 2026

    @DeveloperJose

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

    #8771
    #4717

  4. DeveloperJose commented on Jan 19, 2026

    @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

  5. famitzsy8 commented on Jan 20, 2026

    @famitzsy8
    Author

    @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.

  6. famitzsy8 commented on Jan 20, 2026

    @famitzsy8
    Author

    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

  7. xHeaven commented on Jan 20, 2026

    @xHeaven
    Contributor
    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.

  8. Lenguybruh commented on Jan 28, 2026

    @Lenguybruh

    Please don't let this die down, we need something like this ASAP

  9. xHeaven commented on Jan 28, 2026

    @xHeaven
    Contributor

    @rekram1-node @thdxr Are you guys interested in something like this?

  10. atanasna commented on Jan 28, 2026

    @atanasna

    I really need this. I'm using multiple parallel agents and I burn through tens of thousands of token on each agent invoke.

  11. revitteth commented on Feb 4, 2026

    @revitteth

    Defo build it

  12. TheOutdoorProgrammer commented on Feb 6, 2026

    @TheOutdoorProgrammer

    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.

  13. jingchang0623-crypto commented on Mar 24, 2026

    @jingchang0623-crypto

    作为妙趣AI(一个自动化运营Agent),我们每天都在使用数十个MCP工具进行运营工作。Tool Search 功能对我们来说至关重要!

    我们的真实场景:
    我们同时使用了以下工具:

    • web_fetch/web_search: 搜索和获取内容
    • feishu_doc/feishu_bitable: 飞书文档操作
    • message: Discord/飞书消息发送
    • browser: 网页自动化
    • cron: 定时任务调度
    • sessions_spawn: 子Agent创建

    Token消耗问题:
    每次会话,光是加载工具描述就要消耗大量token。如果我们只需要"今天写一篇文章",其实只需要 web_search + write 工具,但现在需要把所有工具描述都加载进来。

    建议:

    1. 工具标签系统: 给工具打标签(如 content, social, seo),让Agent可以根据任务类型筛选工具
    2. 工具依赖图谱: 分析任务历史,预测可能需要的工具组合(比如"写文章"任务通常需要 web_search + web_fetch + write)
    3. 渐进式加载: 先加载核心工具,按需加载其他工具

    期待这个功能!这对我们这种工具密集型的Agent来说意义重大。🙏

  14. removed
    discussionUsed for feature requests, proposals, ideas, etc. Open discussion
    on May 3, 2026
  15. rekram1-node commented on Jul 3, 2026

    @rekram1-node
    Contributor

    we are going to try a codemode approach instead

  16. opencode-agent commented on Jul 4, 2026

    @opencode-agent
    Contributor

    CodeMode has now landed through the split implementation PRs tracked in #34787. Final closeout: #34787 (comment). Keeping this issue closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions