Tools
Tools give agents the ability to act — search the web, query databases, call APIs, execute code, and more. ORQO has three distinct tool layers, each serving a different purpose.
The Three Tool Layers
Layer 1: Internal Tools (System)
Every agent automatically has access to a set of internal tools provided by the engine. These are not visible in the UI and cannot be modified — they're the fundamental capabilities an agent needs to function within a team:
- agent_message — communicate with other agents in the team
- share_result — broadcast results to teammates
- dispatch — route tasks to other agents
You don't configure these. They're always available.
Layer 2: Project Tools (ToolFactory)
This is ORQO's custom tool system. You define tools directly in the UI as Python scripts that conform to the engine's Pydantic-based ToolFactory interface.
Each tool definition includes:
| Field | Description |
|---|---|
| Name | Tool name the LLM sees and calls |
| Description | What the tool does — guides the LLM on when to use it |
| Parameters | Typed input parameters (string, integer, number, boolean, array) with descriptions |
| Source Code | Python function body — the actual implementation |
| Credentials | API keys the tool needs (injected automatically at runtime) |
| Runtime | Sandboxed execution environment (required for tools that run code) |
When a workflow starts, the engine's DynamicToolFactory compiles these definitions into full Pydantic AgentTool classes at runtime — with type validation, credential injection, and security scanning.
This is the primary way to build project-specific tools. Unlike MCP servers, you don't need to deploy a separate service. Write the Python, define the parameters, and the tool is ready.
Layer 3: MCP Tools (External)
MCP (Model Context Protocol) servers expose tools over a standardized protocol. Connect an MCP server in Settings → MCP Servers, and ORQO discovers its tools automatically.
MCP tools can also come through Apps — when you register an App, ORQO connects to its underlying MCP server and fetches all available tools. In both cases (standalone MCP server or App-wrapped), tools are auto-discovered and made assignable to agents via Skills.
See MCP Servers for connection details and Integrations for how Apps wrap MCP servers.
Tools and Long-Term Memory
Every tool — whether a Project Tool or an MCP tool — has two flags that connect it to the Long-Term Memory system:
| Flag | What it does |
|---|---|
| Enriches Knowledge Graph | Tool results are fed into the async enrichment pipeline. The knowledge graph grows passively every time this tool runs. |
| Requires Extraction | Strip ads, navigation, and boilerplate before classification. Enable this for tools that return raw web content. |
When an MCP server or App is registered, ORQO automatically analyzes each discovered tool and sets these flags based on a platform-wide registry of known tools. A web search tool gets both flags enabled (its output is knowledge-worthy but needs cleaning). A send_slack_message tool gets neither (its output isn't worth storing).
You can override these flags manually per tool — but the defaults are usually right.
This means your knowledge graph grows passively with every workflow execution, without agents needing to explicitly store anything. A research agent runs a web search, and the useful content from that search automatically flows through the Knowledge Curator, gets classified by the three-pass pipeline, and becomes part of the navigable knowledge graph.
Runtimes Are Invisible to Agents
Some tools need a sandboxed execution environment — a Python container, a headless browser, a code interpreter. In other platforms, this is the agent's problem. In ORQO, agents don't know or care about runtimes.
When an agent calls a tool, it gets back a result. Whether that tool ran locally, on a remote MCP server, or inside a sandboxed Docker container is entirely managed by the platform. The agent's experience is always the same: call the tool, get the result.
Runtimes are configured at the Skill or Tool Definition level by the person building the workflow — not by the agent at execution time.
Assigning Tools to Agents
Tools reach agents through two paths:
-
Skills — bundle tools with credentials into a reusable package. Assign a Skill to an agent in the Team Builder, and the agent gets all bundled tools in every stage. Think of skills as the agent's permanent expertise.
-
Stage assignments — assign specific tools to an agent for one particular stage. This keeps agents focused and avoids loading them with tools they don't need for every task.
See Skills for the full explanation of skills vs. stage tools.