HuntX
Official# HuntX
Personal MCP (Model Context Protocol) server giving Claude Code (or any
MCP-compatible client) direct tool-access to security-testing
primitives for bug bounty hunting: recon querying/triggering, HTTP
request replay, IDOR/BOLA fuzzing, SQLi/XSS/SSTI/SSRF detection, JWT/OAuth
testing, secrets scanning, misconfiguration/exposure checks, and
persistent hunt memory with confidence-scored findings across sessions.
Every finding gets a confidence level (`confirmed`/`likely`/
`needs_review`) and nothing auto-escalates without explicit human
review — see `AGENTS.md` for the full design principles.
## Requirements
- Python 3.12+
- [uv](https://github.com/astral-sh/uv)
### Optional external tools
Most adapters work standalone. A few shell out to external CLI tools —
install these only if you need the corresponding adapter:
| Adapter | Needs |
|---|---|
| `secrets_scan` | `gitleaks`, `trufflehog` on PATH |
| `nuclei_scanner` | `nuclei` on PATH (with templates: `nuclei -update-templates`) |
| `recon_bridge` / `recon_trigger` | [reconFTW](https://github.com/six2dez/reconftw) installed — `recon_bridge` reads its `Recon/<domain>/` output, `recon_trigger` runs it directly |
## Setup
```bash
uv sync
uv run huntx
```
Then add HuntX as an MCP server in your Claude Code config, pointing at
this project's `huntx` entrypoint.
## Configuration (environment variables)
| Variable | Default | Purpose |
|---|---|---|
| `HUNTX_DB_PATH` | `~/.huntx/memory.db` | SQLite database for request history and findings |
| `HUNTX_OOB_SERVER` | public interactsh pool (`oast.pro`) | Interactsh server for `ssrf_scanner`'s out-of-band detection. **Set this to a self-hosted [interactsh-server](https://github.com/projectdiscovery/interactsh) instance before testing anything sensitive** — the public pool's "zero logging" claim is unaudited, and any data a target leaks via SSRF transits that third-party server. Without this set, `ssrf_scan` logs a warning and flags `oob_is_public_pool: true` in its results so it's never silent. |
TDQS
Scored across 38 tools
Each tool has a clearly distinct purpose: HTTP logging/replay, IDOR fuzzing (with three variants for different contexts), recon data retrieval, vulnerability scans (XSS, SQLi, SSRF, SSTI, CORS, etc.), and triage management. Even similar functions like idor_fuzz vs idor_fuzz_url differ by input source, and subdomain_takeover_check vs batch differ by scope. No two tools appear to do the same thing.
Tool names follow predictable group-specific patterns (http_*, recon_*, triage_*, auth_test_*), but there is inconsistency across groups: some use verb_noun (scan_secrets, http_replay) while others use noun_verb (cors_scan, sqli_scan). Overall snake_case and readable, but not a single uniform convention.
With 38 tools, the server is substantially oversized. While each tool is justified within its subdomain, the total count far exceeds the 25+ threshold for 'too many'. The breadth suggests a monolithic design that could be decomposed into smaller, focused servers.
The server covers the full security testing lifecycle: recon (endpoints, params, IPs, subdomains, trigger), scanning (all major OWASP categories), HTTP request interception and replay, auth vulnerability testing (JWT, OAuth), and finding triage with create/read/update operations. No obvious dead ends or missing critical capabilities for the stated purpose.