Tools

Tools define specific capabilities for your agents. A tool gives your agent the ability to do tasks. Tools are reusable — you can attach the same tool to multiple agents.

A tool exposes a single capability the LLM can invoke. Every tool carries a name, a purpose, and a schema. Tools come in two variants:

• Structured — A JSON schema in the OpenAI function-calling format that the LLM fills in. Best for advisory tools and for structured calls into upstream systems where the argument shape matters.
• Code — A schema plus an uploaded Python handler that actually runs. The LLM calls a single handler(event, context) entry point and receives whatever you return. Best for deterministic work: calculations, lookups, and calls out to external services.

Both variants carry a schema, because the schema is what the LLM reads to decide how to call the tool. A code tool can generate its schema from the handler's docstring for you.

For the full authoring reference — the Python handler contract, schema patterns, worked examples, and bundle rules — see Tool Authoring Reference.

What You Can Build

Tools extend an agent beyond what the underlying LLM knows or can compute on its own — giving it access to your firm's conventions, your upstream systems, and deterministic code that runs the same way every time. A few illustrative examples:

• Create Jira ticket (Structured) — A function-calling spec that declares project, summary, description, priority, and assignee with the exact enums your workflow allows. The agent collects the right fields from the conversation and the call into your ticketing system has the shape it expects — no copy-paste between chat and a web form, no malformed payloads.
• Drawing review checklist (Structured) — Capture your firm's conventions for reviewing engineering drawings: title block fields, dimensioning standards, GD&T usage, sheet-size and revision rules. Encoded in the tool's purpose and schema, the agent applies the same checklist on every drawing instead of re-deriving "what good looks like" from the model's general knowledge — and updating the rules in one place updates every agent the tool is attached to.
• Beam deflection solver (Code) — A handler that takes load, length, modulus, and cross-section and returns a deflection curve. The LLM hands the math to code, the code returns numbers it can trust, and the agent narrates the result. Use this pattern whenever the answer must be repeatable and auditable — finance calculations, unit conversions, table lookups against a bundled materials CSV, or any computation where "the model did it in its head" isn't good enough.
• Web / API search (Code) — A handler that takes a query and optional filters, calls out to a search API or vendor REST endpoint, and returns the top hits with title, URL, and snippet. Use this pattern whenever the agent needs information that lives outside the conversation and outside the model's training cutoff — current standards documents, an internal knowledge base, supplier catalogs, regulatory filings. Remember to allow the hostnames it needs under Runtime Access.

Each variant plays to a different strength: structured tools encode contracts and judgment, code tools encode deterministic work. A well-built agent typically carries a mix.

Creating a Tool

1. Open Tools in the sidebar and click New Tool. This opens an empty tool editor.
2. Fill in the two required fields:
   • Name — Shown to you, and normalized into the identifier the LLM calls. A short verb-object name like search_documents works well.
   • Purpose — Sent to the LLM as context. Describe when it should call this tool, in one or two sentences.
3. Pick a Tool variant — Structured or Code.
4. For a code tool, upload your Python bundle and set its runtime access (see below).
5. Define the Schema, or generate it from your code.
6. Optionally add Trigger conditions.
7. Click Save.

Tool Variant

Two cards let you choose how the tool works:

• Structured — "JSON schema the LLM fills in."
• Code — "Python executable plus schema."

Switching from Code back to Structured discards the attached bundle, since a code tool is defined by having one.

Python Executable Tool

When the Code variant is selected, a Python Executable Tool card appears.

Start from a template

Before you have uploaded anything, the card offers three starter templates:

• Minimal handler — one function, one action.
• Multi-solver dispatcher — routes an action field to the matching parameter block.
• Reads attached files — CSV/JSON lookups against a file bundled with the tool.

Picking a template updates the code preview below the cards. Download starter .zip gives you a ready-to-edit archive containing handler.py, requirements.txt, and a short README. Edit it locally and upload it back.

Once a bundle is attached, the templates are hidden. Remove the archive to start over from a template.

Uploading your handler

Uploads accept exactly one .zip per tool, with:

• handler.py at the archive root.
• requirements.txt listing every dependency (it may sit at the root or one directory down).
• handler(event, context) returning a JSON-serializable dict.
• A docstring on the handler documenting every event field.

The checklist beside the dropzone lists these, and ticks once a valid archive is attached.

Bare .py uploads are not accepted

Every tool needs a requirements.txt alongside its handler, which a lone .py file cannot carry. Zip your handler and its requirements together and upload the archive.

Archives are unpacked in the browser and validated before upload, so structural problems — a missing handler.py, no requirements.txt, no def handler(event, context), a missing docstring — are reported immediately. Cache and metadata noise (__pycache__/, .pyc, .git/, virtual-env directories, OS metadata) is stripped during extraction. The directory structure is preserved, so relative imports resolve at runtime.

Runtime Access

Code tools get a Runtime access card. The sandbox is sealed from the public internet by default.

• Toggle Allow internet access to let the handler make outbound calls.
• Add the specific hostnames it needs (for example api.example.com) and press Enter or click Add URL. Requests to anything not on the list are blocked.

Two conditions disable Save until you fix them: a hostname that matches your organization's block list (flagged blocked on the chip), and internet access enabled with no hostnames listed.

Runtime access applies when your uploaded handler runs — not to the starter download.

Schema

The Schema card is what the LLM reads to decide how to call the tool. It uses the OpenAI function-calling format.

The editor has two modes, toggled in its toolbar:

• Schema — a tree view. Use Add field, Add list, and Remove last for top-level entries; hover a row to add nested entries or delete items. Double-click any key or value to edit in place, and use the type selector to change a value's type (text, number, boolean, object, or list).
• Raw — the underlying JSON, for editing or pasting directly.

For code tools with a bundle attached, a Generate from Code button appears in the card header. It reads the handler's docstring and parameter annotations and writes the resulting schema into the editor, which stays fully editable afterward. Review the generated spec against your docstring — they should agree.

tip

You don't have to click Generate. Saving a new code tool with an empty schema runs the same generator automatically before saving.

Trigger Conditions

Trigger conditions tell the agent when a tool should activate. Click Add condition to add one or more. Each is a natural-language cue — for example, "when the user asks about documents".

A "Code Review" tool might carry:

• "When the user asks for a code review"
• "When the user shares a code snippet and asks for feedback"
• "When the user asks about best practices for a piece of code"

These conditions help the agent decide when to bring this tool into play versus relying on its other tools or general knowledge.

Saving and Versions

The editor header shows Draft — unsaved changes whenever you have edits pending, and warns you if you try to leave without saving.

Saving an existing tool creates a new version of it rather than overwriting the old one. The editor follows the new version automatically and any shares move with it.

Managing Tools

The Tools landing page shows your tools as cards, grouped into Your Tools, Shared with you, your organization's tools, and Third Loop Tools. From there you can:

• Open a tool by clicking its card.
• Search with the search box, which matches on name and description.
• Filter to a single ownership group using the section toggle above the grid.
• Edit, Share, or Delete a tool you own from its ⋯ menu. Deleting asks for confirmation.
• Leave a tool shared with you from its ⋯ menu.

Sharing grants other users Edit or View access, and can also be done from the Share button in the editor header, which is where you remove existing shares.

Organization and Third Loop tools are read-only. Tools marked Proprietary show only their description — their schema and code are deliberately hidden — but you can still attach them to your own agents.

Tags

Tools carry tags in the underlying data, but the tag editor is not currently shown in the UI — nothing consumes tags for search or filtering yet. Tags on existing tools are preserved.