Implement Dynamic Toolsets to Reduce Token Usage and Improve Tool Organization (Issue #32)

[aryan4codes]

The changes replace the previous static registration of tools with a dynamic system that allows enabling tools for specific BrowserStack products at runtime.

• Issue Dynamic Tool Discovery #32

Refactor of tool registration:

• Introduced a PRODUCT_TOOLS mapping that associates BrowserStack product categories with their respective tool registration functions, replacing the previous static registerTools function. ([src/index.tsR19-R123](https://github.com/browserstack/mcp-server/pull/64/files#diff-a2a171449d862fe29692ce031981047d7ab755ae7f84c707aef80701b3ea0c80R19-R123))

• Added a new enableProductsTool function, 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 registerTools function with registerInitialTools, which registers only the enableProducts tool 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))

Integration with server initialization:

• Updated the server initialization logic to use registerInitialTools instead of the previous registerTools function, aligning with the new dynamic tool registration system. ([src/index.tsL41-R134](https://github.com/browserstack/mcp-server/pull/64/files#diff-a2a171449d862fe29692ce031981047d7ab755ae7f84c707aef80701b3ea0c80L41-R134))

[ruturaj-browserstack]

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!

[aryan4codes]

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!