TLDR
In AskUI, a Tool is a capability you give to an agent. Out of the box, the agent can see the screen and interact with it. But if you need it to read a file, save a screenshot, send a signal to an external system, or wait for a condition, you give it a Tool for that. AskUI ships with a built-in Tool Store for common operations, and engineers can create custom Tools for anything specific to their test environment.
This post explains what Tools are, what's available out of the box, and how to build your own.
Why Tools Exist
An AskUI agent can perceive the screen and perform OS-level actions (click, type, scroll). That covers a lot, but real-world testing often requires more:
- Reading test cases from a file
- Saving screenshots for reports
- Writing results to disk
- Sending a signal to an external simulation system (like a CANoe API for HVAC control)
- Waiting for a hardware state to settle before verifying the display
Without Tools, you'd have to handle all of this outside the agent. With Tools, the agent can do it as part of the same agentic flow. It reads the test case, calls the HVAC tool, waits for the display to update, captures a screenshot, and writes the report, all in one run.
Built-in Tool Store
AskUI ships with a set of ready-to-use Tools organized by category.
Universal Tools work with any agent type:
| Tool | What it does |
|---|---|
| ReadFromFileTool | Reads content from files (supports multiple encodings) |
| WriteToFileTool | Writes content to files |
| ListFilesTool | Lists files in a directory |
| PrintToConsoleTool | Prints messages to console during execution |
| LoadImageTool | Loads images for analysis or comparison |
| GetCurrentTimeTool | Returns current date/time for time-aware decisions |
| WaitTool | Pauses execution for a specified duration |
| WaitWithProgressTool | Waits with a visual progress bar |
| WaitUntilConditionTool | Polls a condition with configurable interval and timeout |
Computer Tools require Agent OS (desktop environments):
| Tool | What it does |
|---|---|
| ComputerSaveScreenshotTool | Captures and saves screenshots to disk |
| Window management tools | List processes, focus windows, manage virtual displays |
Android Tools require Android Agent OS:
| Tool | What it does |
|---|---|
| AndroidSaveScreenshotTool | Saves screenshots from Android devices |
Tools are passed to the agent when it's created or per individual run:
from askui import ComputerAgent
from askui.tools.store.universal import PrintToConsoleTool, WriteToFileTool
from askui.tools.store.computer import ComputerSaveScreenshotTool
with ComputerAgent(act_tools=[
PrintToConsoleTool(),
WriteToFileTool(base_dir="./reports"),
ComputerSaveScreenshotTool(base_dir="./screenshots"),
]) as agent:
agent.act("Take a screenshot and save it, then print a status message")Custom Tools
This is where it gets interesting for hardware validation. The built-in Tools cover file operations and screenshots. But if you're testing an automotive digital cluster, you need a Tool that talks to your HVAC simulation system. If you're testing a POS terminal, you need a Tool that triggers a payment sequence.
Custom Tools inherit from askui.models.shared.tools.Tool:
# helpers/tools/hvac_tool.py
from askui.models.shared.tools import Tool
class HvacTool(Tool):
"""Wraps the external HVAC simulation API (e.g., CANoe, dSPACE)"""
def __init__(self):
super().__init__(
name="hvac_tool",
description="Sets the HVAC temperature via the external simulation system",
input_schema={
"type": "object",
"properties": {
"temperature": {
"type": "number",
"description": "Target temperature in °C"
}
},
"required": ["temperature"]
}
)
def __call__(self, temperature: float) -> str:
# Engineer implements the connection to their simulation API here
# e.g., canoe_client.set_signal("HVAC_Temp", temperature)
return f"HVAC set to {temperature}°C"Once registered, the agent can use this Tool as part of its agentic flow. When a CSV test case says "Set HVAC to 22°C and verify display," the agent calls the HvacTool to send the signal, then verifies the screen. The engineer writes the Tool once and defines test cases in CSV. The agent figures out when to call which Tool.
For a full walkthrough of how Tools, CSV test cases, and the agent work together in a test run, see How AskUI Orchestrates a Test Run.
MCP: Connecting to External Services
Beyond custom Tools, AskUI supports the Model Context Protocol (MCP) for connecting agents to external services and data sources. MCP is an open standard for how AI agents communicate with external tools, sometimes described as "USB-C for AI."
This means an AskUI agent can connect to databases, messaging platforms, internal APIs, or any service that exposes an MCP interface, without building a custom Tool from scratch.
How the Agent Decides Which Tool to Call
The agent doesn't follow a hard-coded script that says "call Tool A, then Tool B." Instead, the LLM reads the test intent (from a CSV, markdown, or text file), looks at what Tools are available, and decides which ones to call and in what order.
For example, given the test case "Set HVAC to 22°C and verify the climate display shows the correct temperature":
- The agent sees that HvacTool is available and calls it to send the signal
- It waits (using WaitTool or WaitUntilConditionTool) for the display to update
- It captures the screen and reasons about whether 22°C is displayed
- It saves a screenshot (ComputerSaveScreenshotTool) and writes a report (WriteToFileTool)
This is what makes it agentic rather than scripted. The sequence isn't predetermined. The agent plans it based on the goal and the available Tools.
What This Means for Hardware Validation
In traditional test automation, integrating with external systems means writing glue code: API calls, wait loops, error handling, retry logic. All of it hard-coded per test.
With Tools, the integration happens once (write the Tool class), and the agent reuses it across every test case that needs it. A single HvacTool serves every HVAC-related test in the CSV. A single PLC Tool serves every alarm verification test. The test logic stays in natural language, and the Tools handle the system-level plumbing.
This is how teams scale validation across hardware variants without rebuilding test scripts for each one. The Tools stay the same. The CSV test cases change. The agent adapts.
FAQ
What's the difference between a built-in Tool and a custom Tool?
Built-in Tools (from the Tool Store) cover common operations like file I/O, screenshots, and waiting. Custom Tools are ones you write for your specific environment, like interfacing with a CANoe simulation API or a PLC controller. From the agent's perspective, both work the same way: they're registered as available capabilities, and the agent decides when to call them.
Do I need to write code to use Tools?
Built-in Tools require no code beyond importing and registering them. Custom Tools require writing a Python class that inherits from askui.models.shared.tools.Tool. The complexity depends on what the Tool needs to interface with.
Can one agent use multiple Tools in a single test run?
Yes. The agent has access to all registered Tools and decides which ones to call based on the test intent. A single test case can involve file reading, signal sending, screen verification, and report writing, all using different Tools in sequence.
How does this relate to MCP?
MCP (Model Context Protocol) is another way to give the agent access to external capabilities. While custom Tools are Python classes you write, MCP lets you connect to services that already expose an MCP interface. Both expand what the agent can do beyond screen interaction.