Function Tools
Allowing your agents to use your python functions as tools for your agents is quite straight forward. You can choose one of the following ways:
Docstrings
Your Python functions need to contain typehints for parameters and docstrings as that is what Railtracks automatically parses to inform your LLM about the capability of the tool. Parameter descriptions can be written as Google-style, NumPy-style, or reST/Sphinx-style docstrings. Typehints always belong on the function signature itself, whatever style you pick.
import railtracks as rt
@rt.function_node # (1)!
def tool_name(arg1: arg1_type, arg2: arg2_type)->return_type:
"""
Information on what this tool does
Args:
arg1: what this arg is
arg2: what this arg is
Returns:
information about return type
"""
...
Agent = rt.agent_node(
...
tool_nodes=[rt.function_node(some_tool)]
)
- Simply add the
railtracks.function_nodedecorator before the definition of your function. This transforms your function into a node type usable upon passing to any agent.
Tool names must be unique
Two different tools cannot share a name — the model would have no way to address them apart
Supported docstring styles
The same tool written in each of the three supported styles. All three produce identical parameter descriptions for the LLM.
The Google Args: header can also be written as Arguments: or Parameters:, and reST accepts every Sphinx parameter field name (:param, :parameter, :arg, :argument, :key, :keyword). Use one style per docstring: if a docstring mixes them, Railtracks warns and reads only one, in the order Google, NumPy, reST.
Inspecting an agent's tools
tool_nodes() returns the tools avaliable to the agent, and tool_info() returns the tool schema that the LLM sees.