COMMON TOOL CATEGORIES

EXAMPLES Example 1: A web search tool. An agent is asked about a recent regulation. It calls a web search tool with the words "new data privacy regulation summary." The tool returns ten results, each with a title, a two-line snippet, and a URL. The agent reads the snippets, picks the two most promising official sources, and calls a fetch tool on each URL to read the full text. It then cites both sources in its answer. Because web content is untrusted, the harness marks fetched text clearly as outside material, so the model treats any instructions found in it as data and not as commands. Example 2: A shell tool. A coding agent has just changed a function. It uses a shell tool to run pytest, a popular Python testing program. The tool reports "42 passed, 3 failed," plus the error traces for the failed tests. The agent reads the traces, fixes the code, and runs pytest again until all tests pass. The shell runs inside a sandbox with a 60-second time limit and no network, and an allowlist that permits test commands but refuses commands that delete folders. Example 3: A specialized domain tool. A medical-coding agent helps billing staff. Its lookup_billing_code tool takes a diagnosis description and returns the matching code from an official code set, along with a confidence note. The tool is built for healthcare workflows and is unlikely to be useful elsewhere. Because a wrong code can cause billing errors, the harness requires a human coder to confirm each code before submission, and the team tests the tool against a set of known cases. Example 4: A communication tool with a safety rail. A customer-service agent has two tools: draft_email and send_email. The draft_email tool saves a draft in a folder for a human to look over and cannot send anything. The send_email tool is guarded by an approval step and an allowed-recipient list, and is limited to 10 messages per minute. Because the tools are separate, drafting can never accidentally trigger sending.