Rqwstr is an AI-native HTTP security testing toolkit that provides AI agents with low-level control over HTTP/1.1 and HTTP/2 for offensive web security testing. Key capabilities include:
HTTP Traffic Generation & Manipulation: Send raw HTTP/1.1 (send) and HTTP/2 (send_h2) requests with advanced options like header smuggling, content-length overrides, connection pinning, and pause attacks. Import raw requests from Burp or HAR (import), export stored requests to various formats (export), and fetch/search stored requests and responses.
Advanced Attack Vectors: Perform Burp Intruder-style fuzzing (intruder) with multiple attack types and payload management. Test for race conditions (race) with burst, single-packet, or staggered timing. Execute multi-step request chains (chain) with variable extraction, conditional logic, and automatic cookie forwarding. Send parallel requests (parallel) for throughput attacks or synchronized testing.
Out-of-Band Interaction Detection: Detect blind vulnerabilities via OOB interactions (oob) using Interactsh integration.
Hunt & Session Management: Create and manage named hunts (hunt) with targets, proxies, and default settings (SQLite-backed). Manage scope rules (scope) for testing, cookie jars (session), and variable profiles (profile).
Utilities: Encode/decode payloads (encode) using various schemes, and access built-in agent guidance (rqwstr_docs).
AI-native HTTP security testing toolkit, shipped as an MCP server. It gives an AI agent low-level control over HTTP/1.1 and HTTP/2 — raw framing, connection pinning, intruder-style fuzzing, request racing, OOB detection, and multi-step chains — on its own Go engine, rather than wrapping a high-level HTTP client.
This repository hosts the release binaries and Claude Desktop .mcpb bundles. The source is proprietary. Docs and sign-up: rqwstr.com.
Real v1.2.0 MCP session against a synthetic loopback fixture: one request, response-side
filtering, stored search, and named retrieval. The capture and renderer are reproducible
from demo/ with an activated free or Pro license; no live target is
involved.
Download the .mcpb for your platform from the latest release and double-click it to add rqwstr as a Claude Desktop extension.
macOS — Apple silicon (darwin_arm64) or Intel (darwin_amd64)
Linux — linux_amd64 or linux_arm64
Windows — windows_amd64
Download the binary for your platform from the latest release, then point your MCP client at it:
{
"mcpServers": {
"rqwstr": {
"command": "rqwstr",
"args": ["serve"]
}
}
}rqwstr serve runs the MCP server on stdio.
Related MCP server: pentestMCP
17 HTTP tools:
send · send_h2 · fetch · intruder · race · chain · oob · parallel ·
scope · session · encode · export · save · search · hunt · profile ·
import
The HTTP tools cover:
Traffic — send (HTTP/1.1), send_h2 (HTTP/2), fetch, import (Burp / HAR), export (curl / python / requests)
Hunt lifecycle — hunt, scope, save, search, session, profile
Attacks — intruder (sniper, battering ram, pitchfork, cluster bomb), race (single-packet), chain, parallel
OOB — oob with Interactsh integration
Encoding — encode (URL, base64, JWT, and more)
Agents discover workflows through the rqwstr_docs tool. Per-hunt state lives in SQLite. The free tier is the core toolset; a Pro tier unlocks the heavier offensive tools.
Each release includes checksums.txt. Verify before running:
# Linux
sha256sum -c checksums.txt
# macOS
shasum -a 256 -c checksums.txtrqwstr's data collection, usage, storage, sharing, retention, and contact practices are documented in the Privacy Policy.
Proprietary. © Kjøpstad IT. See rqwstr.com for terms.
Execute multi-step request chain with variable extraction between steps. Each extract value is a PLAIN STRING pattern (body regex / cookie:name / header:Name:regex), never a nested object like {"type":"json",...}. See rqwstr_docs(topic="chain") for patterns. Preferred path for authenticated flows: forward_cookies (default true) auto-forwards Set-Cookie between steps — see rqwstr_docs(topic="cookies").
| Name | Required | Description | Default |
|---|---|---|---|
| steps | Yes | Ordered list of request steps | |
| timeout_ms | No | Per-step timeout in milliseconds (default 30000) | |
| stop_on_error | No | Stop chain on non-2xx response | |
| forward_cookies | No | Auto-forward Set-Cookie headers between steps (default true) | |
| single_connection | No | Reuse same TCP connection across all steps (for connection-state attacks) | |
| stop_on_missing_var | No | Stop if {{VAR}} references undefined variable | |
| stop_on_extract_fail | No | Stop if extraction finds no match |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It details extraction pattern formats, default forward_cookies behavior, first-document-wins for SSE, and references docs for patterns. However, it omits error handling nuances and rate limit/authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose but includes redundant explanations (e.g., extract patterns repeated). It could be more concise without losing key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity (multi-step chain with variable extraction), the description does not explain the return value or response format. With no output schema, the agent remains uninformed about what the tool yields, a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds critical semantics for the extract parameter: it explicitly prohibits nested objects, explains pattern forms, and clarifies edge cases like SSE unwrapping. This goes beyond the schema's description of 'plain string pattern'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a multi-step request chain with variable extraction, distinguishing it from single-request siblings like fetch and send. It uses specific verb 'Execute' and resource 'multi-step request chain', and the sibling list confirms its uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use forward_cookies for authenticated flows but does not explicitly contrast with alternatives or state when not to use the tool. No guidance on choosing between chain and other tools like race or parallel is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encode or decode payloads for injection testing. Encodings: url, double, html, base64, unicode, hex. Chain multiple left-to-right. See rqwstr_docs(topic="encoding").
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | encode (default) or decode | |
| chain | No | Chain of encodings applied left-to-right. Example: [url base64] | |
| value | Yes | The value to encode or decode | |
| encoding | No | Single encoding type: url double html base64 unicode hex |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It discloses the ability to chain encodings and lists supported types, but omits behavioral traits such as error handling, side effects, or requirements (e.g., auth, rate limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with a reference to docs. Every word is purposeful, front-loaded with the primary action, and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description covers the basics (purpose, encodings, chaining). However, it lacks details on edge cases, error states, or expected return behavior, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context by listing encoding types and explaining chaining, but does not significantly augment the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool encodes or decodes payloads for injection testing, specifying the verb and resource. While it distinguishes from siblings by context (injection testing), it doesn't explicitly differentiate from similar tools like 'chain' which also deals with encoding chains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for injection testing and suggests consulting rqwstr_docs for more details, but does not provide explicit when-to-use or when-not-to-use guidance compared to sibling tools like 'chain' or 'intruder'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a stored request to curl, python, go, httpie, har, or raw HTTP format. See rqwstr_docs(topic="export") for format options.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Request UUID to export | |
| name | No | Saved name of the request to export | |
| format | Yes | Export format: curl httpie python go har raw |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects, authorization needs, or whether it modifies state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no redundancy, front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers basic purpose but omits relationship between id and name, and lacks behavioral context due to missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3; description adds little beyond schema, only references external docs for format options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool exports a stored request to multiple formats, distinguishing it from siblings like 'import' and 'save'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives; lacks context on prerequisites or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a stored request/response by ID or name
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Request UUID or shortcut: last (most recent) prev (second most recent) prev:N (Nth from latest) | |
| grep | No | Regex to search in response body | |
| name | No | Saved name to fetch | |
| part | No | What to return: meta request response both (default both) | |
| limit | No | Max body bytes to return (default 102400) | |
| offset | No | Body byte offset for pagination | |
| max_match_bytes | No | Bound grep output to ~N bytes per match (a window around each match) and omit the full body. For grepping large single-line/minified assets. 0 = default per-line grep. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'Retrieve'. It does not disclose whether it is read-only, error behavior (e.g., missing ID), or any side effects. Some behavioral details are in the input schema (e.g., grep, limit) but not in the description itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the purpose. It is front-loaded and efficient, though it could be slightly expanded for clarity without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 7 parameters and no output schema or annotations, the description only provides minimal context. It lacks explanation of return values, pagination behavior, and advanced features like grep, making it incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond mentioning 'ID or name'. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'stored request/response', with specific identifiers (ID or name). However, it does not distinguish it from sibling tools like 'search' or 'hunt', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given the many sibling tools (e.g., search, hunt, profile), the absence of usage context leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set active hunt — creates database if new, loads existing if found. See rqwstr_docs(topic="hunts") for workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Hunt identifier (e.g. rapyd-2026-02) | |
| notes | No | Hunt description or notes | |
| proxy | No | Proxy URL (omit to leave stored value unchanged; use reset_overrides to clear back to global default) | |
| target | No | Primary target domain | |
| data_dir | No | Data directory (default: ~/.rqwstr) | |
| scope_file | No | Path to scope JSON file | |
| user_agent | No | Custom User-Agent for all requests | |
| config_file | No | Path to TOML hunt config file | |
| default_headers | No | Default headers injected into every request | |
| reset_overrides | No | Per-hunt stored fields to clear back to global defaults from config.toml. Supported: proxy. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only discloses that the tool creates a database or loads an existing one. It does not mention side-effects, permissions, reversibility, or the impact of parameters like 'proxy' or 'reset_overrides', which is insufficient for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the core action and directing to further documentation. Every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high parameter count and no output schema, the description fails to explain the return value, the workflow after setting a hunt, or how parameters affect behavior. The reference to docs helps but does not compensate for inline completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are described in the input schema. The description adds no additional meaning about parameters, meeting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Set active hunt — creates database if new, loads existing if found' which clearly identifies the tool's purpose as setting the current hunt context with database management. However, it does not explicitly distinguish from siblings like 'chain' or 'scope' but the database creation aspect differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers minimal guidance on when to use this tool versus alternatives. It only references documentation ('See rqwstr_docs(topic="hunts") for workflow') without providing explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import raw HTTP request from Burp or other tools — stores as crafted. See rqwstr_docs(topic="export") for the reverse direction.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | Yes | Raw HTTP request text (e.g. GET /path HTTP/1.1\r\nHost: example.com\r\n\r\n) | |
| name | No | Save imported request with this name for quick lookup | |
| https | No | Use HTTPS scheme (default false = HTTP) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It mentions 'stores as crafted' but does not disclose whether the import modifies existing data, requires authentication, or has side effects. Significant behavioral details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are front-loaded with the core purpose. Every sentence adds value, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description is insufficient. It fails to explain return values, error conditions, input validation, or limits. The tool's behavior is only lightly sketched.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema by stating the context of 'from Burp or other tools', but does not elaborate on parameter usage beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool imports raw HTTP requests from Burp or other tools and stores them as crafted. The verb 'import' and resource 'raw HTTP request' are specific, and it distinguishes itself from the sibling 'export' by referencing the reverse direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a pointer to the reverse direction via rqwstr_docs, but does not offer guidance on when to use this tool over other siblings like fetch, send, or hunt. The description lacks explicit when-not-to-use or alternatives beyond export.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Burp Intruder-style fuzzing with sniper, battering ram, pitchfork, and cluster bomb attack types. See rqwstr_docs(topic="intruder") for attack types and CSRF handling.
| Name | Required | Description | Default |
|---|---|---|---|
| sni | No | TLS SNI override. Decouples SNI from Host header for HTTPS requests. | |
| url | Yes | Target URL with §position§ markers | |
| body | No | Request body (may contain §position§ markers) | |
| method | Yes | HTTP method | |
| headers | No | Request headers (may contain §position§ markers) | |
| threads | No | Concurrent threads (default 1 max 50) | |
| payloads | No | Position name to payload values mapping | |
| output_dir | No | Directory to save response bodies (creates if not exists) | |
| timeout_ms | No | Per-request timeout in ms (default 30000) | |
| attack_type | Yes | Attack type: sniper battering_ram pitchfork cluster_bomb | |
| raw_headers | No | Raw headers string (\r\n-separated). Appended after headers map. Allows duplicate headers and non-standard formatting. | |
| filter_match | No | Only show responses matching this regex | |
| http_version | No | HTTP version: 1.1 or 2 (default 1.1; use 2 for HTTPS timing attacks) | |
| filter_status | No | Only show these status codes | |
| payload_files | No | Position name to relative hunt artifact path (one payload per line); absolute paths require RQWSTR_ALLOW_ABSOLUTE_FILE_PATHS=1 | |
| session_setup | No | Chain-like steps to run before each request. Fetches CSRF tokens and session state. Extracted variables substitute via double-brace syntax. Cookies auto-forward. | |
| filter_time_gt | No | Only show responses slower than N milliseconds | |
| filter_time_lt | No | Only show responses faster than N milliseconds | |
| payload_ranges | No | Position name to range spec (e.g. 1-254 or 0-100:5) | |
| request_target | No | Override request-line target (RFC 7230 §5.3.2 absolute-form). May contain §position§ markers. | |
| filter_length_gt | No | Only show responses larger than N bytes | |
| filter_length_lt | No | Only show responses smaller than N bytes | |
| filter_exclude_payload | No | Regex to exclude results where any payload value matches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'fuzzing' and references external docs. It does not mention safety concerns (e.g., potential for many requests, destructive effects) or request handling details beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, with no wasted words. However, it relies on an external reference for critical details (attack types, CSRF), which slightly reduces self-contained conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 23 parameters, no output schema, and no annotations, the description is too sparse. It lacks overview of the process, output format, prerequisites, or risk details. The high parameter count demands more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 23 parameters, each with a clear explanation. The tool description adds no extra parameter semantics, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as performing Burp Intruder-style fuzzing with multiple attack types. It distinguishes it from siblings like 'send' or 'hunt', though it could specify the action verb more explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'send' or 'hunt'. The description mentions consulting external documentation for attack types and CSRF handling, but does not set decision rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Out-of-Band interaction detection via Interactsh for blind vulnerability testing. See rqwstr_docs(topic="oob") for the register/send/poll workflow.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Override auth token (default from config.toml) | |
| action | Yes | Action: register poll list deregister | |
| server | No | Override Interactsh server URL (default from config.toml) | |
| correlation_id | No | Correlation ID (required for poll and deregister) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool is for 'detection' but does not disclose whether it is read-only, destructive, or what side effects (e.g., network calls, state changes) occur. The multi-step workflow is only referenced via external docs, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one for purpose and one pointing to further docs. It is extremely concise with no fluff, front-loading the core concept.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of OOB detection (register/send/poll workflow) and lack of output schema, the description is incomplete. It does not explain the workflow steps, return behavior, or error handling, relying entirely on external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter described (e.g., token override, action enum, server URL, correlation ID for poll/deregister). The description adds no further semantic meaning beyond referencing the workflow. Baseline 3 is appropriate as schema handles parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Out-of-Band interaction detection via Interactsh for blind vulnerability testing.' This specifies a verb+resource combination and distinguishes it from direct testing tools like 'send' or 'fetch', which lack OOB capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description references 'rqwstr_docs(topic="oob")' for the register/send/poll workflow, hinting at a multi-step process, but provides no explicit guidance on when to use this tool versus alternatives like 'send' or 'intruder'. It lacks clear when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send multiple different HTTP requests simultaneously. See rqwstr_docs(topic="parallel") for sync/stagger/repeat patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| grep | No | Regex to search response bodies | |
| sync | No | Barrier sync: wait for all goroutines before firing (default false) | |
| repeat | No | Fire the same batch this many times (default 1). For sustained throughput attacks like cache poisoning. | |
| requests | Yes | List of requests to send simultaneously | |
| grep_first | No | Stop repeating on first grep match and return that wave's results | |
| stagger_ms | No | Delay in ms between firing each request (staggered timing mode) | |
| timeout_ms | No | Per-request timeout in ms (default 30000) | |
| session_setup | No | Chain-like steps to run before each wave. Fetches CSRF tokens and session state. Extracted variables substitute via double-brace syntax. Cookies auto-forward. | |
| repeat_delay_ms | No | Delay in ms between repeat waves (default 0 = immediate) | |
| grep_ignore_case | No | Case insensitive grep |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only mentions simultaneous sending, ignoring key behaviors like sync, staggering, repeating, grep filtering, and session setup. The description is insufficient for an AI agent to understand the tool's full capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence plus a reference). It is front-loaded with the core purpose, but could include more information without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no annotations), the description is very incomplete. It does not explain return values, error handling, or how results are aggregated. The reference to external docs helps but is not sufficient for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core function: sending multiple different HTTP requests simultaneously. This distinguishes it from sibling tools like 'send' (single request) and 'intruder' (brute-forcing). The reference to docs for patterns adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It only points to docs for sync/stagger/repeat patterns, but lacks direct guidance on usage boundaries or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Variable profile management — save, load, list, delete named snapshots of variables
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Profile name (required for save load delete) | |
| action | Yes | Action: save load list delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full responsibility. It lists actions but does not disclose behavioral traits such as side effects (e.g., overwriting on save), permission requirements, or error conditions. For a management tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and lists the supported actions. It is efficient and easy to parse, though it could be slightly more structured (e.g., using bullet points).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks crucial context about return values, storage location, naming constraints, and error handling. It is minimally adequate for a 2-parameter tool but leaves significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters clearly. The description reinforces that 'name' is required for certain actions but adds little new semantic meaning beyond stating the action values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: managing variable profiles via save, load, list, and delete actions. It specifies both the verb ('manage') and the resource ('variable profiles'), and distinguishes it from sibling tools by naming specific profile operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when managing variable profiles) but provides no explicit guidance on when not to use it or how it compares to sibling tools. There is no mention of alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Race condition testing with burst, single_packet, and staggered timing modes. See rqwstr_docs(topic="race") for timing-mode guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| sni | No | TLS SNI override. Decouples SNI from Host header for HTTPS requests. | |
| url | Yes | Target URL | |
| body | No | Request body | |
| grep | No | Regex to search response bodies | |
| name | No | Request name for result labeling | |
| count | No | Number of copies to send (default 10; ignored when payloads set) | |
| method | Yes | HTTP method | |
| timing | No | Timing mode: burst (default), single_packet (H2 single-frame attack), or staggered_us:N | |
| headers | No | Request headers | |
| payloads | No | Different payloads for each request (overrides count) | |
| raw_path | No | Send URL path exactly as provided without Go net/url normalization. Preserves percent-encoded sequences like %2f literally. For web cache deception and path traversal attacks. | |
| body_file | No | Relative path under hunt artifacts directory for request body; absolute paths require RQWSTR_ALLOW_ABSOLUTE_FILE_PATHS=1. Overrides body. | |
| multipart | No | Multipart form-data parts. Each part: {name, value, filename, content_type, body_file/file_path}. File paths are relative to hunt artifacts unless RQWSTR_ALLOW_ABSOLUTE_FILE_PATHS=1. Overrides body/body_file. | |
| timeout_ms | No | Per-request timeout in ms (default 30000) | |
| raw_headers | No | Raw headers string (\r\n-separated). Appended after headers map. Allows duplicate headers and non-standard formatting. | |
| session_setup | No | Chain-like steps to run before each burst. Fetches CSRF tokens and session state. Extracted variables substitute via double-brace syntax. Cookies auto-forward. | |
| payload_marker | No | Marker to replace with payload (default {{PAYLOAD}}) | |
| request_target | No | Override request-line target (RFC 7230 §5.3.2 absolute-form) | |
| grep_ignore_case | No | Case insensitive grep |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds minimal behavioral context. It mentions timing modes but does not disclose what happens during testing, output format, or side effects. Most behavioral information must be inferred from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose. Every sentence adds value, and the reference to documentation is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (19 parameters, nested objects, no output schema), the description is insufficient. It lacks details on how to use the tool, what results to expect, and does not compensate for missing output schema or annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already documented. The description mentions timing modes but does not add meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for race condition testing, specifying timing modes. It distinguishes itself from sibling tools like 'fetch' or 'intruder' by being purpose-built for race conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for race condition testing but does not explicitly state when to use this tool over alternatives. The reference to rqwstr_docs for timing guidance provides some direction but no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch rqwstr agent guidance by topic. topic='index' lists all topics; pass a topic name (e.g. 'race', 'intruder', 'chain') to read that page. Do not call this tool more than 3 times per question.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Topic name; use 'index' (or empty) to list all topics |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool fetches guidance and imposes a rate limit (3 times per question). However, it does not state whether it is read-only, idempotent, or any side effects. The rate limit adds moderate transparency, but more detail on behavior (e.g., no side effects) would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no fluff. The first sentence states purpose, the second explains usage and a constraint. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with one optional parameter and no output schema, the description is fairly complete. It explains the two modes, gives examples, and adds a rate limit. It does not describe the format of returned guidance, but for a straightforward fetch tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the single parameter 'topic' is described. The description adds examples ('race', 'intruder', 'chain') and clarifies the use of 'index', but these largely repeat the schema's own description. With full schema coverage, baseline is 3; the description provides marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'rqwstr agent guidance by topic'. It distinguishes from sibling tools which are action-oriented (e.g., hunt, send) by specifying a documentation retrieval function. The two modes (index vs specific topic) are explicitly described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to fetch guidance) and includes an explicit usage constraint: 'Do not call this tool more than 3 times per question.' While it doesn't explicitly state when not to use it or direct to alternatives, the context of sibling tools implies that this is for reference, not actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Name a request for quick retrieval
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Request ID to name | |
| name | Yes | Human-readable name for the request | |
| notes | No | Freeform notes to attach to the request |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It only states 'name a request' without disclosing side effects (e.g., whether it overwrites, requires persistence, or affects other tools). The behavior is underspecified for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence, which is efficient and front-loaded. It could benefit from additional detail, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is too minimal. It lacks information on return behavior, persistence, and edge cases, leaving the agent under-informed for a state-changing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning beyond the schema, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Name a request for quick retrieval' clearly states the action (name) and resource (request), and its purpose (quick retrieval). It is specific and not a tautology, though it doesn't distinguish from sibling tools like 'save' might imply storing; however, the verb 'name' is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, leaving the agent to infer context. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage scope rules — add/remove include/exclude rules, import presets, check URLs
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Rule ID (for remove) | |
| url | No | URL to check (for check) | |
| port | No | Port number (for add) | |
| type | No | Rule type: include or exclude (for add) | |
| notes | No | Notes for the rule (for add) | |
| action | Yes | Action: add remove list clear import status check | |
| preset | No | Preset name: exclude-static exclude-cdn exclude-analytics (for import) | |
| protocol | No | Protocol: any http https (default any) (for add) | |
| host_pattern | No | Host pattern e.g. *.example.com (for add) | |
| path_pattern | No | Path pattern e.g. /api/* (for add) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It mentions actions but does not explain side effects, persistence, permissions, or error handling. The description lacks critical behavioral context beyond listing operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently summarizes the tool's purpose and key operations. Every word adds value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters with conditional actions) and absence of annotations or output schema, the description is too brief. It does not explain which parameters are used for which action, leaving gaps for the AI agent to infer from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal meaning beyond the schema—it recaps actions but does not clarify conditional parameter usage (e.g., which parameters apply to which actions). The schema's own descriptions are sufficient, so the description contributes little extra.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages scope rules and lists specific operations (add/remove include/exclude, import presets, check URLs). It distinguishes this tool from sibling tools like fetch or hunt, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not specify contexts where scope management is needed, nor does it mention when not to use it or recommend other tools for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Regex search through stored requests and responses
| Name | Required | Description | Default |
|---|---|---|---|
| in | No | Where to search: all name notes request response (default all) | |
| limit | No | Max results to return (default 50) | |
| query | Yes | Regex pattern to search for | |
| method | No | Filter by HTTP method (GET POST etc) | |
| status | No | Filter by HTTP status code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It hints at read-only behavior ('search through stored') but does not explicitly state that the tool only reads and does not modify data. Missing details about performance, rate limits, or data sources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (7 words, 1 sentence). It is front-loaded and contains no fluff, but could be slightly more informative without losing conciseness (e.g., specifying regex flavor or default scope).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no output schema), the description is insufficient. It does not explain the return format, pagination, or that the tool is non-destructive. The stored data context ('stored requests and responses') remains vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions (100% coverage). The description adds minimal value beyond the schema—only clarifying that the search is regex-based, which is already in the schema for 'query'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: regex search through stored requests and responses. It distinguishes from sibling tools like 'fetch' or 'send' which perform actions, but could be more specific about which stored data (e.g., proxy history, saved items).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'hunt' or 'scope'. The description lacks context about typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send HTTP request and store in hunt database. See rqwstr_docs(topic="hunts") for the core workflow. Cookie handling: an explicit Cookie in headers or raw_headers suppresses the per-hunt cookie jar (the jar is only injected when no Cookie is supplied). A Cookie set in both sources is additive on the wire — both propagate, not deduped. send injects jar cookies outbound but NEVER auto-stores Set-Cookie: for multi-step authenticated flows use chain (forward_cookies), or session(action="import_from_response") after a login response. See rqwstr_docs(topic="cookies") for the full store model and setting explicit Cookie payloads (session fixation, deserialization, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| sni | No | TLS SNI override. Decouples SNI from Host header for HTTPS requests. When set the TLS ServerName uses this value instead of the Host header. | |
| url | Yes | Target URL (must include scheme) | |
| body | No | Request body string | |
| grep | No | Regex to filter response. Use .* to return full body | |
| name | No | Save request with this name for quick lookup. If the name is already used in this hunt an integer suffix is appended (name-2, name-3, ...) and the stored name is reported back, so the request stays retrievable via fetch. | |
| notes | No | Attach notes to request | |
| method | Yes | HTTP method (GET POST PUT DELETE etc) | |
| headers | No | Request headers as key-value pairs | |
| raw_path | No | Send URL path exactly as provided without Go net/url normalization. Preserves percent-encoded sequences like %2f literally. For web cache deception and path traversal attacks. | |
| body_file | No | Relative path under hunt artifacts directory for request body; absolute paths require RQWSTR_ALLOW_ABSOLUTE_FILE_PATHS=1. Overrides body. | |
| multipart | No | Multipart form-data parts. Each part: {name, value, filename, content_type, body_file/file_path}. File paths are relative to hunt artifacts unless RQWSTR_ALLOW_ABSOLUTE_FILE_PATHS=1. Overrides body/body_file. | |
| timeout_ms | No | Request timeout in milliseconds (default 30000) | |
| url_encode | No | URL-encode query parameter values | |
| raw_headers | No | Raw headers appended verbatim. No validation — enables duplicate headers and header smuggling. Array of [name, value] pairs: [["X-Custom", "val"]]. | |
| http_version | No | HTTP version: 1.0 or 1.1 (default 1.1) | |
| connection_id | No | Reuse H1 connection by ID. Same connection_id = same TCP connection. For H1 smuggling self-verification (send smuggle + follow-up on same connection). Auto-closes after 60s idle. | |
| keep_alive_ms | No | Hold connection open after response. Milliseconds. Use with connection_id to keep poisoned bytes alive until a victim request. | |
| max_redirects | No | Max redirects to follow (default 10) | |
| save_response | No | Relative path under the hunt artifacts directory to save raw response body bytes | |
| request_target | No | Override request-line target. Use for absolute-form requests (RFC 7230 §5.3.2) e.g. GET https://backend/ HTTP/1.1 | |
| close_connection | No | Close a pooled connection by connection_id. Returns immediately without sending a request. | |
| follow_redirects | No | Follow HTTP redirects (default false) | |
| grep_ignore_case | No | Case insensitive grep matching | |
| pause_after_headers_ms | No | Pause between sending headers and body in milliseconds. For pause-based CL.0 desync attacks where the backend times out waiting for the body. | |
| content_length_override | No | Override Content-Length header value independent of actual body length. For CL mismatch smuggling. | |
| save_response_overwrite | No | Overwrite an existing save_response artifact (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses critical behavioral traits: cookie jar suppression when explicit Cookie is set, additive cookie behavior, no auto-storing of `Set-Cookie`, and details about `raw_path`, `raw_headers`, and connection reuse. However, it does not explicitly mention side effects or resource limits, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long (three paragraphs) but packs essential details and references. It could be more concise by front-loading the core purpose and moving cookie technicalities to a separate section. Still, it is well-structured with inline references.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (26 parameters, advanced features like raw_path, raw_headers, cookie jar management), the description covers key behaviors and directs to `rqwstr_docs` for more. It lacks details on the response format or error handling, but is otherwise complete for advanced usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds significant value for cookie-related parameters (e.g., the interaction between `headers`, `raw_headers`, and Cookie) but does not systematically explain the other 26 parameters beyond the already comprehensive schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core action: 'Send HTTP request and store in hunt database.' It also references `rqwstr_docs` for the core workflow and provides details on cookie handling, making the purpose distinct. However, it does not explicitly differentiate from sibling `send_h2`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use alternatives: 'for multi-step authenticated flows use `chain` (forward_cookies), or `session(action="import_from_response")`.' It also points to `rqwstr_docs` for more context, providing clear when-to-use and when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send HTTP/2 request over TLS with ALPN negotiation. See rqwstr_docs(topic="http2") for raw-frame mode and smuggling primitives. Cookie handling matches send: an explicit Cookie in headers (or raw_headers) suppresses the per-hunt cookie jar, and a Cookie set in both sources is additive on the wire (both propagate, not deduped). raw_headers only reaches the wire on raw_mode or a pooled connection; on the standard HTTP/2 path raw_headers is not sent, so it neither suppresses the jar nor lands on the wire.
| Name | Required | Description | Default |
|---|---|---|---|
| sni | No | TLS SNI override. Decouples SNI from Host header. When set the TLS ServerName uses this value instead of the Host header. | |
| url | Yes | Target URL (must be HTTPS) | |
| body | No | Request body | |
| grep | No | Regex to filter response | |
| name | No | Save request with this name for quick lookup | |
| notes | No | Attach notes to request | |
| method | Yes | HTTP method (GET POST PUT DELETE etc) | |
| headers | No | Request headers | |
| raw_mode | No | Use raw H2 frame path. Bypasses Go HTTP/2 validation. Enables CRLF injection and Content-Length mismatch. | |
| body_file | No | Read request body from relative hunt artifact path; absolute paths require RQWSTR_ALLOW_ABSOLUTE_FILE_PATHS=1. Supports binary content and raw CRLF bytes. Takes precedence over body parameter. | |
| timeout_ms | No | Request timeout in ms (default 30000) | |
| raw_headers | No | Ordered header pairs [[name val]...] for raw_mode. Use instead of headers when order matters. | |
| connection_id | No | Reuse H2 connection by ID. Same connection_id = same TCP connection. For H2 smuggling self-verification (send smuggle + follow-up on same connection). Auto-closes after 60s idle. | |
| keep_alive_ms | No | Hold connection open after response for H2 smuggling. Sends PING keepalives. Milliseconds. raw_mode only. | |
| close_connection | No | Close a pooled connection by connection_id. Returns immediately without sending a request. | |
| grep_ignore_case | No | Case insensitive grep | |
| pause_after_headers_ms | No | Pause between HEADERS and DATA frames in milliseconds (raw_mode only). For pause-based desync attacks. | |
| content_length_override | No | Override Content-Length header value (raw_mode only). Set to a value different from body length for H2.CL smuggling. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully discloses behaviors: ALPN negotiation, cookie suppression/additive behavior, raw_headers sending conditions, connection reuse/auto-close, and raw_mode specifics. It provides extensive detail beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, front-loading the main purpose. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema, but covers input parameters and behavioral nuances comprehensively. References external docs for further depth. Sufficient for a complex tool with 18 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds value by explaining interactions like cookie handling and raw_headers behavior, exceeding mere schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Send HTTP/2 request over TLS with ALPN negotiation,' providing a specific verb and resource. It distinguishes from siblings like 'send' by focusing on HTTP/2 and advanced features like smuggling, with a reference to 'rqwstr_docs' for further details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers guidance on cookie handling and raw mode usage, and compares to 'send' for cookie behavior. However, it does not explicitly specify when to avoid this tool in favor of siblings, though the context implies it for HTTP/2-specific tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cookie jar management — list, get, set, delete, clear cookies, import from response headers. See rqwstr_docs(topic="cookies") for actions.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Target URL (for get and import_from_response) | |
| name | No | Cookie name (for set and delete) | |
| path | No | Cookie path (for set; defaults to /) | |
| value | No | Cookie value (for set) | |
| action | Yes | Action: list get set delete clear import_from_response delete_expired | |
| domain | No | Cookie domain (for set and delete) | |
| secure | No | Secure flag (for set) | |
| expires | No | Expiry Unix ms (for set; 0 = session cookie) | |
| http_only | No | HttpOnly flag (for set) | |
| same_site | No | SameSite: Strict Lax None (for set) | |
| set_cookies | No | Set-Cookie header values (for import_from_response) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description lists actions but does not disclose behavioral details such as whether modifications take immediate effect, results of clear, or prerequisites for import_from_response. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence plus reference) and front-loaded with the purpose. However, it could include more guidance without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters and multiple actions, the description is too minimal. It lacks explanation of return values (no output schema), prerequisites, or detailed usage context, relying on external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional meaning beyond the schema; it merely references actions already enumerated in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as 'Cookie jar management' and enumerates specific actions (list, get, set, delete, clear, import from response headers), distinguishing it from sibling tools like fetch or send which handle HTTP requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for cookie management and directs to rqwstr_docs for further actions, but lacks explicit when-to-use vs alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.2.0chainencodeexportfetchhuntimportintruderoobparallelprofileracerqwstr_docssavescopesearchsendsend_h2sessionEach tool has a clearly distinct purpose: send/send_h2 for single requests, chain for multi-step flows, parallel for simultaneous, intruder for fuzzing, race for race conditions, oob for out-of-band detection, etc. Even send and send_h2 are differentiated by HTTP version. No two tools overlap in functionality.
Most tools use single-word lowercase verbs (chain, encode, fetch, hunt, etc.), but there are deviations: 'intruder' is a noun, 'oob' is an acronym, 'rqwstr_docs' uses an underscore, and 'send_h2' uses underscore. However, the overall pattern is short and descriptive, with only minor inconsistency.
18 tools is well-scoped for a comprehensive HTTP security testing toolkit. Each tool covers a distinct operation (sending, fuzzing, encoding, session management, etc.), and the number is neither too small to be useful nor too large to be overwhelming.
The tool surface covers the full lifecycle of HTTP request manipulation: creation (import, save), sending (send, send_h2, chain, parallel, intruder, race), modification (encode, session), inspection (fetch, search, export), and auxiliary functions (hunt, scope, profile, oob, rqwstr_docs). No obvious gaps for its intended purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MEOK MCP Hardening MCP — automated security red-team for any MCP server. Maps OWASP LLM Top 10
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kjopstad-IT/rqwstr-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
