Skip to main content

Tool Results

Every BindAI tool execution produces a ToolResult. ToolResult is the standard result object used by the Tool abstraction. It records whether execution succeeded, the value returned by the underlying Python function, and any error information produced during execution. This provides a predictable contract between tool execution and the rest of the framework.

ToolResult

ToolResult is a dataclass with three fields:
The fields are: ToolResult uses slots=True. The important distinction is that value contains successful tool output, while error contains the error information for failed execution.

How Tool Results Are Created

Tools automatically convert function execution into a ToolResult. For example:
When the tool is called:
the result represents:
The Python function only needs to return its normal Python value. You do not normally need to construct a ToolResult manually.

Successful Execution

When the underlying function completes successfully, Tool wraps its return value in a successful result. Conceptually:
For example:
Calling:
produces:
The original Python return value is available through result.value.

Failed Execution

If the underlying function raises an exception, the Tool abstraction converts the exception into a failed ToolResult. Conceptually:
For example:
Calling:
produces a failed result similar to:
The exact error string depends on the exception raised by the underlying function.

Checking Success

Applications can inspect the success field:
This provides a simple way to distinguish successful execution from failure. A useful general pattern is:

Accessing the Returned Value

A successful tool return value is stored in value. For example:
The output is:
The field is named value, not output. This distinction is important because AgentResult uses a different result interface.

Returning Different Python Values

A tool can return normal Python values.

Strings

The result contains:

Numbers

The result contains:

Lists

The list is stored in:

Dictionaries

The dictionary is stored in:
The ToolResult.value field accepts arbitrary Python values, so the underlying tool can return different value types. Choose return types that are useful and predictable for the application.

None as a Tool Value

A tool can also complete successfully without returning a meaningful value. For example:
A successful execution can therefore contain:
Do not interpret value=None by itself as a failure. Use result.success to determine whether execution succeeded.

Tool Exceptions

Tool exceptions are handled by the Tool abstraction. An exception raised by the underlying function is converted into a failed ToolResult. The resulting error information is derived from the exception. Conceptually:
This gives callers a consistent result object for successful and failed tool execution. For development and debugging, tools should still be written carefully so that unexpected programming errors are not silently ignored.

ToolExecutor

BindAI also provides ToolExecutor.
ToolExecutor works with a ToolRegistry:
It can execute a registered tool by name:
The execution result is represented as a ToolResult. This provides a lower-level execution path that does not require going through a complete agent request.

Unknown Tools

If ToolExecutor cannot find the requested tool in its registry, it returns a failed ToolResult. The result represents the failed lookup:
For example:
The caller can handle the failure using the same ToolResult interface:
This avoids requiring callers to handle a separate result type for an unknown registered tool name.

Tool Execution Flow

The current tool execution flow can be summarized as:
When using ToolExecutor:

ToolResult and Agents

ToolResult is specifically concerned with tool execution. AgentResult represents the result of an agent execution. They have different responsibilities and different APIs. For example, a tool result uses:
An agent execution uses the AgentResult interface described in the Agent execution and Results documentation. Do not assume that fields from one result type are available on the other. In particular:
should not be replaced with:
when working with the current ToolResult API.

ToolResult and Workflows

Tools can also be used as part of workflow execution. A workflow can invoke a tool, inspect its result, and use the successful value in subsequent processing. Conceptually:
The workflow decides how the tool result participates in the larger workflow state. ToolResult itself remains focused on the outcome of the individual tool execution.

ToolResult and External Integrations

Tools commonly wrap external operations such as:
  • API requests
  • Database operations
  • File operations
  • Search operations
  • Notifications
  • Service integrations
For example:
The external operation can return a normal Python value. BindAI then exposes that value through:
If execution fails, the result can instead expose:
This keeps the tool result boundary consistent even when the implementation behind the tool changes.

Current API

The currently verified ToolResult API is:
The available attributes are:
The current API does not define verified helper methods such as:
Use the dataclass fields directly.

Result Handling Pattern

A simple result-handling pattern is:
This pattern keeps success and failure handling explicit. For application code, consider logging failures or propagating them to the appropriate workflow or agent layer rather than silently ignoring them.

Predictable Tool Outputs

Tool outputs should be designed with their callers in mind. Prefer predictable structures for operations that return structured information. For example:
The caller can then reliably inspect:
For more complex applications, structured Python objects or clearly defined dictionaries can make downstream processing easier.

Error Messages

Error messages should provide useful information without exposing sensitive implementation details. For example:
A useful application-level error might communicate that the requested order could not be retrieved. Avoid exposing:
  • API keys
  • Access tokens
  • Passwords
  • Connection strings
  • Sensitive personal information
  • Internal credentials
Tool results can flow back into an agent or external application, so error content should be treated as application-visible data.

Best Practices

  • Return normal Python values from tool functions.
  • Let Tool wrap successful return values into ToolResult.
  • Check result.success before using result.value.
  • Inspect result.error when execution fails.
  • Keep tool return values predictable.
  • Use clear and useful error messages.
  • Avoid exposing secrets or sensitive internal details through errors.
  • Keep tool functions focused on one responsibility.
  • Test both successful and failed execution.
  • Test unknown-tool behavior when using ToolExecutor.
  • Do not rely on an output field for ToolResult; use value.
  • Do not assume ToolResult and AgentResult have identical APIs.
  • Do not depend on undocumented result helper methods.

Complete Example

The agent-level result is an AgentResult, while the individual tool execution uses ToolResult. When working directly with a ToolResult, the successful tool value is accessed through:
This distinction keeps the APIs of tool execution and agent execution separate.

Summary

ToolResult is BindAI’s standard result object for tool execution. The current result structure is:
A successful Python function return value is stored in value. An execution failure is represented by success=False and error information in error. The current public interface is intentionally small:
This provides a simple and consistent contract for executing tools, handling failures, and passing tool results into larger agent or workflow executions.