Tools (External Tool Registry)

The Tools view is a registry of external command-line tools Hugin can invoke. Define a tool once (path, args, expected output format), and use it from anywhere — Workflows, Macros, Repeater context menus, MCP, Lua extensions.

This is how Hugin integrates with anything outside its own binary: nuclei, ffuf, sqlmap, your own private toolkit, anything that accepts arguments and prints output.

🔗Built-in Tools

Hugin auto-detects and registers common tools if found on PATH:

  • nuclei — fast vulnerability scanner
  • subfinder / amass — subdomain enumeration
  • ffuf / wfuzz — HTTP fuzzers (separate from Hugin’s FFuzzer)
  • httpx — HTTP probing
  • gowitness / aquatone — visual recon
  • sqlmap — SQL injection toolkit
  • gobuster / dirsearch — content discovery
  • mitmproxy — TLS inspection (when you need a different proxy alongside Hugin)

For each detected tool, Hugin records the binary path, version (from --version), and a default arg template.

🔗Adding a Custom Tool

+ Add Tool:

  • Name — display name + identifier
  • Binary path — full path to the executable
  • Arg template — command-line args with {{template}} placeholders (e.g., {{target}}, {{wordlist}})
  • Working directory (optional)
  • Environment variables (optional)
  • Output format — text / json / xml / sarif / custom-parser
  • Health-check command — e.g., --version; runs to verify the tool is reachable
  • Permissions required — execution of arbitrary tools is permission-gated

🔗Using Tools

🔗From Workflows

Add a RunShell action node (or use a custom Tool node) that invokes a registered tool. The flow context (URL, body, etc.) is passed via stdin or args. Tool stdout is captured and fed to downstream nodes.

🔗From Right-Click

Right-click any flow → Run Tool → pick from the registry. The tool runs with the flow’s URL/host/body as args, output streams into the bottom panel.

🔗From Repeater

The Repeater detail pane has a Tools menu that lists registered tools. Pick one to pipe the current request to it (e.g., send the request as raw HTTP to sqlmap’s -r flag).

🔗From MCP / Lua

tools_registry action:"execute" name:"nuclei" args:"-u {{target}}"

Lua:

local result = hugin.exec_tool("nuclei", {target = "https://example.com"})

🔗Health Checks

The Health column shows whether each tool is reachable:

  • Healthy — last health-check succeeded
  • Stale — not checked recently (> 1 hour)
  • Failed — last check failed (binary missing, command errored)

Manual recheck per tool. Bulk recheck via the Refresh All button.

🔗Output Capture

Tool stdout/stderr is captured into the output_store SQLite table with FTS5 search. Past runs are queryable from:

  • The Tools view → click any tool → Run History
  • The output_store MCP tool
  • Workflow / Macro context (downstream nodes can read the output)

🔗Tool-Specific Wrappers

For frequently-used tools, build a wrapper workflow that pre-fills common args and parses output into structured findings:

  • Nuclei → Findings workflow: invoke nuclei, parse SARIF output, auto-create Hugin findings with severity mapping
  • sqlmap → Findings workflow: invoke sqlmap, parse --results output, attach evidence

🔗Permissions

Arbitrary external tool execution is permission-gated. Settings → Custom Code → “Allow external tool execution” must be enabled. Each tool can be individually allowed/denied. Audit log captures every invocation.

🔗MCP

The tools_registry MCP tool exposes:

  • list — all registered tools with health status
  • get — one tool by name
  • health — health-check one tool
  • health_all — health-check every registered tool
  • execute — invoke a tool with args

Adding / removing tools from the registry is done through the UI (or by editing the registry storage directly).

🔗Best Practices

  • Don’t replicate. If a tool already exists in Hugin (FFuzzer vs ffuf), prefer the built-in for tighter integration.
  • Tag tools. Use the tag field to group by category (recon / scan / exploit) for cleaner picker menus.
  • Pin versions. When possible, register the absolute path to a specific binary version, not the system PATH lookup, so reproducibility holds across upgrades.