-
Notifications
You must be signed in to change notification settings - Fork 25
Implement Dynamic Toolsets to Reduce Token Usage and Improve Tool Organization (Issue #32) #64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
...ganization: - Only `enableProducts` tool is exposed initially - Tools are registered on-demand by product - Tools grouped by product categories - State tracking prevents duplicate registration
Thanks for the PR, @aryan4codes – the enableProducts approach works as expected!
That said, our goal is to enable tools implicitly based on query intent, without requiring an explicit enableProducts call. (Ref: Issue #275)
I explored this in PR #62, where tools are dynamically registered during runtime. While they appear correctly in the UI, the issue is that tools registered mid-chain aren’t immediately discoverable or invokable in the same message cycle—they only work in the next one. This breaks chained execution where a tool is needed right after it’s dynamically registered.
If you’ve come across a solution for this, would love to hear your thoughts. Appreciate your work on this!
Thanks for the detailed context from the issue @ruturaj-browserstack .
I understood the challenge with the timing issue in dynamic tool registration. Let me dive deeper and explore some potential approaches to enable implicit tool discovery without breaking the execution chain.
I'll get back to you with a possible solution once I've had a chance to properly analyze the requirements. Thanks for your guidance on this!
Uh oh!
There was an error while loading. Please reload this page.
The changes replace the previous static registration of tools with a dynamic system that allows enabling tools for specific BrowserStack products at runtime.
Refactor of tool registration:
PRODUCT_TOOLSmapping that associates BrowserStack product categories with their respective tool registration functions, replacing the previous staticregisterToolsfunction. ([src/index.tsR19-R123](https://github.com/browserstack/mcp-server/pull/64/files#diff-a2a171449d862fe29692ce031981047d7ab755ae7f84c707aef80701b3ea0c80R19-R123))image
Added a new
enableProductsToolfunction, which dynamically enables tools for specified products, validates input, and tracks enabled products. This function ensures that only tools for selected products are registered. ([src/index.tsR19-R123](https://github.com/browserstack/mcp-server/pull/64/files#diff-a2a171449d862fe29692ce031981047d7ab755ae7f84c707aef80701b3ea0c80R19-R123))Replaced the
registerToolsfunction withregisterInitialTools, which registers only theenableProductstool initially and stores a reference to the server instance for dynamic tool registration. ([src/index.tsR19-R123](https://github.com/browserstack/mcp-server/pull/64/files#diff-a2a171449d862fe29692ce031981047d7ab755ae7f84c707aef80701b3ea0c80R19-R123))image
Integration with server initialization:
registerInitialToolsinstead of the previousregisterToolsfunction, aligning with the new dynamic tool registration system. ([src/index.tsL41-R134](https://github.com/browserstack/mcp-server/pull/64/files#diff-a2a171449d862fe29692ce031981047d7ab755ae7f84c707aef80701b3ea0c80L41-R134))