Tool Builder

The Tool Builder is your organization's AI software engineer for custom tools. You describe the tool you need in plain English, and the Tool Builder writes the Python, runs it through a five-phase verification pipeline, and saves the finished tool to your Tool Library.

Every tool it creates is real Python — not a template, not a wrapper. The code is compiled, schema-validated, executed with test input, and security-scanned before it's saved. You never run unverified code.

When to Use It

Reach for the Tool Builder when you want to:

• Create a new custom tool — call an API, transform data, parse a file format, run a domain-specific computation.
• Modify an existing custom tool — tweak parameters, add a credential, adjust the logic.
• Understand what a tool actually does — the Tool Builder can pull a tool's source code, parameters, and credentials and explain them to you.
• Verify a tool without saving — run the five-phase pipeline on a draft to see if it compiles, validates, and executes before committing.

It is not the right place to:

• Package multiple tools into an installable Skill — that's the Integration Builder.
• Build an App, a channel, or an adapter — those live in a separate system.
• Publish a tool to the marketplace — the Tool Builder saves to your Tool Library; listing and publishing go through the Integration Builder.
• Modify a library tool — library tools ship with ORQO and are read-only. The Tool Builder tells you plainly when you hit one.

How to Open It

The Tool Builder lives in the chat drawer on Developer Portal pages. Click the chat handle at the right edge of the screen (or press ⌘J) and the drawer opens directly into the Tool Builder — there are no tabs to choose.

ORQO picks the right specialist based on the page you're on. Developer Portal pages open the Tool Builder; project pages open the Workflow Assistant; Settings → Integrations / MCP / Credentials / Apps open Integration Builder; the rest of the app opens Doorkeeper. See How the chat drawer chooses its agent for the full mapping.

If you're mid-conversation with another agent and you navigate into the Developer Portal, the drawer keeps your current conversation and shows a banner — "This page is for Tool Builder." — with Switch and Stay buttons. Switch drops your current conversation from the drawer and shows Tool Builder's recent conversations list — pick one, or start fresh with the + button. Stay dismisses the banner and keeps your current conversation open.

The Tool Builder is also reached indirectly. The Integration Builder calls the Tool Builder whenever a new Python tool is part of an integration; the Workflow Assistant does not call the Tool Builder directly — it routes capability requests through Integration Builder, which then calls the Tool Builder when Python is the right answer.

The Code Viewer

While you talk to the Tool Builder, a code viewer opens in your main content area. It shows the tool's name, description, parameters, source code (syntax-highlighted), and verification results live as the Tool Builder works. You see the code before it's saved, the test output when it runs, and a big red badge if anything fails.

Status badges on the viewer:

Badge	Meaning
Draft	Code exists but hasn't been verified yet
Verified	Passed the full five-phase verification pipeline
Saved	Persisted to your Tool Library
Failed	Verification hit an error
Requires Runtime	Uses restricted operations and needs a runtime to execute

The code viewer persists across messages, so you can scroll the chat and still see what's being built.

The Workflow

The Tool Builder follows a consistent protocol for every tool it creates or modifies. You'll see it work through the steps:

1. Understand

It clarifies what the tool should do, what inputs it needs, whether it needs credentials, and whether it calls out to an external API. Expect a short back-and-forth — "What should happen if the API returns a 404? Retry, or fail the tool?" — before code gets written.

2. Check what already exists

Before writing anything new, it lists the existing tools in your organization to avoid name collisions and to reference similar patterns. If a tool that does what you want already exists, it says so and stops.

3. Check credentials

If the tool needs API keys, it checks what's already configured in your organization. If a required credential is missing, it tells you exactly what to add — credential key, category, and where the secret comes from — and waits for you to add it in Settings → Credentials before continuing.

4. Read conventions (if needed)

The Tool Builder has an on-demand reference for Python tool conventions: the execute() signature, how to access credentials at runtime, parameter types, imports, and examples. It pulls this when writing non-trivial tools or when refreshing its knowledge.

5. Write the code

It opens the code viewer and generates the Python source: the execute() method, parameter definitions, a test input that exercises every required parameter, and an optional log message template.

6. Verify

It runs the tool through the engine's five-phase verification pipeline:

Phase	What it checks
Build	Compile the Python source — catches syntax errors
Schema	Generate the JSON schema from parameters — catches type errors
Instantiate	Create an instance with test values — catches validation errors
Execute	Run the tool against test input with a 5-second timeout
Log preview	Interpolate the log message template

The code viewer updates with the verification result: errors in red, test output in monospace, security scan findings, and a log message preview.

7. Fix and re-verify

If verification fails, the Tool Builder reads the error, fixes the code, and runs verification again. It iterates until the pipeline passes. If it's stuck, it tells you what's going wrong instead of spinning forever.

8. Save

Once verification passes, the Tool Builder runs a mandatory security scan and then saves the tool to your Tool Library. The scan looks for restricted operations (subprocess, os.system, shutil, socket, os.popen) and, if any are found, automatically marks the tool as requires runtime so it can only execute inside a runtime environment. This flag is then locked — it cannot be disabled without re-writing the code.

If the security scanner is unreachable, save fails safe: unscanned code never gets saved.

9. Report

It summarizes what the tool does, what parameters it takes, which credentials it uses, and whether it requires a runtime. It points you to where the tool can now be assigned — on a stage assignment in any workflow in the organization.

What the Tool Builder Can Do

Here is the full set of capabilities available today.

Inspect

• List existing tools in your organization, with flags for library tools and runtime requirements, plus which credentials each tool needs.
• Pull full details of any specific tool — source code, parameters, credentials, flags.
• List available credentials in your organization, with configuration status.
• Read the Python tool conventions — on-demand reference for writing correct tool code.

Build

• Write Python tools from a description — complete source code with parameters, test input, and log templates.
• Verify a tool through the five-phase pipeline without saving.
• Save a verified tool to the Tool Library, with automatic security scanning and credential wiring.
• Modify an existing tool — pull its current source, adjust, re-verify, and save. Saving updates the existing record by matching on name; library tools are rejected.

UX

• Live code viewer showing the tool's source, parameters, verification results, and security scan in real time.
• Auto-navigate to the tools or credentials settings when a result is ready to review.
• Maintain a to-do list for multi-step work.
• Ask questions when it needs input, with a clear signal that the turn has ended and it's waiting for you.

Scope — What It Won't Do

The Tool Builder has a narrow mandate. It creates exactly one Python tool per request — nothing else. If you ask it for something outside that scope, it tells you plainly which agent you actually need.

• It does not bundle tools into Skills. Skills are created by the Integration Builder.
• It does not create Apps, channels, or adapters. Those live in a separate system and are not built through a chat agent.
• It does not create marketplace listings. Publishing a Skill to the organization catalog or the public marketplace is handled by the Integration Builder.
• It does not modify library tools. Library tools ship sealed; the Tool Builder detects this and tells you.
• It does not create credentials. When a new API key is needed, you add it in Settings → Credentials before the Tool Builder proceeds.
• It does not silently downgrade a request. If you ask for a "Stripe skill," it will not quietly create a single Stripe tool and pretend that's a skill. It tells you to use the Integration Builder instead.

This narrow mandate is on purpose. The Tool Builder is often called by the Integration Builder, which relies on its faithful reporting — saying "I created the tool fetch_stripe_payment_intent" when that's actually what happened, and nothing more.

Security

Every saved tool goes through a mandatory security scan. The scan:

• Detects restricted operations — subprocess, os.system, shutil, socket, os.popen.
• Flags runtime requirements — tools using restricted operations can only run inside a runtime.
• Locks the runtime flag — once a tool is marked as requiring a runtime, the flag cannot be disabled without re-writing the code.
• Fails safe — if the scanner is unreachable, saving is blocked.

Library tools (the ones that ship with ORQO) are sealed at the database level; the Tool Builder cannot modify them, and neither can anything else.

Privacy

The Tool Builder never shows database IDs in conversation. Tools and credentials are always referred to by name.

Screenshots

note

Screenshots of the Tool Builder chat drawer, the live code viewer, and the verification output are pending. See the documentation status file for the outstanding screenshot list.

Related

• Integration Builder AI — calls the Tool Builder when adding new platforms to your organization, and is the path the Workflow Assistant uses when a workflow needs a new Python tool
• Workflow Assistant — the project-level agent that requests new tools through Integration Builder rather than calling the Tool Builder directly
• Doorkeeper AI — the org-level front desk
• Tools reference — how custom tools, library tools, and MCP tools fit together
• Runtimes — execution environments for tools that need filesystem or shell access
• Credentials — how API keys are stored and injected into tools
• Building a Skill — if you want to hand-craft a Skill without the builder