HuntX
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| auth_test_jwtA | Test JWT for manipulation vulnerabilities (alg:none, RS256→HS256, kid injection). Runs deterministic checks against a JWT-protected endpoint:
|
| auth_test_oauth_redirectB | Test OAuth redirect_uri for open redirect and CSRF vulnerabilities. Tests multiple redirect_uri bypass techniques:
|
| cors_scanB | Scan for CORS misconfigurations. Tests with various Origin headers to detect reflected origins, null origin acceptance, and wildcard with credentials. |
| error_page_scanA | Scan for verbose error page disclosure. Triggers errors with bad input and checks for stack traces, debug info, and internal path disclosure. |
| http_sendB | Send an HTTP request and log it for later querying. |
| http_replayA | Replay a previously logged request with optional modifications. |
| http_searchA | Search past HTTP requests by full-text query. Searches across URL, request body, and response body. |
| http_listC | List recent logged HTTP requests. |
| http_getA | Get details of a single logged HTTP request. |
| idor_fuzzA | Fuzz a logged HTTP request by swapping ID parameters. Loads the request from memory, identifies ID-like parameters (numeric IDs, UUIDs) in the URL and body, generates or uses provided candidate IDs, sends mutated requests, and diffs responses to detect access control bypass (IDOR/BOLA). |
| idor_fuzz_urlA | Fuzz a URL directly for IDOR/BOLA without needing a logged request. Identifies ID parameters in the URL and body, mutates them, and compares responses to detect access control issues. |
| idor_fuzz_rolesA | Test the same resource with different auth contexts (role-based BOLA). Sends the same request with each auth context and compares responses to detect cross-role access control bypass. This is the vertical BOLA / privilege-escalation test: can a lower- privilege user access a higher-privilege resource? |
| misconfig_scanB | Scan for common misconfigurations. Checks for exposed .git directories, .env files, API keys in responses, debug endpoints, swagger docs, and other sensitive paths. |
| nuclei_scanB | Scan a URL using projectdiscovery/nuclei with automatic-scan. Wraps nuclei -u -as -json and parses output into findings. Requires nuclei installed and in PATH. |
| open_redirect_scanA | Scan for open redirect vulnerabilities. Injects redirect payloads into URL parameters and checks if the server redirects to an external domain. |
| race_testA | Test for race conditions by sending concurrent requests. Sends N concurrent requests to the same URL and compares responses for differential behavior (different status codes, response lengths, or success/failure) — a strong indicator of TOCTOU race conditions. |
| recon_list_targetsA | List all domains with reconFTW output data on disk. Returns domain names that have a Recon// directory under the reconFTW output root. |
| recon_subdomainsB | Get subdomains discovered for a target domain. |
| recon_web_targetsB | Get live web URLs (HTTP endpoints) for a target domain. |
| recon_endpointsB | Get extracted endpoints/URLs for a domain, with optional filtering. |
| recon_paramsA | Get discovered query parameters for a target domain. |
| recon_ipsB | Get IP addresses associated with a target domain. |
| recon_domain_summaryA | Get a summary of all recon data available for a domain. |
| recon_triggerA | Run a reconFTW scan against a domain. Subprocess-wraps reconftw.sh (the same tool recon_bridge reads output from) — does not reimplement any recon logic. Writes to reconFTW's own Recon// layout, so recon_bridge's tools can query the results immediately after this completes. |
| scan_secretsA | Scan a filesystem path for leaked secrets. Uses gitleaks (default) or trufflehog to scan a directory or file for hardcoded secrets, API keys, tokens, and credentials. |
| scan_git_secretsA | Scan a git repository for leaked secrets in commit history. Uses trufflehog to scan git history for credentials, API keys, and other secrets. |
| security_headers_scanA | Scan for missing or misconfigured security headers. Checks for CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, COOP, CORP, COEP, and other security headers. |
| sqli_scanA | Probe a request's query/body parameters for SQL injection. Tries a small, high-signal payload set: error-based (single quote/paren breakouts, checked against real DB error signatures — flags "confirmed" only on an unambiguous match) and boolean-based blind (TRUE/FALSE condition pair, flags "likely" on a significant response diff — needs human review, a diff alone doesn't prove SQLi). |
| ssrf_scanA | Scan a URL for SSRF via out-of-band interaction (interactsh). Injects unique OOB domains into request parameters. If the target server fetches our domain, SSRF is confirmed with near- zero false positives. Uses the interactsh protocol for OOB detection with RSA-2048 + AES-CFB encryption. |
| ssti_scanA | Scan a URL for Server-Side Template Injection (SSTI). Injects math-evaluation probes ({{77}}, ${77}, etc.) into request parameters and checks if the result (49) appears in the response. Also detects known template engine error signatures. |
| subdomain_takeover_checkA | Check a subdomain for takeover opportunities. Checks for dangling CNAME records pointing to unclaimed external services (S3, GitHub Pages, Heroku, etc.). |
| subdomain_takeover_check_batchB | Check multiple subdomains for takeover opportunities. |
| triage_listA | List findings with optional filters. |
| triage_getB | Get a single finding by ID. |
| triage_updateB | Update a finding's status. |
| triage_summaryA | Get a per-target summary of all findings. Returns counts by status, vuln_class, and confidence. |
| triage_saveB | Manually save a finding for triage. |
| xss_scanA | Probe a request's query/body parameters for reflected XSS. Injects a unique marker wrapped in an HTML-breaking payload per parameter and statically analyzes the response: verbatim unescaped reflection is "confirmed", reflected-but-transformed is "likely" (needs human/browser verification), properly encoded or not-reflected-at-all produces no finding at all. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.