HuntX
OfficialRelated Servers
Alternatives to HuntX
No user-submitted related servers found.
Related Servers
- AlicenseBqualityDmaintenanceAn MCP server for authorized bug bounty work that enforces an evidence-driven workflow with session management, preflight checks, surface discovery, and verified scanning.12MIT
- AlicenseNot gradedqualityCmaintenanceEnables automated bug bounty hunting and security research with tools for reconnaissance, web vulnerability scanning, API testing, binary analysis, and mobile app analysis through an MCP interface.MIT
- FlicenseNot gradedqualityDmaintenanceA comprehensive MCP server for automated bug bounty hunting and security reconnaissance, featuring over 28 specialized tools for subdomain discovery, vulnerability scanning, and traffic analysis. It integrates automated scope validation and professional reporting across multiple platforms like HackerOne and Bugcrowd to streamline security testing.5-
- AlicenseNot gradedqualityCmaintenanceA local Python MCP server for safe, human-led bug bounty recon, providing lightweight helpers for scope checks, headers, robots.txt, sitemap.xml, JavaScript URL collection, endpoint extraction, URL deduplication, evidence notes, and manual test planning.MIT
- AlicenseAqualityBmaintenanceMCP server for offensive-security tooling, enabling AI agents to run reconnaissance, CVE intelligence, JavaScript analysis, HTTP probing, and port scanning against authorized targets.10MIT
- AlicenseAqualityBmaintenanceAn MCP server that provides passive and low-impact active reconnaissance tools for authorized bug bounty and security assessments, enabling LLMs to perform structured recon and generate reports.11Apache 2.0
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.