@tool decorator to expose them to Orchestrate.
Each Python tool runs inside an isolated container with its own virtual environment. This ensures that the tool and its dependencies remain sandboxed from the host operating system, providing a secure and consistent runtime.
Python tool example
Python
Note:
Python tools must use Google-style docstrings to apply descriptions and document the tool.
Python tools must use Google-style docstrings to apply descriptions and document the tool.
Importing Python-based tools
To import a Python tool use theorchestrate tools import command using the -f flag to specify which python file
contains your tool definitions. Each @tool annotated in the given file will be exposed as a tool within your
active watsonx Orchestrate environment.
It is recommended to include only a single @tool annotated function per file so that tools can be imported independently.
BASH
Additional features of Python tools
Adding Dependencies
Adding Dependencies
If your Python function relies on external libraries or packages, you can ensure your tool works correctly by specifying
these dependencies in the requirements.txt exampleWhen importing your tool, specify the requirements.txt file by using the -r flag.
requirements.txt file.Python tool examplePython
TEXT
For more information on the format of a requests file, please see the official pip documentation.
BASH
Using complex input and output argument types with Pydantic
Using complex input and output argument types with Pydantic
Python tools support input and output arguments based on any native Python type from the typings package and classes which
extend BaseModel from the popular library Pydantic.Example
PYTHON
Securely providing credentials
Securely providing credentials
Python tools are compatible with the watsonx Orchestrate Connections framework. A connection represents a dependency on an external service
and are a way to associate credentials to a tool such as those for Basic, Bearer, API Key, OAuth, or IDP SSO based authentication flows. Python tools also support
key_value connections which as the name implies are arbitrary dictionaries of keys and values which can be used to pass in
credentials for any authorization scheme which does not match one of the existing native schemes.Connections are referenced by something known as an application id (or app_id). This app_id is the unique identifier of a connection.
OpenAPI connections can have at most one Connection’s app_id associated to them.For more information please see, Connections, and the expected_credentials input to the @tool annotation.Creating multi file Python tool packages
Creating multi file Python tool packages
In addition to importing a single tool file, it is possible to import an entire folder (package) along with your tool file.
This is useful when you wish to centralize logic into shared utility libraries, for example, shared authentication, data processing, or including static files such as CSVs or sqlite databases.Assuming a folder structure as follows:my_tool.py:Importing your multifile Python tool:
Assuming your CLI was currently in theLimitations:
PYTHON
Assuming your CLI was currently in the
my_agentic_project folder, this tool could be imported using the following:BASH
Notes:
- Only tools defined in
my_tool.pywill be imported. Other Python files in the package will not be scanned for tools. - The system will only accept strings composed of alphanumeric characters and underscores (
_) in thenameattribute of the@tooldecorator inmy_tool.py. - The system will only accept tool file names composed of alphanumeric characters and underscores (
_). - The package root folder and the tool file path CLI arguments MUST share a common base path.
- The path of the tool file folder relative to the package root folder, must be composed of folder names which are only composed of alphanumeric characters and underscores (
_). - Any whitespace like characters which prefix or suffix provided package root path will be stripped by the system.
- A package root folder path that resolves to an empty string will make the system assume that no package root was specified. Then, the system falls back to single Python file tool import.
- The max compressed tool size: 50Mb
- File resolution for non-python packages must be done relative to the current file, as seen above
- Imports to packages within your code must be resolved relatively
Creating tools that accept files
Creating tools that accept files
You can create Python tools that accept files or return files to download.To do that, you must comply with the following requirements:Use the
The
Use this approach when a tool only needs file metadata or to read the content on demand.
It helps reduce processing overhead and improves performance.
- To accept files as input, the tool must accept a sequence of bytes as arguments.
- To return a file for download, the tool must return a sequence of bytes as output.
WXOFile parameter type when a tool must reference a file without processing its full content.The
WXOFile class provides methods to retrieve file properties or content as needed.You can call the following methods:| Method | Description |
|---|---|
WXOFile.get_file_name(wxo_file) | Returns the file name. |
WXOFile.get_file_size(wxo_file) | Returns the file size in bytes. |
WXOFile.get_file_type(wxo_file) | Returns the file MIME type, such as image/jpeg or text/plain. |
WXOFile.get_content(wxo_file) | Returns the file content in bytes. |
It helps reduce processing overhead and improves performance.
Creating tools that return inline tables, images or links
Creating tools that return inline tables, images or links
The native watsonx Orchestrate web chat supports Markdown rendering. To ensure correct formatting, the LLM can be instructed to return output in Markdown. In some cases, however, it is more efficient for the tool to return the expected output directly, reducing the amount of transformation required by the LLM.Inline tables
Links
Images
PYTHON
PYTHON
PYTHON
Runtime and migration strategy
Python tools execute within a UV virtual environment inside a component called the tools runtime. This runtime includes a predefined set of supported Python versions. Currently, the only supported version is Python 3.12.Version Management
- When a tool is imported into the runtime, it uses the Python version it was originally imported with.
- If that version becomes deprecated by watsonx Orchestrate, the system will:
- Display a deprecation warning in the UI.
- Show the same warning when running the command:
- Inform the user that the tool must be reimported to remain compatible.
Deprecation Timeline
- After 24 months of deprecation:
- The runtime will remove support for the deprecated Python version.
- If the tool has not been reimported, the runtime will attempt to reimport it using the closest supported Python version.
Limitations of Python tools
Host networking
- watsonx Orchestrate Developer Edition: Python tools run inside a container. In this environment, localhost refers to the container itself, not the host machine. To call an endpoint on the host machine, use docker.host.internal or the host machine’s IP address.
- SaaS: The SaaS version of watsonx Orchestrate cannot access your company’s internal network. If internal access is required, prototype with the Developer Edition and then deploy watsonx Orchestrate on-premises or consult IBM for alternative solutions.
- On-premises: To allow a tool to access external internet resources, ensure that firewall rules do not block outbound traffic from the node pool responsible for tool execution.

