> ## Documentation Index
> Fetch the complete documentation index at: https://trickest.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tools

> Tool nodes as pre-packaged command-line programs in workflows.

## Overview

On this page you will learn what tool nodes are in Trickest, how they work, and how they relate to other building blocks and the Library.

## What is a Tool Node

A tool node is a **containerized environment** that runs a pre-packaged command-line tool. Each tool has its own Docker image with the tool and its dependencies already installed. You do not download or install the tool yourself. Tool nodes accept **inputs** (parameters) such as string, file, folder, and boolean values, and produce **file** and **folder** outputs. The platform builds the execution command from the inputs you configure, so you work with human-readable parameters instead of raw command-line flags.

## Why Tools Exist

Tools are the most common node type in workflows. They run specific security processes and tasks (e.g. scanning, fuzzing, enumeration) in a standardized way. Trickest removes the usual friction: no local install, no dependency or OS mismatch. You choose a tool from the [Library](/docs/library/introduction) or import your own, configure its parameters via node inputs, and the platform runs it in a repeatable containerized environment. Outputs can feed the next node in the workflow.

## How It Works

Each tool defines a set of parameters (required and optional). These parameters become **node inputs**. You provide values by connecting outputs from other nodes (e.g. a file from a previous tool or script) or by setting them explicitly (e.g. a target URL as a string, a wordlist as a file). The platform generates the final command from those inputs and executes it inside the tool’s container. The tool writes its results to the node’s output; file and folder outputs are then available to downstream nodes. Tools are designed to be chained: one tool’s output often becomes another tool’s input.

## How It Relates

* **Building blocks:** Tools are one of the three node types (scripts, tools, modules). See [Introduction](/docs/key-concepts/building-blocks/introduction).
* **Scripts:** Scripts are code you write or reuse; tools are pre-packaged CLI programs. Both have defined inputs and outputs and can be chained. Scripts are often used to parse or transform tool output for the next tool.
* **Modules:** Modules are reusable subgraphs of nodes; a tool is a single node. You can use tool nodes inside a module.
* **Workflows:** Tools run as nodes in a workflow. They receive data from upstream nodes and pass results downstream. See [Workflows](/docs/key-concepts/workflows).

## Common Patterns

* Chaining tools so the file or folder output of one tool (e.g. subdomain enumeration) is the input of another (e.g. port scanning or HTTP probing)
* Using string inputs for targets, URLs, or options and file inputs for wordlists, configs, or target lists
* Combining tools with script nodes to parse, filter, or reshape output between steps
* Reusing tools from the Library and configuring only the parameters your workflow needs

## Next Steps

<CardGroup cols={2}>
  <Card title="Building and Debugging a Workflow" icon="code" href="/docs/using-the-app/workflow-and-executions/building-and-debugging-a-workflow">
    Add tool nodes, configure parameters, and connect inputs and outputs.
  </Card>

  <Card title="Using Workflows From the Library" icon="book" href="/docs/using-the-app/workflow-and-executions/using-workflows-from-the-library">
    Copy workflows and tools from the Library into your workspace.
  </Card>
</CardGroup>