Loading ToolBench
MCP server to assist AI in offensive security testing of web applications
ShyHurricane has mixed quality across its 5 tools. All tools have descriptions and input schemas present, but there are significant gaps in parameter descriptions, schema completeness, and error handling guidance. The naming is generally clear and action-oriented (find_*, index_*), but parameter descriptions lack specificity around formats, constraints, and when to use each tool. Output schemas are not documented in the provided source. The server appears designed for offensive security testing with appropriate READ_ONLY and WRITE risk classifications, but lacks idempotency guarantees and recovery guidance for failures.
Query indexed resources for a list of domains that have resources that can be researched. Invoke this tool when the user asks about websites that have been scanned, spidered or indexed.
Query indexed resources for a list of hosts for the given domain. Invoke this tool when the user asks about websites that have been scanned, spidered or indexed.
Query indexed resources for a list of network locations, i.e. host:port, for a given domain. Invoke this tool when the user asks about websites that have been scanned, spidered or indexed.
Query indexed resources for a list of URLs for the given host or domain. Invoke this tool when the user asks for page URLs that have been scanned, spidered or indexed. Invoke this tool when a list of URLs for a website is needed for analysis.
Index an HTTP URL to allow for further analysis and return the context, response code, response headers. Invoke this tool when the user needs the content of one specific URL. If the content type is binary or over the content_length_limit, content will not be returned. If follow_redirects is true, redirects will be followed and the result is the destination of the redirect.
Output schemas not documented. No evidence in source of response field definitions for any of the 5 tools. LLMs cannot predict what fields to expect, breaking tool composition and downstream planning.
Parameter descriptions lack actionable constraints. 'query' in find_domains says 'contains operator' but doesn't specify case sensitivity, partial vs full match, or when query is empty vs null. 'host_query' in find_urls lacks any example of valid format (domain, domain.com, *.example.com?).
index_http_url parameter 'additional_hosts' type is 'object' with no schema details. LLMs cannot infer the structure, is it {'host': '1.2.3.4'} or {'host': {'ip': '1.2.3.4'}}? No validation rules stated.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
No pagination or result limit guidance for find_* tools. find_domains, find_hosts, find_netloc accept no limit parameter. If a domain has 10,000 hosts, response could explode context window. No 'total_count' or 'next_cursor' documented.
Error handling not described. No guidance on what happens when domain_query matches zero hosts, when URL is unreachable, when content_length_limit is exceeded. LLMs have no recovery path.
index_http_url has WRITE risk but no dry-run, confirmation, or idempotency guarantee. Calling it twice with identical params may create duplicate indexed entries or cause side effects. No guidance on retry safety.
Tool composition risk: find_urls returns URLs but index_http_url requires 'url' parameter, no evidence these are compatible field names or that find_urls response includes the exact URL format index_http_url expects.
Parameter 'method' in index_http_url defaults to GET but description doesn't explain when to use POST/PUT/DELETE or whether request_body is required for non-GET methods.