kali-mcp-server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes (e.g., nmap_scan vs masscan_scan vs host_discovery). However, dns_recon with scan_type 'brt' overlaps with subdomain_enum, and several *scan tools could be confused by target type, though descriptions clarify.
Naming Consistency4/5
All tool names use snake_case and mostly follow a '{object}_{action}' pattern (dns_recon, nmap_scan, hash_crack). Exceptions like list_tools_status, generate_report, and record_finding start with a verb, creating minor inconsistency but still predictable.
Tool Count4/5
24 tools is above the typical 3-15 range, but the server covers a full pentest workflow (recon, scanning, exploitation, reporting, scope management). Each tool serves a distinct function, so the count feels slightly heavy but justified for a Kali MCP server.
Completeness4/5
The toolset covers the core lifecycle: recon (dns_recon, subdomain_enum), scanning (nmap_scan, nikto_scan), exploitation (sqlmap_test, hydra_bruteforce), and reporting (record_finding, generate_report). Minor gaps like traffic capture or wireless testing exist, but the main engagement flow is complete.
Average 4.3/5 across 24 of 24 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
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.
Add a glama.json file to provide metadata about your server.
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 the full burden of disclosing behavioral traits. It does not mention that this is an active network scanner that sends HTTP requests, nor does it explain potential side effects, rate limiting, or the meaning of aggression levels. It also does not clarify whether the tool is read-only or could have any impact, leaving the agent to infer the operational behavior from the tool name and 'whatweb' reference.
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 well-organized with labeled sections (USECASE, INSTRUCTIONS, INPUT_DESCRIPTION, OUTPUT_DESCRIPTION, EXAMPLES, PREREQUISITES, RELATED_TOOLS) and front-loads the core purpose. It is a bit verbose and repeats some information (e.g., in-scope requirement mentioned multiple times), but the structure makes it scannable and each section earns its place. It could be trimmed, but it is not bloated.
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 moderate complexity, the description is quite complete: it includes use cases, step-by-step instructions, prerequisites, an example, related tools, and expected output structure. However, the lack of clarity on the aggression range and the absence of behavioral transparency (e.g., network activity) leave gaps. The presence of an output schema reduces the need to detail return values, but the description still provides some. Overall, it is above average but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are entirely absent (0% coverage), so the description must compensate. It does explain 'target' as 'URL to fingerprint (must be in scope)' and 'aggression' as 'whatweb aggression level (1-4)' or '1=stealthy .. 3=aggressive' in different sections. However, these two ranges (1-4 vs 1-3) contradict each other, which degrades clarity and could mislead an agent about valid inputs. The inconsistency prevents the description from fully compensating for the schema gap.
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 opens with a specific verb+resource: 'Fingerprint web technologies used by an in-scope site (whatweb).' It clearly identifies the tool's function as identifying CMS, frameworks, servers, and libraries, distinguishing it from sibling tools like nikto_scan and nuclei_scan which focus on vulnerability scanning.
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 clear usage context: ensure host is in scope, provide URL and optional aggression level, and call. PREREQUISITES explicitly states 'Host authorized and in scope.' RELATED_TOOLS lists related utilities, but there is no explicit when-not-to-use guidance or criteria for choosing this tool over alternatives, so it lacks full exclusionary guidance.
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?
With no annotations, the description carries the burden of disclosing behavior. It says the tool is 'passive' and uses 'public sources', which implies read-only, non-intrusive behavior. It also reveals the output contains 'command and mode', indicating it runs a subprocess. However, it doesn't discuss potential side effects, rate limits, or reliance on third-party APIs, leaving some behavioral aspects opaque.
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 core description is a single, front-loaded sentence. The additional metadata block is structured and informative, though some entries (e.g., TOOL_NAME, DISPLAY_NAME) repeat the tool name and add little. The format is clear and scannable, but minor redundancy prevents a perfect score.
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?
For a one-parameter tool with an output schema, the description is quite complete. It covers purpose, use case, instructions, prerequisites, input semantics, output structure, and examples. It lacks explicit guidance on choosing this over sibling tools and does not mention error handling or edge cases, but overall it provides sufficient context for correct invocation.
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?
The schema only states 'domain' is a required string (0% coverage). The description adds meaningful semantics: 'Args: domain: Apex domain to enumerate (must be in scope).' It also provides an example 'example.com' and clarifies the domain should be an apex domain, which compensates well for the sparse schema.
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 function: 'Discover subdomains of an in-scope domain (subfinder, passive).' It includes a specific verb ('discover'), a resource ('subdomains'), and scope ('in-scope domain'). While it doesn't explicitly differentiate from siblings like dns_recon, the mention of 'passive' and 'subfinder' conveys its unique approach.
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 clear context for when to use the tool via metadata: 'USECASE=Passively discover subdomains of an authorized domain from public sources', 'INSTRUCTIONS=1. Ensure domain is in scope, 2. Call with the apex domain', and 'PREREQUISITES=Domain authorized and in scope'. It gives situational guidance but does not explicitly contrast with alternatives (e.g., when to use dns_recon instead).
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?
With no annotations provided, the description carries the full burden of disclosure. It states that the tool performs a scan (active network behavior) and requires scope/authorization. It also mentions returning 'raw nikto findings' and a 'command and mode' in the output, which hints at execution details. However, it does not disclose potential side effects such as network traffic volume, duration, or alerting, which is important for a scanning 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 well-structured with distinct metadata sections (USECASE, INSTRUCTIONS, INPUT_DESCRIPTION, OUTPUT_DESCRIPTION, EXAMPLES, PREREQUISITES, RELATED_TOOLS). It is somewhat lengthy but every section provides useful context. The opening line is concise and action-oriented, and the Args/Returns summary at the end is clear.
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?
The description covers prerequisites, instructions, examples, related tools, input semantics, and output structure. It gives sufficient context for an agent to understand what the tool does and how to use it. It does not exhaustively describe all possible return values, but the presence of an output schema (even if not detailed in the prompt) and explicit OUTPUT_DESCRIPTION mitigate that 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?
The input schema has 0% description coverage, so the description must compensate. It does so by explaining target is a 'Web host or URL (must be in scope)' and port as 'Optional explicit port' with the INPUT_DESCRIPTION adding the default behavior ('default 80/from URL'). This adds valuable meaning beyond the bare schema types.
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 starts with a specific verb+resource: 'Scan a web server for known vulnerabilities and misconfigurations (nikto).' This clearly distinguishes it from sibling tools like whatweb_fingerprint (fingerprinting) or dir_bruteforce (directory brute force), and the USECASE reinforces the purpose.
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 clear context for when to use the tool via USECASE ('Identify dangerous files, outdated servers, and misconfigurations on an in-scope web host'), INSTRUCTIONS (ensure scope, provide target), and PREREQUISITES (host authorized and in scope). It lists related tools but does not explicitly differentiate when to choose this over alternatives, so it stops short of a perfect score.
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?
With no annotations, the description carries the burden of disclosing behavior. It mentions zone transfer attempts, scan type options, and the requirement for authorization. However, it does not explicitly state whether the tool is read-only, potential network impact, or error behavior, leaving some gaps in transparency.
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 structured with metadata fields and a docstring, providing all essential info. Some redundancy exists between USECASE and the main description, but it is well-organized and front-loaded.
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 moderate complexity (2 params, output schema exists), the description covers scope, parameters, return values, prerequisites, and related tools. It lacks details on edge cases or when to choose this over related tools, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by explaining both parameters: 'domain' must be in scope, and 'scan_type' lists valid values (std, axfr, brt, srv). The example invocation further clarifies parameter usage.
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: 'Enumerate DNS records for an in-scope domain (dnsrecon)' and expands on the record types. It is distinct from sibling tools like subdomain_enum and whois_lookup, with a specific verb and resource.
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 clear usage context, including prerequisites ('domain authorized and in scope') and steps ('Choose scan_type, Call'). It lists related tools for context but does not explicitly state when to use this tool over alternatives, so it falls short of a 5.
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 that masscan needs root, runs as root in a Kali container, caps rate at 5000 to avoid flooding, and summarizes output structure via OUTPUT_DESCRIPTION. It could further detail potential side effects, but what is provided is transparent about execution requirements and output.
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 well-structured with a one-line summary followed by organized fields (USECASE, INSTRUCTIONS, PREREQUISITES, etc.). There is minor redundancy between the first sentence and USECASE, but overall it is efficient and each section adds value.
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?
The description covers purpose, usage, prerequisites, input descriptions, output format, examples, and related tools. For a network scanning tool, this is quite complete. It lacks some edge-case behaviors (timeouts, error handling), but the essentials are well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, so the description must compensate. The Args section thoroughly explains each parameter: target as host/IP/CIDR, ports with examples (e.g., '1-65535' or '80,443'), and rate with a cap and purpose. This adds significant meaning beyond the raw 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 states 'Run a fast masscan port sweep against an authorized target' and USECASE 'Rapidly identify open TCP ports across an in-scope host or range', which fully captures the tool's function. It is also distinct from siblings like nmap_scan (detailed scan) and host_discovery due to the 'fast' and 'port sweep' emphasis.
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 provides prerequisites (target authorization, root requirement) and lists related tools (nmap_scan, host_discovery), but does not explicitly say when to use this tool versus alternatives. The USECASE implies a particular scenario, but exclusions or direct comparisons are missing.
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?
With no annotations, the description must disclose behavioral traits. It mentions the need for authorization and scope, and describes the output structure. However, it does not warn that NSE vuln scripts may be intrusive or that scans can be detected, nor does it mention rate limits or potential side effects. Some transparency is present, but significant details are omitted.
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 well-structured with a concise opening sentence followed by labeled sections (USECASE, INSTRUCTIONS, INPUT_DESCRIPTION, etc.). It is front-loaded with the core purpose and every section provides actionable information without fluff. The format is easy to parse and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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, no annotations, but an output schema, the description is highly complete. It covers purpose, usage instructions, parameter semantics, prerequisites, examples, output format, and related tools. Nothing critical is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description fully compensates. It explains each parameter in detail: target as host/IP/CIDR with scope requirement, profile listing allowed values (quick|full|service|os|aggressive|vuln|top-ports), ports with syntax and override behavior, and extra_args as raw nmap flags. This adds substantial meaning beyond the schema.
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 'Run an nmap scan against an authorized target' and the USECASE adds 'Discover open ports, services, versions, OS and run NSE vuln scripts'. This is a specific verb+resource with a clear purpose, but it does not explicitly differentiate from sibling tools like masscan_scan or host_discovery, so it falls short of a 5.
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 step-by-step instructions (INSTRUCTIONS), prerequisites (ensure target in scope, nmap available), and examples. It gives clear context on how and when to use the tool, but it does not explicitly state when to use this tool instead of alternatives or when not to use it, so no exclusions are given.
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?
With no annotations, the description carries the full burden. It discloses that a finding is stored, lists steps, and describes the return dict, but does not detail side effects such as whether the finding is appended, whether existing data is overwritten, or any error conditions.
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 well-structured with distinct sections (USECASE, INSTRUCTIONS, INPUT_DESCRIPTION, etc.) and an example. However, INPUT_DESCRIPTION and OUTPUT_DESCRIPTION are somewhat redundant with the Args and Returns sections.
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?
The description covers purpose, usage, parameters, output, example, and prerequisites. Related tools are listed but not explained, and side effects are not fully specified, but the tool is simple and the provided information is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section provides meaningful descriptions for all 7 parameters, including allowed severity values and reference types (CVEs, URLs). Since the schema properties have no descriptions, this fully compensates for the 0% schema coverage.
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 opening sentence clearly states the tool records a security finding in the engagement session. The USECASE further specifies it captures vulnerabilities/observations for the final report, distinguishing it from scan/enumeration siblings.
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 USECASE provides clear context for when to use the tool (capturing vulnerabilities for the final report), and RELATED_TOOLS names related tools. However, it does not explicitly state when not to use it or how it differs from generate_report/session_summary beyond the implicit purpose.
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 the essential behavior: WHOIS 'contacts registry servers, not the target itself' and is 'not scope-gated'. It also hints at the output structure (status, raw output, command, mode). This is solid disclosure for a simple lookup tool, though it does not mention potential rate limits or redacted WHOIS data.
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 well-structured with sections, but it is repetitive: the opener and USECASE overlap, and the Args/Returns sections duplicate INPUT_DESCRIPTION/OUTPUT_DESCRIPTION. The INSTRUCTIONS line ('1. Provide a domain or IP, 2. Call') adds little value. It could be tightened without losing information.
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?
For a single-parameter tool with an output schema present, the description covers the essential context: purpose, usage, prerequisites, example, related tools, and behavior. It notes that WHOIS is not scope-gated, which is valuable for engagement context. The output schema itself would cover return details, so lack of deep retvalue explanation is acceptable.
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 schema coverage at 0%, the description compensates well: INPUT_DESCRIPTION states 'target (domain or IP)' and the Args section repeats 'target: Domain or IP to look up'. The example 'whois_lookup("example.com")' clarifies the expected format. This adds meaning beyond the bare schema string type.
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 opens with 'Look up WHOIS registration data for a domain or IP' and the USECASE specifies 'Retrieve registrar/ownership/allocation data', giving a specific verb, resource, and data category. This clearly distinguishes it from sibling tools like dns_recon or subdomain_enum, which serve 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a USECASE, PREREQUISITES ('queries public WHOIS servers, not the target host'), and a Note that the tool is 'not scope-gated'. It also lists RELATED_TOOLS, implying context for alternatives. However, it does not explicitly state when not to use this tool compared to those alternatives, so it falls just short of a 5.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'passive' and 'free/no-key sources', which hints at non-intrusive behavior, but does not explicitly state that the tool is read-only or what side effects (if any) it might have. It also does not mention rate limits or permission requirements beyond scope authorization, leaving some transparency gaps.
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 well-structured with a concise first line followed by key-value metadata and an Args section. There is some redundancy between INPUT_DESCRIPTION and Args, and the USECASE largely repeats the first line, but overall it is efficient and front-loaded. Slightly longer than necessary due to redundancy, but still a solid 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential aspects: purpose, use case, instructions, prerequisites, input parameters, output structure (Structured result dict including parsed emails), examples, and related tools. Given the tool's moderate complexity (3 parameters, 1 required), this is comprehensive and provides enough context for an AI agent to know when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description's Args section fully compensates by explaining each parameter: domain (apex domain, must be in scope), sources (comma-separated theHarvester sources, default free/no-key), and limit (max results). This exceeds what the schema provides and gives essential guidance for using the tool correctly.
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 first line clearly states the verb (harvest), resource (emails, subdomains, hosts), and method (theHarvester, passive), making the purpose immediately obvious. The USECASE adds more detail about collecting from search engines and CT logs, which also distinguishes it from sibling tools like dns_recon or subdomain_enum by emphasizing email discovery.
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 clear usage context: 'Collect public emails, subdomains and hosts for an in-scope domain', along with instructions and prerequisites (domain must be in scope). It also mentions related tools (subdomain_enum, dns_recon) but does not explicitly say when NOT to use this tool versus those alternatives, so it falls short of a perfect 5.
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 description carries full burden. It discloses that it returns a dict with per-tool availability grouped by category, backend status, and execution mode, and indicates no arguments are needed. It does not explicitly state it is read-only, but the nature of a status report implies it.
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 verbose and repetitive, with the first sentence restating the USECASE and OUTPUT_DESCRIPTION duplicating the Returns section. While structured, it contains redundancy that could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool, the description covers use case, instructions, input/output, example, prerequisites, and related tools. It fully specifies behavior and return value, so it's complete.
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?
Tool has 0 parameters, so baseline is 4. Description explicitly states 'Call with no arguments' and INPUT_DESCRIPTION=None, fully clarifying parameter semantics.
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 uses a specific verb 'Report' and resource 'security tools' with scope 'on the host and via Kali/Docker'. It clearly distinguishes from sibling tools that perform scans/recon, as this is a status/availability reporting tool.
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 USECASE field explicitly states 'See, per tool, whether it is installed on the host and whether the Kali container backend is available', providing clear context. It also lists RELATED_TOOLS=scope_manage. However, it does not explicitly state when not to use it or alternatives, so score 4.
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 must disclose behavior. It does explain the output format ('Dict with status and the resulting scope snapshot') and prerequisites ('Only add targets you have written authorization to test'). However, it does not disclose side effects of destructive actions like 'clear' or whether set_engagement overwrites existing scope. With no annotations, this gap is notable.
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 structured with headings and is generally front-loaded with the primary purpose. However, it contains redundancy, e.g., OUTPUT_DESCRIPTION and Returns say nearly the same thing, and the TOOL_NAME/DISPLAY_NAME lines are unnecessary metadata. Overall, it's readable but could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 params, no schema descriptions, and no annotations, this description is exceptionally complete. It includes use cases, instructions, examples, prerequisites, related tools, parameter semantics, and output format. The only minor gap is explicit alternative-selection guidance, but the RELATED_TOOLS line helps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by providing an Args section that explains each parameter: action, targets, client, authorized_by, ticket, start_date, end_date, notes. This adds meaning beyond the bare schema types and helps the agent invoke the tool correctly.
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 first sentence 'Manage the authorized engagement scope (the master authorization gate)' clearly states the tool's verb and resource. The USECASE further details it: 'Declare which targets are authorized, set engagement metadata, and review current scope.' This distinguishes it from sibling scanning tools by positioning it as the authorization gatekeeper.
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 clear usage context through INSTRUCTIONS and PREREQUISITES, e.g., '1. Use action=set_engagement with client/authorized_by/ticket, 2. action=add with targets you are permitted to test, 3. action=show to review.' It also lists RELATED_TOOLS like nmap_scan, generate_report, session_summary. However, it doesn't explicitly say 'use this instead of X when...' or provide exclusion criteria, so it falls short of a 5.
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 of behavioral disclosure. It explicitly states 'Call with no arguments', describes the output ('Dict with scope snapshot, session summary counts, and recent audit events'), and lists prerequisites as None. This exceeds the typical transparency level, though it doesn't explicitly mention read-only semantics, which are implied.
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 but has slight redundancy: the opening sentence, OUTPUT_DESCRIPTION, and Returns section all convey similar information. The structured key-value layout is efficient and front-loads the core purpose, but the duplication prevents a perfect score.
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 zero-parameter signature, the description covers the use case, output format, and example call adequately. The output schema is present, so it doesn't need to detail return values, but it still provides a high-level summary. Minimal guidance on alternative tools is provided, but the simplicity of the tool makes this sufficient.
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?
The tool has zero parameters, so the baseline is 4. The description adds clarity by explicitly stating 'Call with no arguments' and INPUT_DESCRIPTION=None, ensuring the agent knows no input is required.
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 'Summarize the current engagement: scope, scans, findings, recent audit,' naming a specific verb and resource. This distinguishes it from sibling tools, which are all individual recon/scan utilities, making its purpose unambiguous.
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 USECASE ('Get a quick status view of the engagement') and lists RELATED_TOOLS (generate_report, scope_manage), giving context on when to use the tool. It does not explicitly state when not to use it, but the use case and related tools imply the appropriate context.
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?
With no annotations, the description must fully disclose behavioral traits. It mentions the prerequisite that the target must be in scope and describes the return structure, but does not discuss potential side effects such as high request volume or noise. This is adequate but not rich, warranting a 3.
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 front-loaded with a concise one-liner and then organized into structured metadata sections. There is some redundancy between the initial line, USECASE, and INPUT_DESCRIPTION, but the additional instructions, prerequisites, and examples are valuable, so it remains appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, instructions, prerequisites, an example invocation, and the output structure (status, discovered vhosts, command, mode). With an output schema and three parameters, this is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains each parameter: target as the base URL, domain as the apex domain for vhost candidates, and wordlist as optional with a default. This adds complete meaning beyond the bare schema types.
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 function: 'Brute-force virtual hosts on a web server (gobuster vhost mode).' This specifies the verb, resource, and method, and distinguishes it from sibling tools like subdomain_enum and dir_bruteforce through the focus on virtual host discovery.
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 clear context: 'Discover name-based virtual hosts served by an in-scope web server' and includes prerequisites and related tools. However, it does not explicitly state when not to use this tool or when to prefer a related tool like subdomain_enum, so it lacks direct 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 the transparency burden. It explicitly discloses the tool is offline ('Not network-gated'), writes hashes to a temporary file under the output directory, and returns a structured dict with status, cracked credentials, command, and mode. The default wordlist (rockyou) and use of John the Ripper are also stated, providing solid behavioral expectations.
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 structured with headers (USECASE, INSTRUCTIONS, INPUT_DESCRIPTION, etc.) and an Args/Returns block. It has some redundancy between the two parameter sections, but each part conveys useful information and the overall organization aids scanning.
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 lack of schema descriptions and annotations, the description compensates well: it explains inputs, output, example, prerequisites, related tool, offline behavior, and file-writing side effect. It could provide more detail on the result dict structure, but it enumerates the key fields and the output schema is indicated as available. This is robust for a 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), so the description's parameter explanations are essential. The INPUT_DESCRIPTION and Args block define each parameter: hashes (newline-separated), wordlist (path with default), hash_format (--format value), and name (temp file label). The example further illustrates usage with a real hash and format, making parameter semantics clear.
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 opens with a specific action: 'Crack supplied hashes offline with a wordlist (John the Ripper).' It clearly identifies the resource (hashes) and method (offline wordlist cracking), distinguishing it from sibling tools like hash_identify (which identifies hash types) and hydra_bruteforce (online attacks). The USECASE section reinforces this by specifying 'hashes you already possess'.
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 USECASE states 'Recover plaintext for hashes you already possess' and PREREQUISITES adds 'operates only on hashes you supply; no target contact,' clarifying the offline, owned-data context. RELATED_TOOLS points to hash_identify, suggesting a potential preceding step, though it does not explicitly say when to use hash_identify instead; the context is generally sufficient.
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?
The description discloses that it executes vulnerability scans, returns a structured dict with status, findings, command and mode, and requires templates to be present. It also states prerequisites about host authorization. However, it does not mention potential side effects like active network traffic, but 'vulnerability check' implies that. With no annotations, it carries the burden and does so reasonably.
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 contains redundant metadata sections that repeat the same information (INPUT_DESCRIPTION vs Args, OUTPUT_DESCRIPTION vs Returns, USECASE vs first sentence). While the core one-liner is front-loaded and effective, the overall block is longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential aspects: purpose, usage instructions, prerequisites, parameter descriptions, output format, and an example. Given the presence of an output schema and the scanner's complexity, it is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lacks descriptions, but the description provides complete parameter semantics: target is a URL that must be in scope, severity and tags are optional comma-separated filters, with an example. This fully compensates for the 0% schema coverage.
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 'Run template-based vulnerability checks against an in-scope target (nuclei)' and identifies the use case as detecting known CVEs, misconfigurations and exposures. This distinguishes it from sibling scanners like nikto_scan and nmap_scan.
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 explicit usage instructions (ensure in scope, provide URL, optionally filter by severity/tags) and prerequisites (templates present). It lists related tools but does not explicitly contrast when to use this vs alternatives, though the specific purpose implies when.
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 the transparency burden. It discloses the tool's underlying mode (gobuster dir), output structure (dict with status, discovered paths, command, mode), and operational prerequisites (wordlist mounted into /wordlists, host authorized). It does not mention potential aggressive network behavior or rate limits, but the core behavior is clear.
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 well-structured with sections (USECASE, INSTRUCTIONS, INPUT_DESCRIPTION, etc.) and front-loaded with a clear summary. There is slight redundancy between sections (e.g., INPUT_DESCRIPTION vs Args), but each section adds value like examples and prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (brute-forcing with wordlists and extensions), the description covers prerequisites, input parameters, output structure, an example invocation, and related tools. The presence of an output schema also reduces the need to explain return values, but the description already does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains each parameter: target (base URL, must be in scope), wordlist (path, default common.txt), extensions (comma-separated). This adds significant meaning beyond the bare type information in the input 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 states a specific action: 'Brute-force web content paths/directories (gobuster dir mode)' and its use case 'Discover hidden directories and files on an in-scope web app using a wordlist.' This distinguishes it from sibling tools like vhost_enum or nikto_scan.
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 clear usage context: 'Ensure host is in scope, Provide the base URL, Optionally set wordlist/extensions, Call.' It also lists prerequisites and related tools. However, it does not explicitly compare when to use this tool versus alternatives beyond naming them.
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 provided, the description carries the full burden of behavioral disclosure. It clearly states the tool writes a report to an output directory and returns a dict with status, content, and path, which informs the agent of side effects. It does not mention overwrite behavior or error handling, but for a report generator this is reasonably transparent.
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 front-loaded with the core sentence, but the embedded structured metadata (TOOL_NAME, DISPLAY_NAME, USECASE, etc.) includes some redundancy (e.g., TOOL_NAME duplicates the tool name). It is not excessively long, but the repetition prevents a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with one optional parameter and an output schema. The description covers purpose, usage, prerequisites, related tools, input format, output format, and an example, making it highly complete for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with no description (0% coverage). The description compensates by explicitly documenting accepted values: 'report_format: markdown or json.' It also provides an example call, making parameter usage unambiguous.
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 opens with a specific verb and resource: 'Generate an engagement report from recorded scans and findings.' The USECASE further clarifies that it produces a shareable markdown or JSON report, distinguishing it from sibling tools like record_finding and session_summary.
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 clear usage context: it instructs to record findings before calling, and notes that it is 'more useful after findings are recorded.' It lists related tools (record_finding, session_summary) but does not explicitly state when not to use it or provide explicit alternatives, so a 4.
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 burden. It discloses the method (nmap -sn, a ping sweep), the return type (structured dict with status, raw output, command, and mode), and prerequisites (target authorized and in scope). It does not elaborate on network side effects or permission requirements beyond scope, but for a read-only ping sweep, the disclosure is adequate and adds meaningful detail beyond the tool's name.
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 opens with a concise one-line summary, then provides structured fields (TOOL_NAME, USECASE, INSTRUCTIONS, etc.) for easy parsing. Some redundancy exists (e.g., TOOL_NAME repeats the tool name, DISPLAY_NAME is redundant), and the block contains repeated scope reminders, but the overall structure is organized and front-loaded. It is verbose but not wasteful enough to earn a 3.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description covers all necessary context: input description, output description, an example (host_discovery("10.0.0.0/24")), prerequisites, and related tools. It also outlines the structured result fields. This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, but the description fully compensates: 'target: Host, IP or CIDR to sweep (must be in scope).' It clarifies the type (host/IP/CIDR) and the constraint (in-scope). This is exactly what an agent needs to correctly populate the parameter.
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 function: 'Ping-sweep a host or range to find live hosts (nmap -sn).' It uses a specific verb ('sweep') and resource ('host or range'), and mentions the scope of the operation ('without port scanning'), effectively differentiating it from sibling tools like nmap_scan and masscan_scan.
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 USECASE field provides clear context: 'Enumerate which hosts in an in-scope range are up, without port scanning,' implying when to use it. RELATED_TOOLS lists nmap_scan and masscan_scan, but without explicit comparative guidance. There is no direct 'when not to use' statement, but the 'without port scanning' phrase suggests a boundary. This is strong but not fully explicit.
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 provided, the description carries the full burden of behavioral disclosure. It clearly states the tool works offline, makes no target contact, and returns a structured result dict with status/titles/paths/command/mode. It also notes it is 'not scope-gated'. This is significant behavioral context, though it doesn't cover potential error conditions or database freshness.
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 well-structured with a brief opening summary, followed by labeled fields (USECASE, INSTRUCTIONS, INPUT_DESCRIPTION, etc.) that are efficient and informative. It is slightly verbose with repeated mentions of 'offline' and 'no target contact', but every section provides useful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool, the description covers all key aspects: purpose, usage instructions, input examples, output structure, safety characteristics, and related tools. The presence of an output schema and the description's own output details make it fully complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the query parameter, but the description compensates with a clear definition ('Free-text search terms') and concrete examples ('apache 2.4.49', 'CVE-2021-41773'). This adds meaning beyond the bare schema, fully clarifying the expected input format.
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 searches the offline Exploit-DB for known exploits, using specific verbs ('Search', 'Find') and a specific resource. It distinguishes from siblings by highlighting the offline lookup capability and the use case of matching product/version/CVE, which is unique among the sibling tools.
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 clear context on when to use the tool (offline exploit lookup, no target contact) and includes examples and related tools (nuclei_scan, sqlmap_test) indicating alternatives. However, it does not explicitly state when not to use it or directly contrast with alternatives, so it stops short of a 5.
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 provided, the description must carry the full burden of behavioral disclosure. It does a good job by revealing the gated nature ("GATED — exploitation"), the need for ALLOW_EXPLOITATION, and the blocked result when exploitation is disabled. It also indicates that the target must be in scope, implying a safety boundary. It does not mention potential side effects like payload delivery, but the 'exploitation' label and gating already signal high-impact behavior.
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 well-structured with clear sections (USECASE, INSTRUCTIONS, INPUT_DESCRIPTION, etc.) and front-loads the core purpose. It is slightly verbose—some information is repeated between the initial sentence and the structured block—but every section contributes functional guidance. The length is justified because there are no annotations or schema descriptions to lean on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations and a minimal schema, the description covers all critical aspects: use case, step-by-step instructions, prerequisites, input/output formats, an example, and related tools. It even explains the return value includes a 'blocked' status. For a tool of this complexity (gated exploitation, four parameters, custom output), this is a complete and self-sufficient description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The Args section effectively explains each parameter: target is the URL with parameter and must be in scope, data is an optional POST body, level and risk are described with their sqlmap-specific ranges (1-5 and 1-3). An example call further clarifies usage, providing complete semantic meaning beyond the bare schema types and defaults.
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: "Test a URL/parameter for SQL injection (sqlmap)." The verb 'test' plus the specific resource (URL/parameter) and tool (sqlmap) leaves no ambiguity. It also distinguishes itself from siblings by focusing on SQL injection exploitation, whereas other tools like nuclei_scan or nikto_scan cover broader vulnerability scanning.
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 explicit usage context: USECASE is "Detect and exploit SQL injection in an authorized web app parameter," and PREREQUISITES clearly state that ALLOW_EXPLOITATION must be true and the target must be authorized and in scope. However, it does not explicitly state when NOT to use this tool or which sibling tools should be chosen for other vulnerability types, only listing RELATED_TOOLS without explanation.
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 offline operation and 'no target contact', and the phrase 'likely algorithm(s)' conveys probabilistic/multiple-candidate behavior. However, it does not address error handling or behavior with invalid hashes.
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 well-structured with labeled sections (USECASE, INSTRUCTIONS, PREREQUISITES) and front-loaded with the primary purpose. Minor redundancy exists (INPUT_DESCRIPTION repeats Args, OUTPUT_DESCRIPTION repeats Returns), but overall it is scannable and not overlong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with an output schema, the description covers purpose, usage context, example, prerequisites, related tool, and parameter semantics. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates with 'Args: hash_value: The hash string to identify' and a matching INPUT_DESCRIPTION. This gives the agent complete understanding of the parameter.
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 opens with 'Identify the likely algorithm(s) of a hash string (hashid)', which is a specific verb and resource. It clearly distinguishes this from sibling tools like hash_crack by focusing on identification rather than cracking.
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 USECASE field states 'Determine which hashing algorithm produced a given hash before cracking' and PREREQUISITES notes 'None — offline, no target contact', providing explicit context for when to use. RELATED_TOOLS lists hash_crack as an alternative, making the workflow clear.
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 the burden and does disclose key behavior: "GATED — active exploitation", prerequisite ALLOW_EXPLOITATION, and that it returns 'blocked' if exploitation is disabled. It does not mention potential side effects like account lockouts, but the 'active exploitation' framing provides sufficient warning.
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 long but well-structured with labeled sections (USECASE, INSTRUCTIONS, INPUT_DESCRIPTION, etc.). It front-loads the core purpose and provides examples, though some redundancy exists between INSTRUCTIONS and PREREQUISITES.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-risk exploitation tool, the description is comprehensive: it covers purpose, usage prerequisites, input semantics, output format (structured dict with status, credentials, command, mode), and an example. The presence of an output schema also supports completeness, and the description explicitly states the blocked behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the Args section thoroughly defines each parameter: target with scope note, service as hydra module, username/userlist alternatives, password/passwordlist alternatives, and optional port. This fully compensates for the minimal schema and adds practical semantics.
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 states a specific verb+resource: "Brute-force a network login service (hydra)" and includes a USECASE that distinguishes it from siblings like dir_bruteforce or hash_crack. The examples and related tools further clarify its unique role.
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 INSTRUCTIONS and PREREQUISITES sections explicitly state when to use the tool: enable ALLOW_EXPLOITATION, ensure target is in scope, and provide service, username(s), password(s)/list. It also references RELATED_TOOLS (nmap_scan, hash_crack), giving context for alternatives.
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?
With no annotations provided, the description carries the full burden and does so well. It discloses passivity, public scope, audit-log recording, long runtimes ('can take a few minutes'), and the structured return shape. This gives the agent realistic expectations beyond a simple 'lookup'.
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 well-organized using clear subheadings and front-loads the core purpose. There is some repetition between the USECASE, description, and Args sections, but it remains concise enough for an agent to parse quickly and each section adds distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity, and the description covers prerequisites, authorization guidance, related tools, an example, and the return structure (including the 'found' list of {site, url}). The presence of an output schema reduces the need to fully document return values, but the description still provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. The INPUT_DESCRIPTION names both parameters, and the Args section elaborates that username is the handle to search and timeout is an optional seconds override, even noting why it might be needed (Sherlock checks many sites).
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 opens with a clear verb and resource: 'Enumerate which public platforms a username exists on (Sherlock).' The USECASE further clarifies it discovers registered platforms from public profile pages. This distinguishes it from sibling tools like email_harvest or subdomain_enum.
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 clear context for when to use the tool, including prerequisites ('run on handles you are authorized to profile') and that it is passive and not network-scope-gated. However, it does not explicitly contrast alternatives beyond listing RELATED_TOOLS, so it stops short of an explicit when-not-to-use.
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 provided, the description carries the full burden. It discloses that the tool runs wpscan, returns a structured result dict, and uses an optional API token. It could be more explicit about network behavior or potential impact, but the command and output structure are clear.
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 well-structured with labeled sections (TOOL_NAME, USECASE, INSTRUCTIONS, INPUT_DESCRIPTION, OUTPUT_DESCRIPTION, EXAMPLES, PREREQUISITES, RELATED_TOOLS, Args). Every section adds value without unnecessary repetition, making it both thorough and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 and no annotations, the description is remarkably complete. It covers purpose, prerequisites, step-by-step instructions, input/output formats, examples, and related tools. This provides all context an agent needs to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully compensates by explaining each parameter: 'target (WordPress URL)', 'enumerate (wpscan --enumerate arg, e.g. "vp,vt,u")', and 'api_token (optional WPScan API token)'. Examples and defaults are also provided.
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 scans WordPress sites for vulnerabilities using wpscan, with the use case 'Enumerate vulnerable plugins/themes/users on an in-scope WordPress site'. This specific verb+resource combination distinguishes it from sibling tools like nuclei_scan or dir_bruteforce.
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?
Provides explicit instructions ('Ensure host is in scope, Provide the site URL, Optionally set enumerate options/API token'), prerequisites ('Host authorized and in scope'), and related tools (nuclei_scan, dir_bruteforce). This clearly guides when and how to use the tool.
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:

[![kali-mcp-server MCP server](https://glama.ai/mcp/servers/bsahane/kali-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/bsahane/kali-mcp-server)

Score Badge

Copy to your README.md:

[![kali-mcp-server MCP server](https://glama.ai/mcp/servers/bsahane/kali-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/bsahane/kali-mcp-server)

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/bsahane/kali-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server