anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 10:15:31 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

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

New Issue
Open
opened 2026-02-16 18:05:23 -05:00 by yindo · 11 comments
yindo commented 2026-02-16 18:05:23 -05:00
Owner
Copy Link
Copy Source

Originally created by @famitzsy8 on GitHub (Jan 19, 2026).

Originally assigned to: @thdxr on GitHub.

  • 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
Originally created by @famitzsy8 on GitHub (Jan 19, 2026). Originally assigned to: @thdxr on GitHub. - [x] 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](https://github.com/famitzsy8/opencode-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](https://github.com/famitzsy8/opencode-tool-search-tool) 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. <img width="1114" height="491" alt="Image" src="https://github.com/user-attachments/assets/85529104-69b4-41c2-abe3-5eb16cec62a8" />
yindo added the discussion label 2026-02-16 18:05:23 -05:00
yindo commented 2026-02-16 18:05:23 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 19, 2026):

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

  • #9350: [Feature Request] MCP Tool Search - Lazy Loading for 85% Token Reduction
  • #9407: [FEATURE]:ToolSearch
  • #8277: [FEATURE]: Lazy/dynamic loading for mcp tools
  • #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.

@github-actions[bot] commented on GitHub (Jan 19, 2026): This issue might be a duplicate of existing issues. Please check: - #9350: [Feature Request] MCP Tool Search - Lazy Loading for 85% Token Reduction - #9407: [FEATURE]:ToolSearch - #8277: [FEATURE]: Lazy/dynamic loading for mcp tools - #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.
yindo commented 2026-02-16 18:05:23 -05:00
Author
Owner
Copy Link
Copy Source

@DeveloperJose commented on GitHub (Jan 19, 2026):

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

https://github.com/anomalyco/opencode/pull/8771
https://github.com/anomalyco/opencode/pull/4717

@DeveloperJose commented on GitHub (Jan 19, 2026): This is the 3rd proposed implementation suggested that I know of, I am listing the other 2 below https://github.com/anomalyco/opencode/pull/8771 https://github.com/anomalyco/opencode/pull/4717
yindo commented 2026-02-16 18:05:23 -05:00
Author
Owner
Copy Link
Copy Source

@DeveloperJose commented on GitHub (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

@DeveloperJose commented on GitHub (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
yindo commented 2026-02-16 18:05:23 -05:00
Author
Owner
Copy Link
Copy Source

@famitzsy8 commented on GitHub (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:

  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 commented on GitHub (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: 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.
yindo commented 2026-02-16 18:05:23 -05:00
Author
Owner
Copy Link
Copy Source

@famitzsy8 commented on GitHub (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

@famitzsy8 commented on GitHub (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
yindo commented 2026-02-16 18:05:23 -05:00
Author
Owner
Copy Link
Copy Source

@xHeaven commented on GitHub (Jan 20, 2026):

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.

@xHeaven commented on GitHub (Jan 20, 2026): > 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.
yindo commented 2026-02-16 18:05:23 -05:00
Author
Owner
Copy Link
Copy Source

@Lenguybruh commented on GitHub (Jan 28, 2026):

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

@Lenguybruh commented on GitHub (Jan 28, 2026): Please don't let this die down, we need something like this ASAP
yindo commented 2026-02-16 18:05:23 -05:00
Author
Owner
Copy Link
Copy Source

@xHeaven commented on GitHub (Jan 28, 2026):

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

@xHeaven commented on GitHub (Jan 28, 2026): @rekram1-node @thdxr Are you guys interested in something like this?
yindo commented 2026-02-16 18:05:24 -05:00
Author
Owner
Copy Link
Copy Source

@atanasna commented on GitHub (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.

@atanasna commented on GitHub (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.
yindo commented 2026-02-16 18:05:24 -05:00
Author
Owner
Copy Link
Copy Source

@revitteth commented on GitHub (Feb 3, 2026):

Defo build it

@revitteth commented on GitHub (Feb 3, 2026): Defo build it
yindo commented 2026-02-16 18:05:24 -05:00
Author
Owner
Copy Link
Copy Source

@TheOutdoorProgrammer commented on GitHub (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 https://github.com/anomalyco/opencode/issues/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.

@TheOutdoorProgrammer commented on GitHub (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 https://github.com/anomalyco/opencode/issues/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: - #9461 - #9350 - #8277 Semi related issues that would compliment this (for visibility): - #7399 I've rebased #8771 [here](https://github.com/anomalyco/opencode/pull/12520). I've been running it for a few days its working amazing. Looking forward to this being part of OpenCode.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#6828
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?