rqwstr

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.0
Disambiguation5/5
Each 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.4/5 across 18 of 18 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness3/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![rqwstr-mcp MCP server](https://glama.ai/mcp/servers/Kjopstad-IT/rqwstr-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Kjopstad-IT/rqwstr-mcp)

Score Badge

Copy to your README.md:

[![rqwstr-mcp MCP server](https://glama.ai/mcp/servers/Kjopstad-IT/rqwstr-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Kjopstad-IT/rqwstr-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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