fix: Export ToolboxTool from toolbox-core for toolbox-langchain integration

[anubhav756]

The ToolboxTool class within toolbox-langchain relies on importing the ToolboxTool class from the underlying toolbox-core library.

This change exports the ToolboxTool class from toolbox-core, making it easier to access it from toolbox-langchain.

[twishabansal]

Just a curious question: Is there a way to say that it is not recommended to use classes like ToolboxTool?

Something like protected methods in python. It is not impossible to use those but it is discouraged for the users to use the protected methods of classes.

[anubhav756]

Just a curious question: Is there a way to say that it is not recommended to use classes like ToolboxTool?

Something like protected methods in python. It is not impossible to use those but it is discouraged for the users to use the protected methods of classes.

See https://stackoverflow.com/a/551048/28124314

Tldr; we can use underscores just like we use them with method/vars.

Alternatively, we can put comments, just like we did here:

mcp-toolbox-sdk-python/packages/toolbox-langchain/src/toolbox_langchain/async_tools.py

Lines 33 to 35 in ca88369

	# This class is an internal implementation detail and is not exposed to the
	# end-user. It should not be used directly by external code. Changes to this
	# class will not be considered breaking changes to the public API.

Do you think we should make the ToolboxTool as protected?

IMO, I would keep it as is since people might want to use the class for playing around with the tool. Eg:

from toolbox_core import ToolboxTool

tool: ToolboxTool = await client.load_tool("my-tool")
tool.bind_parameters(...)
result = await tool(...)

CC: @kurtisvg

[kurtisvg]

I'm not sure I understand why we need to export ToolboxTool (although not necessarily opposed to it).

Do we have an example of how we are using it that's causing problems?

[anubhav756]

I'm not sure I understand why we need to export ToolboxTool (although not necessarily opposed to it).

Do we have an example of how we are using it that's causing problems?

My main thinking behind proposing it was future flexibility:

• Easier for users with custom orchestration frameworks to import/wrap/extend ToolboxTool.
• Helps anyone using the tool directly (like in the example above) get better typing/IDE support/debugging.
• The import path (from toolbox_core import ToolboxTool) is a bit more standard/discoverable too.
• Plus, it felt consistent since our other orchestration packages export their own wrappers.

But, thinking about it more, I agree it might be premature. It's likely most folks needing custom integration might just use ToolboxClient and won't need to extend the base ToolboxTool directly.

So, makes sense to hold off. I'll close the PR for now to avoid exposing it unnecessarily. 👍 We can definitely reopen if a clear need pops up later!