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
I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Motivation behind the feature request.
I’d like to have hooks that allow runtime manipulation of the tool list before and after tools are built and sent to the LLM based on the user query. Currently, neither the MCP specification nor the existing hook system provides a way to intercept and modify tool definitions at this stage.
This would unlock several important use cases:
Removing unnecessary or irrelevant tools dynamically
Modifying tool schemas, properties, or enums
Injecting additional metadata or constraints
Reducing token usage by trimming verbose tool definitions
Improving LLM focus by exposing only contextually relevant tools
This feature would significantly improve flexibility for advanced tool orchestration and optimization workflows.
Solution I'd like
Add PreToolBuild and PostToolBuild hooks that execute during tool construction/runtime preparation before it is sent to LLM, based on the user query.
These hooks should allow developers to:
Add or remove tools
Modify tool definitions
Adjust properties and enums
Transform schemas before they are sent to the model
The hooks should operate on the final tool collection available to the agent at runtime.
Alternatives considered
An alternative approach is using a proxy layer that intercepts and rewrites tool definitions before they reach the model. While technically possible, this is more complex, less ergonomic, and introduces unnecessary infrastructure overhead for functionality that fits naturally into the hook system.
Additional context
One practical use case is intelligently removing optional or irrelevant tools, their properties, and enums to reduce prompt size and token consumption, while keeping the model focused on the most relevant capabilities.
These issues share the core use case of dynamically controlling which tools are exposed to the LLM. You may want to coordinate with those issues or reference them to consolidate the discussion.
The closest to this request is #23297, though my request is more granular and operates not on the tool level but can manipulate anything in the tools, including tool properties and enums.
Removing irrelevant tools is a great start, but most tools have optional properties that excessive for most cases and keeping only relevant can keep the tool but remove unnecessary information.
Large lists of enums can also be a problem, like for example timezone tool can have a long list of time zones but when a real request comes, usually only one is actually needed.
So my feature request is more granular and balanced to one hand provide flexibility keeping necessary nuanced parts of the tools definition and on the other hand remove irrelevant garbage, save tokens and keep LLM focused.
This issue might be a duplicate of existing issues. Please check:
A ToolBuild hook is powerful, but I would keep it from becoming silent policy mutation by requiring a build receipt.
If a plugin removes or rewrites tools before the model sees them, the runtime should expose at least original tool count, final tool count, removed tool ids, and the plugin or hook responsible. That keeps token trimming and contextual pruning auditable, and it matters a lot once people start comparing behavior across OpenCode, Codex, and Claude Code wrappers where "why was this tool unavailable?" becomes a real migration question.
Activity
github-actions commentedon May 19, 2026
This issue might be a duplicate of existing issues. Please check:
hiddenfield totool.definitionhook output for tool suppression #23297: Proposes adding ahiddenfield to thetool.definitionhook to suppress/remove tools from the LLM's tool list — very similar goal of intercepting tool construction before sending to the modeltool.definitionhook with ahiddenfield — overlapping scopeThese issues share the core use case of dynamically controlling which tools are exposed to the LLM. You may want to coordinate with those issues or reference them to consolidate the discussion.
qdrddr commentedon May 19, 2026
The closest to this request is #23297, though my request is more granular and operates not on the tool level but can manipulate anything in the tools, including tool properties and enums.
Removing irrelevant tools is a great start, but most tools have optional properties that excessive for most cases and keeping only relevant can keep the tool but remove unnecessary information.
Large lists of enums can also be a problem, like for example timezone tool can have a long list of time zones but when a real request comes, usually only one is actually needed.
So my feature request is more granular and balanced to one hand provide flexibility keeping necessary nuanced parts of the tools definition and on the other hand remove irrelevant garbage, save tokens and keep LLM focused.
Keesan12 commentedon May 20, 2026
A ToolBuild hook is powerful, but I would keep it from becoming silent policy mutation by requiring a build receipt.
If a plugin removes or rewrites tools before the model sees them, the runtime should expose at least original tool count, final tool count, removed tool ids, and the plugin or hook responsible. That keeps token trimming and contextual pruning auditable, and it matters a lot once people start comparing behavior across OpenCode, Codex, and Claude Code wrappers where "why was this tool unavailable?" becomes a real migration question.
qdrddr commentedon May 20, 2026
@Keesan12 makes sense.
qdrddr commentedon May 20, 2026
Also, I was thinking that more generic hooks like
PreLLMCallandPostLLMCall(currently non-existent) can also serve my needs.PostLLMCall or PostToolBuild tools are needed in case we want to verify the returned results.
github-actions commentedon Jul 20, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.