Tengu

by rfunix

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation3/5
There is notable overlap among tools (e.g., nmap_scan, masscan_scan, rustscan_scan; ssl_tls_check and testssl_check; ffuf_fuzz, gobuster_scan, feroxbuster_scan). Descriptions clarify each tool's unique implementation and use case, but the volume of near-equivalent options can cause misselection without careful reading.
Naming Consistency2/5
Names follow no consistent pattern. Some are external-tool + suffix (nmap_scan, subfinder_enum), others are descriptive actions (analyze_headers, validate_target, cve_lookup). Mixed conventions and inconsistent use of _scan, _enum, _check, _check, etc., make tool names unpredictable.
Tool Count2/5
80 tools far exceeds the typical well-scoped range. While the pentesting domain is broad, many tools are near-duplicates (multiple port scanners, multiple SSL/TLS checkers, multiple content discovery fuzzers), indicating the set could be consolidated or justified only by an extremely broad scope.
Completeness4/5
The tool set covers an impressive range: recon, scanning, web vulnerabilities, exploitation (Metasploit, SQLMap, etc.), post-exploitation (Impacket, BloodHound), cloud security, wireless, OSINT, and reporting. Minor gaps exist (e.g., no packet capture/analysis tool, no mobile application testing), but the surface is largely complete for a comprehensive pentest server.
Average 4.4/5 across 80 of 80 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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 passing
This repository is licensed under MIT License.
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

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 does disclose the two core behaviors (request new Tor circuit, rotate User-Agent) and the return dictionary, which is helpful. However, it does not mention side effects, prerequisites (e.g., Tor must be running), or whether this affects subsequent operations, leaving notable gaps.
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 for the action, a structured Args list, and a Returns line. Every element serves a purpose, and the action is front-loaded, making it easy to parse quickly.
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 simple two-parameter tool, the description adequately covers the operation, parameters, and return format. It omits operational prerequisites or warnings about side effects, but the presence of an output schema likely covers return details, so the description is nearly complete despite these minor gaps.
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 has 0% description coverage, so the description must compensate. The Args section restates the parameter names ('Tor control port', 'Tor control password') and includes the default for port, which is already in the schema. This adds minimal semantic value beyond what the parameter names imply.
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 action ('request new Tor circuit and rotate User-Agent') and the resource ('identity'), making the purpose specific and actionable. However, it does not explicitly distinguish this from sibling tools like tor_new_identity, so it falls short of the top score.
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?
There is no explicit guidance on when to use this tool versus alternatives. The only hint is the action itself, which implies usage, but without specific conditions, exclusions, or mention of alternative tools like tor_new_identity, the agent lacks decision-critical 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 carries the full burden. It mentions the need for a control port and password, implying authentication requirements, and states the return format. However, it does not disclose potential side effects like disrupting existing circuits or requiring Tor to be running with the control port enabled.
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 an Args section and a Returns section. It is concise and avoids unnecessary words, though the opening sentence could be slightly more informative.
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?
The tool is relatively simple, and the description covers its input and output. However, it omits important context such as prerequisites (e.g., Tor must be running, control port open) and the impact on existing connections, which would be useful for an agent to invoke 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?
The description adds some meaning beyond the schema by clarifying that control_port is the Tor control port and control_password comes from torrc. However, the schema already provides defaults, and the added value is minimal, so a baseline 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 tool requests a new Tor circuit via the NEWNYM signal, which is a specific verb+resource. However, it does not distinguish itself from the sibling tool 'rotate_identity', which likely serves a similar purpose.
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 'tor_check' or 'rotate_identity'. The description only explains what the tool does, not the context or prerequisites for invoking it.
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 full behavioral burden. It discloses rate limiting and the allowed_hosts requirement, which is useful, but does not mention network noise, external dependencies, or failure behavior. This is partial 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 well-structured with an intro, Args list, Returns section, and Notes. It is not overly verbose, though it repeats some defaults already present in the schema. All sections are useful 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 complexity and output schema, the description covers usage, parameters, return type, and key constraints. It lacks discussion of alternative tools and some edge cases, but is fairly complete for a scanning tool.
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 0%, so the description compensates by explaining all 7 parameters with one-line definitions and examples (e.g., extensions, status_codes defaults). This adds meaning beyond the schema, though some nuances like extension format are only hinted.
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 first sentence 'Brute-force directories, files, and virtual hosts using Gobuster' is a clear verb+resource statement. It covers the main use cases but does not explicitly distinguish from sibling tools like feroxbuster_scan or ffuf_fuzz, though the mode parameter adds DNS subdomains.
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 provides no guidance on when to use this tool versus alternatives like feroxbuster_scan or ffuf_fuzz. It only lists constraints (allowed_hosts, rate limiting) and mode descriptions, which are more prerequisites than usage direction.
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 the full burden of behavioral disclosure. It mentions that OWASP ZAP must be running and requires environment variables, but it does not state whether the crawl is a read-only operation, potential side effects (e.g., sending requests to target), time expectations, or what happens on failure. This is a significant gap for a tool that actively interacts with a target.
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 summary, args, returns, and note sections. It is appropriately sized and front-loaded with the main purpose. Minor redundancy exists between the first two sentences ('Spider/crawl...' and 'Discovers all links...'), preventing a perfect score.
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?
The tool is a crawler with four parameters and an output schema, and the description covers its basic purpose, prerequisites, and parameter defaults. However, it lacks information about error handling, failure modes (e.g., if ZAP is unreachable), and any caveats about crawl behavior. While the output schema likely covers return values, the description doesn't provide enough context for an agent to fully understand the tool's operational bounds.
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 0%, so the description must compensate. It provides explanations for max_depth (default 5), wait_for_completion (wait for spider to finish), and timeout (override scan timeout in seconds). However, it does not explain the URL format or behaviors when timeout is null or when wait_for_completion is false. The parameter semantics are adequate but not comprehensive.
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: spider/crawl a web application using OWASP ZAP, discovering links and URLs. It identifies the specific resource (OWASP ZAP) and the action, and notes it's typically the first step before an active scan. However, it doesn't explicitly differentiate from other spider/crawl tools like katana_crawl or feroxbuster_scan, so it's not 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 clear usage context: 'This is typically the first step before an active scan,' which implies using it before zap_active_scan. It also lists prerequisites (ZAP running, environment variables). It doesn't explicitly mention when to use alternatives or when not to use this tool, 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.
Behavior2/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 output fields but does not mention safety behavior, side effects, or external network calls. This leaves the agent uncertain whether the tool makes outbound requests or is strictly local.
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, clear structure, and no redundant text. The output description adds useful details without bloat.
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 zero-parameter tool with an output schema, the description explains the check scope and return values. It could mention prerequisites or usage context, but for this simple tool it is largely 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?
There are zero parameters, so the description inherently cannot add parameter meanings. The baseline of 4 applies due to no parameters.
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 'Check' and identifies the resource 'current anonymity level', specifying IP exposure, DNS leaks, and proxy headers. It clearly distinguishes from sibling tools like proxy_check and tor_check by focusing on the overall anonymity assessment.
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?
There is no explicit guidance on when to use this tool versus alternatives, such as proxy_check or tor_check. The description implies its usage but does not state scenarios, exclusions, or conditions.
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 the full burden for behavioral disclosure. It mentions that passwords are 'redacted in logs', which is a useful transparency detail, but it does not state whether the tool is read-only, the network impact, authorization requirements, or potential side effects. The 'Returns' section focuses on output rather than behavioral traits.
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 and well-structured with an Args/Returns format. It avoids unnecessary verbiage and every line adds value. Slightly longer than necessary due to listing all parameters, but this is justified given the tool's complexity.
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, parameters, and return values, which is fairly complete for a complex tool with 7 parameters. It lacks usage guidance and edge-case behavior, but the presence of an output schema (as noted in context) reduces the need for detailed return documentation. Overall it provides enough context for a capable agent.
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 has 0% description coverage, so the description fully compensates by providing clear explanations for all 7 parameters: target, protocol, username, password, domain, modules, and timeout. It even includes example values and notes on optionality.
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 performs 'Enumerate network services and AD using NetExec', which is a specific verb+resource. It also distinguishes itself by referencing NetExec as the successor to CrackMapExec, differentiating it from other enumeration tools like enum4linux_scan and smbmap_scan.
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?
There is no explicit guidance on when to use this tool versus alternatives. While the description lists protocols and modules, it does not mention scenarios where nxc_enum is preferred over other AD/service enumeration tools. No exclusions or alternative tool names are 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?
With no annotations, the description carries the full burden. It discloses that passwords are redacted in logs and that the target must be pre-approved, which is useful. However, it does not mention that the tool actively connects to the target, potential noise or side effects, or how timeouts are handled, which are important for an active enumeration 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 well-structured with clear sections (Args, Returns, Note), front-loaded with the primary purpose, and every sentence serves a purpose. It is concise and scannable.
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 that an output schema exists, the description appropriately summarizes return values rather than detailing them. It covers prerequisites, redaction behavior, and parameter purposes. It lacks comparison to alternatives and more on timeout semantics, but for a moderate-complexity scan tool, it is sufficiently 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?
Schema description coverage is 0%, and the description compensates by explaining each parameter: target (IP/hostname on SMB ports), username (optional for authenticated enumeration), password (redacted), and timeout (override default). This adds meaningful context beyond the schema's raw type definitions, though it could provide more details on format constraints.
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: 'Enumerate SMB/NetBIOS information using enum4linux-ng' and lists returned data (users, groups, shares, password policy). It uses a specific verb and resource, and the tool name itself differentiates it, but it doesn't explicitly contrast with sibling SMB tools like smbmap_scan or nxc_enum.
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 (requires SMB access on port 139/445, target must be in allowed_hosts) but does not offer explicit when-to-use vs alternatives or when-not-to-use. Usage is implied for SMB enumeration, but no selection guidance is provided relative to similar tools.
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 states the return format ('name, rank, and description'), but does not disclose any limitations, prerequisites, or potential side effects, which are minimal for a search 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 concise and well-structured, with a one-sentence purpose and labeled Args/Returns sections. Every sentence provides useful information without redundancy.
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 simple search tool with an output schema, the description covers the core functionality, parameters, and return values. It lacks only non-critical details like error handling or result limits, so it is nearly 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 description fully explains both parameters with examples and enumerates allowed module_type values, compensating for the 0% schema coverage. It adds meaning beyond the raw schema types.
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 'Search for Metasploit modules matching a query' with a specific verb and resource. It distinguishes itself from sibling tools by focusing on Metasploit modules, though it does not explicitly contrast with similar search tools like searchsploit_query.
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?
There is no explicit guidance on when to use this tool versus alternatives like searchsploit_query or cve_search. The examples (e.g., 'eternalblue') imply vulnerability research context, but no when/when-not guidance 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?
With no annotations, the description carries the full burden. It discloses that credentials must be configured, that scans take 5-30 minutes, and that it returns a summary of findings. However, it does not mention whether the tool is read-only, any potential side effects, or behavior on failure. These are notable gaps for an audit 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 concise and well-structured: a summary sentence, a brief explanation of what Prowler does, a clear list of parameters, a returns note, and a note on requirements. Every sentence adds relevant information without redundancies.
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 the tool's purpose, required credentials, parameter semantics, expected output, and runtime. It lacks details on failure modes or specific formatting of the returned summary, but the presence of an output schema mitigates the need for elaborate return documentation. Overall, it is sufficiently complete for an agent to call 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 description includes an Args section that explains the semantics of all six parameters, filling the gap left by the input schema's 0% description coverage. It clarifies that profile is for AWS, project for GCP, subscription for Azure, report_dir for report output, and timeout for overriding duration. This fully compensates for the schema's lack of 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 purpose: 'Perform a cloud security audit using Prowler' and elaborates on what Prowler does (checks cloud configurations against compliance frameworks). However, it does not explicitly differentiate from sibling tools like scoutsuite_scan or checkov_scan, which also perform cloud security audits.
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 provides context about prerequisites (credentials) and duration (long-running) but gives no guidance on when to choose this tool over alternatives. It does not mention any exclusions or when this tool is the preferred choice among siblings.
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 discloses several behavioral traits: it queries the NVD database, caches results locally for 24 hours to respect API rate limits, and warns that the parameter must be named 'keyword' not 'query'. These go beyond a generic search description.
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 somewhat lengthy but well-structured with an important note up front and a clear Args/Returns format. Most sentences add necessary detail, though the keyword parameter is mentioned twice redundantly.
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 an output schema exists, the description adequately covers parameter semantics, defaults (implicit via schema), and behavior. It does not clarify whether parameters can be combined or if no parameters returns all CVEs, but it is fairly complete for a search 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 0% description coverage, so the description must compensate. It explains every parameter with examples, constraints (e.g., max_results max 100, severity values), and meaning for cpe_name, days_back, etc., adding significant value 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 the tool searches CVEs by keyword, product, CPE, or severity, with specific verbs and resource. However, it does not explicitly distinguish itself from the sibling 'cve_lookup' tool, so it lacks sibling differentiation.
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 gives context (queries NVD, results cached) but does not say when to use this tool versus alternatives like 'cve_lookup' or 'searchsploit_query'. There is no explicit when-to-use or alternative 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?
No annotations are provided, so the description must carry the behavioral disclosure burden. It discloses that it uses dictionary attacks via John or Hashcat, explains the 'auto' tool preference order, and warns about authorized use only. It does not mention potential resource usage, prerequisites, or side effects, leaving some gaps in transparency. Overall, it provides moderate behavioral context.
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-organized and front-loaded, starting with a clear one-sentence purpose followed by an important naming note. The Args section is concise and informative, and the notes add valuable caveats. Slight repetition of the hash_value naming warning occurs, but it reinforces a critical detail without being 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 presence of an output schema and the detailed parameter explanations, the description is fairly complete. It covers the tool's purpose, parameters, usage notes, and ethical considerations. It lacks explicit alternative tool guidance and some operational details, but for a hash cracking tool, it provides sufficient context 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema itself provides no descriptions (0% schema coverage), but the tool description thoroughly explains every parameter with defaults and examples. For instance, hash_value is accompanied by a critical naming note and an example, and tool_preference is explained with its enum values. This fully compensates for the missing schema descriptions, making parameter semantics excellent.
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 'Attempt to crack a hash using a dictionary attack,' specifying the verb, resource, and method. It mentions the underlying tools (John the Ripper, Hashcat), which clarifies its function. However, it does not explicitly differentiate itself from sibling tools like hydra_attack or hash_identify, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context, such as 'Only use for authorized password recovery or testing purposes' and notes that dictionary attacks may not work against strong passwords. It also advises that hashcat is preferred for GPU-accelerated cracking. However, it does not explicitly state when to use this tool versus alternatives like hash_identify or hydra_attack, so the guidance is implied rather than explicit.
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 takes on the burden of behavior disclosure. It mentions prerequisites and allowed_hosts restrictions, and the 'analysis' nature implies a read-only operation, but it does not explicitly state safety, whether it sends large traffic, or any side effects. It adds useful context but not full 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 well-structured with clear sections (Args, Returns, Note) and is front-loaded with the tool's purpose. It is slightly longer than a minimal description, but each sentence adds value—the note about allowed_hosts and PATH is essential operational information. 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?
Given the presence of an output schema and 4 parameters, the description covers the essential context: what it does, prerequisites, target constraints, and output type. It could mention that it is a passive network scan or how severity relates to testssl.sh output, but overall it is sufficiently complete for an agent to invoke the tool correctly.
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 has 0% description coverage, but the description's Args section fully compensates by explaining each parameter: host, port (with default), severity_threshold (with enumerated values), and timeout (unit and purpose). This adds clear meaning beyond the schema's bare 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 performs comprehensive SSL/TLS analysis using testssl.sh, and lists specific vulnerability checks (BEAST, BREACH, CRIME, etc.) that distinguish it from generic SSL/TLS tools. It also references sslyze as a complement, making the tool's specific value clear.
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 says it 'complements sslyze with additional checks' but does not explicitly state when to choose this over sslyze or the sibling ssl_tls_check. It provides operational prerequisites (testssl.sh in PATH, allowed_hosts) which imply usage context, but lacks explicit exclusion or alternative guidance.
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 important behavioral details: password is redacted in logs, hashes format is LM:NT, null session support, and the allowed_hosts constraint. This goes beyond a simple 'lists shares' statement and gives the agent a clearer picture of side effects and requirements.
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 'Args', 'Returns', and 'Note' sections, making it easy to scan. It is slightly redundant in the opening sentences ('Enumerate SMB shares...' and 'smbmap lists available SMB shares...'), but overall it is appropriately sized and every section serves a purpose.
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 (8 params, optional recursion, output schema exists), the description covers the essential context: what it returns, the target constraint, and authentication options. It does not describe error behavior or edge cases, but the output schema and sufficient parameter detail make it complete enough for correct invocation.
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?
Despite 0% schema description coverage, the description explains all 8 parameters with clear meanings, defaults, and formats. For example, it specifies the hash format (LM:NT) and what null session means for the username field. This fully compensates for the lack of schema descriptions and adds significant value.
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: 'Enumerate SMB shares and permissions using smbmap.' It uses a specific verb ('Enumerate') and resource ('SMB shares and permissions'). However, it does not explicitly differentiate from sibling tools like enum4linux_scan or nxc_enum, so it doesn't fully meet the 'distinguishes from siblings' criteria for 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need to enumerate SMB shares and permissions) but does not provide explicit guidance on when to prefer it over alternatives. It does mention a prerequisite (target must be in allowed_hosts) and explains optional recursive listing, but offers no exclusions or comparisons.
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 present, the description must carry the full burden. It discloses that the target must be in tengu.toml allowed_hosts and that SNMP v3 needs extra auth parameters, which is helpful. However, it does not explicitly state that the operation is read-only or describe error/timeout behavior, leaving a notable gap.
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 Args, Returns, and Notes sections, and the introductory SNMP context earns its place. It is slightly verbose but every sentence contributes meaningful information, making it efficient without being terse.
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 tool with 5 parameters, no annotations, and an output schema, the description covers purpose, parameter semantics, return value summary, and critical operational notes. The only missing piece is explicit guidance on when to select this tool against sibling scanning tools.
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 compensates by explaining every parameter's meaning, default, and acceptable values (e.g., community default 'public', version '1', '2c', or '3', oid default '.'). This provides semantic value well 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 opens with 'Enumerate SNMP information from a network device using snmpwalk,' which clearly names the verb, resource, and tool. It further explains SNMP's typical use cases (device config, interfaces, routing tables), distinguishing it from sibling network scanners like nmap_scan or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The SNMP protocol explanation implies when this tool is useful (e.g., accessing device configuration), but there is no explicit statement about when to choose it over other scanning tools or when not to use it. Alternatives are not mentioned.
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 implementation details (uses sslyze Python library directly, no subprocess), expected duration (30-60 seconds), and implied read-only behavior through 'analyze'. It also notes the timeout parameter, which is relevant for a scan that can take a minute.
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 for checks, args, returns, and notes. It is slightly long due to the bulleted list of vulnerabilities, but all content is relevant and the front-loaded purpose statement makes it easy to scan. No wasted sentences.
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 complexity of SSL/TLS analysis and the presence of an output schema, the description covers the tool's scope (checks, inputs, return summary, performance). It could further clarify edge cases like unreachable hosts or alternative tools, but for a single-host scanner it is sufficiently 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 input schema provides only types and defaults, with no descriptions. The description fully compensates by documenting each parameter: host (hostname or IP), port (default 443), and timeout (in seconds). This exceeds what is available in the schema and gives the agent actionable guidance for invocation.
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 starts with a clear verb 'Analyze' and specific resource 'SSL/TLS configuration of a host', and enumerates concrete checks (protocol versions, vulnerabilities, cert validity). It is clearly distinct from generic scanning tools but does not explicitly differentiate from the sibling tool 'testssl_check', which likely serves a similar purpose.
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 conveys that this tool is for in-depth SSL/TLS analysis, with explicit options for host, port, and timeout. However, it does not state when to prefer this tool over alternatives like 'testssl_check' or mention exclusions (e.g., when not to use). The usage is implied rather than explicitly contrasted.
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 disclosure burden. It explains the scanning approach, parameter defaults, and return format, which adds value. However, it does not disclose potential side effects such as intrusive network requests or the need for authorization, which is notable for an active scanner.
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 clear opening sentence, a brief explanation of the template engine, a bulleted argument list, and a return-value note. Every section adds essential information without redundancy, making it appropriately sized.
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 (7 parameters, output schema, no annotations), the description covers inputs and outputs thoroughly. It explains the scan scope, filtering options, and result format. The only gap is the lack of explicit authorization/consent warnings, which is a minor omission for an active vulnerability scanner.
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 provides rich semantics for every parameter, including target, templates, severity, tags, exclude_tags, rate_limit, and timeout. It explains formats, defaults, and examples, going far beyond the bare schema definitions.
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: 'Scan a target for vulnerabilities using Nuclei template engine.' It further clarifies the tool's purpose by explaining it detects vulnerabilities, misconfigurations, exposed panels, CVEs, and more, distinguishing it from sibling scanners like nmap_scan or zap_active_scan.
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 clear context that this tool scans web applications and network services, but does not explicitly state when to use it instead of other vulnerability scanners (e.g., nikto_scan, zap_active_scan) or include exclusions. Usage is implied by the detailed functionality, but no alternative guidance is 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 must disclose behavioral traits. It explains the computation (CVSS + context) and the return format, but does not mention side effects, permissions, or whether the tool is read-only. Since it is a calculation tool, the lack of explicit side-effect disclosure is a minor gap, but not a critical omission.
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. It front-loads the purpose, then clearly organizes Args and Returns in separate sections. Every sentence contributes useful information with no fluff or repetition.
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 tool has an output schema, so return values are additionally specified there. The description itself provides enough context for a relatively simple calculation tool: it names inputs, a key influence (context), and the output components. It does not address edge cases or error scenarios, but for this complexity level, the coverage is adequate.
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. It does so effectively with an 'Args' section explaining both parameters: 'findings' as a list from any Tengu tool, and 'context' with examples and explanation of its effect on risk multipliers. This adds meaningful semantic meaning beyond the bare 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 opens with a specific action: 'Calculate a comprehensive risk score based on CVSS scores and engagement context.' This clearly identifies the tool's purpose and differentiates it from sibling tools, which are primarily scanning or attack tools. The reference to 'findings from any Tengu tool' also establishes its role as an aggregation/analysis layer.
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 that the tool is used after collecting findings from other tools, but it does not explicitly state when to use this tool versus alternatives such as correlate_findings. It provides context about the input ('findings from any Tengu tool') but lacks clear guidance on selection conditions or exclusions.
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 burden. It indicates a read-only check via 'Check' and 'retrieve' and lists returned fields, which is helpful. However, it does not disclose potential side effects, whether identity is rotated, or behavior when Tor is not connected.
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 concise sentences: the first states the purpose, the second lists return fields. It is front-loaded, clear, and contains no filler or repetition.
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 low complexity (no parameters, output schema present), the description is complete: it states what the tool does and what it returns. No additional context is necessary for safe 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 tool has zero parameters, so the input schema is empty and there is no need for parameter documentation. The baseline score for no-parameter tools is 4, and the description correctly focuses on behavior and output.
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?
Description uses a specific verb ('Check') and resource ('Tor connectivity'), and clearly states it retrieves exit node IP and country along with real IP. This distinguishes it from sibling tools like tor_new_identity and rotate_identity, which focus on identity changes.
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 the tool is for verifying Tor connectivity and exit node details, but it does not explicitly state when to use it versus alternatives like check_anonymity or proxy_check, nor does it mention prerequisites such as Tor being active.
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 carry the full burden. It discloses that the tool crawls the site, generates network traffic, and respects the allowed_hosts constraint. It also notes depth-related traffic concerns. However, it does not cover error handling, robots.txt behavior, or potential side effects beyond creating the output file, leaving some behavioral traits undisclosed.
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 clear one-sentence summary, followed by compact Args, Returns, and Notes sections. Every sentence adds relevant information without redundancy. It is concise yet comprehensive.
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 (6 params, no annotations, output schema present), the description covers purpose, all parameters, return values, usage constraints, and a caution about traffic. It is nearly complete, though it could mention prerequisites like authentication but the allowed_hosts note covers access control. Overall it provides sufficient context for an agent to invoke it correctly.
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 provides no descriptions for parameters, so the description's Args section fully compensates by explaining each parameter's meaning and defaults. It adds value like depth max 5 and default word length, going beyond the raw schema. This effectively documents all 6 parameters.
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: 'Generate a custom wordlist by crawling a website with CeWL.' It clearly states the tool's function and distinguishes it from sibling crawling or scanning tools by focusing on wordlist generation for password attacks. The purpose is unmistakable.
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 implies usage for creating organization-specific wordlists for password attacks and provides clear context through notes about cautious depth and allowed_hosts requirements. However, it does not explicitly name alternative tools or state when not to use this tool, so it lacks explicit exclusion 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 provided, the description carries the full burden of behavioral disclosure. It does disclose that the tool writes a report to report_dir/scoutsuite-report/, requires pre-configured credentials, and is long-running. However, it does not explicitly state whether the audit is read-only or whether it makes any changes to the cloud environment, which is a notable omission for a security audit 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 well-structured with clear Args, Returns, and Note sections. Every line provides useful information, no filler or redundancy. It is front-loaded with the purpose and efficiently organized.
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 (multi-cloud, multiple parameters, long-running) and lack of annotations, the description covers all essential contextual aspects: credential requirements, output location, time expectations, and return value summary. The presence of an output schema partially reduces the need to explain returns, but the description still gives a concise overview.
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 has 0% description coverage, so the description must compensate. It does so thoroughly: each parameter is explained, including which provider it applies to (profile for AWS, project for GCP, subscription for Azure) and valid values for provider. Even timeout is mentioned, though its unit is not specified. This adds significant meaning beyond the bare 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 opens with 'Perform a cloud security audit using ScoutSuite,' which is a specific verb+resource statement. It clearly identifies the tool's function and differentiates it from sibling tools like prowler_scan by naming the actual technology (ScoutSuite) and the domain (cloud security audit).
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 (e.g., cloud credentials) and caveats (long-running, 5-30 minutes) but does not explicitly say when to use this tool versus alternatives like prowler_scan or checkov_scan. There is no mention of specific scenarios where ScoutSuite is preferred or when another tool should be chosen.
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 takes on the burden of disclosing behavior. It explains aggression level consequences ('Aggression 3+ sends many requests and may trigger WAF/IDS alerts') and the allowed hosts constraint. It also describes the return value. This is solid behavioral disclosure, though it stops short of detailing error handling or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose sentence, separate Args/Returns/Note sections, and no filler. Each line provides necessary information, making it easy for an agent to parse and act 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?
Given the tool has an output schema and three well-documented parameters, the description is largely complete. It covers purpose, parameters, return values, and important constraints like allowed hosts and potential WAF alerts. The only minor omission is explicit mention of error handling, but overall it is sufficient for correct invocation.
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 provides no descriptions (0% coverage), but the description fully compensates. Each parameter is explained: target with an example URL, aggression with a range and meaning, timeout as an override. The notes further clarify aggression behavior, giving the agent a complete understanding of parameter semantics.
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: 'Detect web technologies, CMS, frameworks, and WAF using WhatWeb.' This provides a specific verb and resource. However, it does not explicitly differentiate from sibling tools like wafw00f_scan or nikto_scan, so it's clear but lacks sibling distinction.
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 operational context through notes about aggression levels and allowed hosts, e.g., 'Aggression level 1 sends a single request (safe for production)' and 'Target must be in tengu.toml [targets].allowed_hosts.' While this gives useful context, it does not explicitly state when to choose this tool over alternatives or what not to use it for.
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 behavioral constraints: 75 daily API requests with free token, target must be in allowed_hosts, and a timeout parameter. However, it does not explicitly state that the scan is non-destructive or could generate network traffic against the target, which might be relevant for authorization. It adds some useful context but not a complete behavioral profile.
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 Args, Returns, and Note sections, and the main purpose is stated in the first sentence. It is slightly longer than strictly necessary but every sentence delivers useful information about parameters, prerequisites, or output. No filler or redundant content.
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 has 5 parameters, an output schema, and no annotations, the description covers the essential context: what it does, how to invoke each parameter, what it returns, and important notes about API token and target authorization. It does not discuss potential side effects or examples of full usage, but with an output schema present this is sufficient. The note about allowed_hosts is a critical operational 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%, yet the description's Args section fully explains every parameter: url with example, enumerate with specific option abbreviations, api_token with recommendation, threads with default/max, and timeout with default behavior. This entirely compensates for the schema's lack of descriptions, providing actionable semantics for each 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 a specific verb and resource: 'Scan a WordPress site for vulnerabilities, plugins, themes, and users using WPScan.' This clearly identifies the tool's function and scope, and distinguishes it from sibling scanners like nikto_scan or nuclei_scan which target broader web infrastructure. The enumeration options further clarify its exact 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 contextual guidance: prerequisites like the WPScan API token and the requirement that the target be in tengu.toml allowed_hosts. It implies use for WordPress targets but does not explicitly state when to use this tool over alternatives or when not to. The context is clear enough to make appropriate use decisions, though exclusions are not directly stated.
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 is passive ('without transmitting any packets'), requires monitor mode and root/sudo, captures wireless frames, and must only be used with authorization. It also mentions underlying tool (airodump-ng). It doesn't describe exact error behavior if prerequisites are missing, but covers key behavioral aspects.
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 (intro, Args, Returns, WARNING) and is front-loaded with the core purpose. It is not overly long, but the WARNING section repeats the legal authorization point, which is slightly redundant. Still, every line serves a purpose.
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 tool with no annotations and moderate complexity, the description covers purpose, usage prerequisites, parameters, return values, and legal/ethical warnings. It lacks mention of what happens if the interface is not in monitor mode (error handling), but the core operational context is well-covered.
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% coverage, but the description compensates by explaining each argument: interface ('Wireless interface in monitor mode e.g. wlan0mon'), scan_time ('Duration in seconds to capture'), and timeout ('Override default timeout'). The timeout description is somewhat generic, but overall it adds significant meaning beyond the bare 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 the tool's purpose: 'Passively scan for wireless networks using airodump-ng... without transmitting any packets.' This specific verb+resource combination (passively scan + wireless networks) distinguishes it from sibling tools like nmap_scan and masscan_scan, which target wired/network 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?
It provides clear context on when to use the tool: 'monitor mode required' and 'passively capture wireless network information.' It also lists prerequisites (root/sudo, monitor mode) and legal authorization. However, it does not explicitly name alternatives or state 'use this for wireless, not for wired,' so it stops short of full when-not 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 must carry the full burden. It specifies the output (attack chains, risk score, remediation recommendations) and mentions required input fields, but does not disclose potential side effects (e.g., whether it makes network calls) or limitations (e.g., what happens if findings are malformed). This is acceptable but not rich.
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 and front-loaded with the purpose in the first sentence. The Args and Returns sections are concise and informative, with no superfluous content. Every line adds value for the agent.
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 and the presence of an output schema (though not shown), the description covers the essential aspects: input format, processing logic, and output. It lacks details on edge cases or handling of partial data, but remains sufficient for an agent to understand the tool's role and invoke it 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 is minimal, containing only an array of arbitrary objects. The description compensates by specifying that the array contains Finding objects and enumerating expected fields (severity, owasp_category, cve_ids, tool). This adds significant meaning beyond the schema, guiding correct invocation.
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 verb and resource: 'Correlate multiple findings to identify attack chains and compound risks.' This distinguishes it from sibling tools, which primarily perform individual scans or checks. The opening sentence makes the tool's 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 explains that the tool analyzes findings from multiple tools to identify patterns and compound risks, implying it should be used after collecting findings from various scanners. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to determine suitability.
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 burden. It discloses that the tool makes TGS requests (network behavior), warns about EDR/SIEM detection, notes password redaction in logs, and requires an allowed host – all useful behavioral context. It does not detail side effects or error scenarios, but the key risk is covered.
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 clear introductory sentence, an Args section that is concise, a Returns note, and a WARNING section. No redundant text; each sentence provides necessary 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?
The description covers the core function, expected outputs (service accounts, SPNs, TGS hashes), and important warnings (detectability, credential requirement, allowed hosts). However, it does not explicitly state that either password or hashes must be supplied (both are optional in the schema) or clarify the default timeout value. Given the output schema exists, this is adequate but not exhaustive.
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 has zero descriptions (0% coverage), but the description explains every parameter: target (DC IP), domain (AD domain), username (valid domain user), password (authentication), hashes (NTLM format LM:NT, alternative), and timeout (override default). This fully compensates 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 clearly states it performs Kerberoasting using Impacket GetUserSPNs, specifically requesting TGS tickets for service accounts with SPNs. This distinguishes it from sibling tools like impacket_secretsdump or psexec.
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?
It outlines prerequisites (valid domain credentials, allowed target) and the outcome (offline-crackable hashes), but does not explicitly compare against alternatives or state when not to use it. The usage context is implied rather than fully specified.
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 disclosure burden. It mentions JavaScript rendering, form submission, scope-aware crawling, and timeout override, but does not disclose potential network load/noise, authentication requirements, or a safety profile. It implies active crawling but could be more explicit about impact.
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?
Well-structured: one-sentence summary, brief tool context, clear argument list, return description, and a note. No fluff; every line adds 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?
Description provides the core function, tool background, parameter semantics, return value summary, and an important scope constraint. It doesn't elaborate on output schema (but that's handled by output schema) or mention alternatives, but overall it's sufficiently complete for an agent to select and 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?
Schema has zero descriptions, but the Args section fully explains every parameter: target, depth (with default/max), concurrency (with default/max), js_crawl (purpose), and timeout (meaning). This directly compensates for the schema's lack of 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 opens with a specific action verb ('Crawl a web application to discover endpoints and URLs') and names the underlying tool (Katana). It further distinguishes from sibling scanners by noting JavaScript rendering, form submission, and scope-aware crawling capabilities, which are unique differentiators.
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 first sentence clearly states the tool's purpose (crawling to discover endpoints and URLs). The note about target needing to be in allowed_hosts is a clear prerequisite. However, it does not explicitly compare to alternatives or provide when-not-to-use scenarios.
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 and does well by disclosing what the tool checks (reachability, latency, exit IP, anonymity level) and what it returns. It implies network testing behavior and gives a clear output structure, though it omits potential side effects like network latency or remote service load.
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 compact and front-loaded, with a purpose sentence followed by clearly separated Args and Returns sections. Every line adds value and there is no redundant or filler content.
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 tool with no annotations and an output schema present, the description is complete: it explains the input with examples, the operations performed, and the exact return fields. An agent has sufficient context 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by listing the parameter 'proxy_url' and providing concrete examples with supported schemes (socks5://, http://). This adds meaning beyond the raw schema, though it does not detail validation constraints beyond the examples.
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 with a specific verb ('Validate') and resource ('proxy server'), listing concrete checks: reachability, latency, exit IP, and anonymity level. This distinguishes it from siblings like check_anonymity or validate_target.
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?
Usage is implied by the purpose ('Validate a proxy server'), but the description does not explicitly say when to choose this tool over alternatives or mention any exclusions. No guidance is given relative to sibling tools such as check_anonymity or tor_check.
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 present, the description carries the full burden. It discloses that it queries a local offline database and returns a list with path/type/platform. This is adequate transparency for a read-only search tool, but it omits prerequisites (e.g., SearchSploit installed, database updated) and does not discuss edge cases like empty results or malformed queries.
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-organized: a one-line purpose, a short sentence on use case, an Args block with examples, and a Returns note. Every sentence earns its place. It is front-loaded with the primary action and remains concise while covering necessary details.
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 is comprehensive for a search tool: it states purpose, usage context, all parameters, and return value shape. The only gap is a missing note about installation/update prerequisites for SearchSploit, which is a minor omission given the otherwise complete picture.
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 has 0% description coverage, but the description compensates fully with an 'Args:' section explaining each parameter with examples ('Apache 2.4.49', 'CVE-2021-44228'), clarifications (exact_match, exclude_dos recommended), and a list of valid type_filter values. This adds substantial 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 'Search the ExploitDB offline database using SearchSploit' and further explains 'Queries the local ExploitDB database for exploits matching the search terms.' This is a specific verb+resource pairing that distinguishes it from sibling tools like msf_search or cve_lookup.
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: 'Useful for quickly finding public exploits for identified software versions.' This gives the agent a strong signal for when to use this tool. However, it does not explicitly name alternatives or say when not to use it, so it misses the full exclusions/alternatives 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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. The term 'scan' implies a read-only operation, but the description does not explicitly state that it does not modify the target, nor does it mention potential network activity, authentication needs, or rate limits. The timeout override hints at possible long-running operations but omits safety details.
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 efficient: a one-sentence purpose statement followed by a structured Args and Returns list. Every line provides necessary information without fluff. It is well-organized and front-loaded, making it easy for an agent to parse quickly.
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 4-parameter tool with an output schema, the description covers purpose, all parameters, and return values (list of secret findings with detector type, verification status, source location). It could mention edge cases like GitHub authentication or large repository performance, but the existing details are sufficient for most usage scenarios.
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), but the Args section in the description explains all four parameters with meaningful details: target maps to scan modes, scan_type defines the three modes, branch is optional with a default, and timeout overrides the default. This fully compensates for the schema gap and adds practical guidance.
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 'Scan for leaked secrets and credentials using TruffleHog', which uses a specific verb and resource and clearly distinguishes the tool from other security scanners among siblings (e.g., gitleaks_scan). It also enumerates the scan modes (git, filesystem, github), making its scope explicit.
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 different target types for each scan_type (e.g., 'target: Git repository URL for git/github mode or local directory path for filesystem mode'). However, it does not name alternatives like gitleaks_scan or explicitly state when not to use this tool, so it lacks explicit 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 provided, the description carries the full burden. It discloses important behavioral traits: active mode 'sends DNS queries directly to target's nameservers' and the allowed_hosts requirement. This adds meaningful context beyond a generic enumeration tool, though it could mention more (e.g., rate limits, resource usage).
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 Args, Returns, and Note sections. Every sentence earns its place, and the front-loaded purpose sentence immediately conveys what the tool does. It is succinct without sacrificing essential details.
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 the tool's purpose, parameters, return values, mode differences, and a critical prerequisite. Given the tool's complexity (3 parameters, no annotations, output schema present), 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 explain all parameters. It does so thoroughly: domain with example, mode with definitions, timeout with units and default behavior. This fully compensates for the schema's lack of 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 purpose: 'Enumerate subdomains and map attack surface using Amass.' It identifies the specific resource (subdomains) and implies a broader scope (attack surface). However, it does not explicitly differentiate from sibling tools like subfinder_enum or dns_enumerate, 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 clear context on when to use each mode: passive (no direct interaction) vs active (DNS brute-force + zone walk). It also notes a prerequisite (allowed_hosts). However, it lacks explicit alternatives or when-not-to-use guidance, which would be 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, the description carries the full burden. It discloses key behavioral traits: uses httpx directly, pure Python, performs a single GET request, and returns scores/grades/recommendations. This is more transparent than many tools, though it doesn't explicitly state it is read-only or non-destructive. The single GET detail effectively communicates the operational behavior.
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: a clear one-line purpose, a brief elaboration, then sections for Args, Returns, and Note. Every sentence adds value, and it is concise without being too short. The organization makes it easy to scan.
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 the tool's purpose, how it works, parameters, and return value. Given that an output schema exists and the tool is a simple read-only analyzer, the description is sufficiently complete for an agent to use it correctly. No critical information is missing.
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%, and the description compensates by explaining each parameter in the Args section: url, follow_redirects, and timeout_seconds. It adds meaning beyond the bare schema types/defaults, clarifying that follow_redirects affects destination and timeout_seconds controls request duration.
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: 'Analyze HTTP security headers for a web application.' It further specifies it checks for critical security headers and flags information disclosure headers, which is specific and distinguishes it from sibling tools like ssl_tls_check (SSL/TLS) or whatweb_scan (technology detection).
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 through its stated functionality (e.g., 'Checks for the presence and correctness of critical security headers'), but it does not explicitly state when to use this tool versus alternatives or when not to use it. Sibling tools include many scanners, but no direct alternative for header analysis; still, no explicit usage guidance is provided.
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 covers the expected output (DNS records, zone transfer results, raw output), a failure mode (axfr may fail), and a prerequisite (allowed_hosts). It does not disclose timing or rate-limit behavior, but for a read-only recon tool this is solid coverage.
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 clear sections (capabilities, Args, Returns, Note) and is appropriately sized. Each section earns its place, and the purpose is front-loaded in the first sentence.
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 having no annotations, the description provides complete operational guidance: it names the underlying tool, lists all supported scan modes, documents every parameter, and includes prerequisites plus failure caveats. With an output schema present to handle detailed return structure, nothing essential is missing.
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%, yet the description's Args section fully compensates by explaining all three parameters. Most valuably, it enumerates every scan_type value (std, brt, axfr, rvl, goo) with a short explanation, which the schema itself lacks entirely.
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 opens with 'Perform DNS reconnaissance using DNSRecon' and enumerates supported capabilities (zone transfers, brute-force, PTR lookups, standard record enumeration). It is specific about the tool and scope but does not explicitly differentiate from sibling DNS tools like subfinder_enum or dns_enumerate.
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 operational context: the target must be in tengu.toml [targets].allowed_hosts, and zone transfer (axfr) may fail if nameservers are properly configured. However, it never states when to prefer this tool over sibling DNS enumeration tools or what alternatives exist, so it lacks explicit when/when-not guidance.
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 explains the required FUZZ placeholder and automatic appending, how filter/match codes work, and default thread/rate behavior. It does not mention potential side effects like high request volume or authorization requirements, but it provides substantial operational detail.
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 clear opening summary, an Args section that explains each parameter, and a Returns section. It uses bullet-like formatting and front-loads the core purpose. Every sentence adds value and nothing is redundant.
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 (10 parameters, no schema descriptions, no annotations), the description is thorough. It covers the FUZZ substitution rule, parameter semantics, defaults, and return values, making the tool fully understandable without needing to inspect the schema or output format.
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 provides zero description coverage, but the description compensates fully by listing and explaining every parameter in the Args section, including url, wordlist, method, filter_codes, match_codes, extensions, threads, rate, headers, and timeout. This far exceeds the schema's bare structure.
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 'Fuzz directories, files, and endpoints using FFUF' with a specific verb and resource. It distinguishes itself by naming FFUF, but does not explicitly contrast with similar sibling tools like gobuster_scan or feroxbuster_scan, so it lacks direct sibling differentiation.
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: 'discover hidden files, directories, APIs, and endpoints that are not linked from the application's public pages.' It does not explicitly mention alternatives or when not to use it, but the use case is unambiguous.
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 output behavior: formats (PTES/OWASP), output types (full/executive/etc.), and the output_path behavior returning content inline if empty. It does not mention overwrite behavior or external dependencies, but is reasonably transparent for a reporting 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 a clear one-line purpose, an Args list, and a Returns section. It is slightly verbose with phrases like 'professional' and 'comprehensive' adding little, but the layout is scannable and information-dense without redundancy.
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 all parameters, return value, and report variants. With an output schema present, the return metadata is likely further specified. It lacks explicit prerequisites or side-effect warnings, but given the tool's complexity and completeness of input documentation, it is sufficiently contextual.
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 provides explanations for all 12 parameters, including valid report_type and output_format values. This fully compensates for the schema's lack of descriptions and adds meaning beyond the property names.
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 it generates a professional penetration test report, with a specific verb ('generate') and resource ('penetration test report'). It distinguishes itself from sibling scanner and enumeration tools by focusing on report creation rather than data collection.
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 implies usage after findings are collected, noting that 'findings' should be a list of finding dicts from Tengu tools. However, it does not explicitly state when not to use it or compare it to alternatives, though no sibling tool competes directly.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It usefully discloses WMI access ports, admin requirements, Event ID 4688 generation, WMI activity logs, password redaction, and the need for explicit human authorization. It does not mention limitations such as command output truncation or the exact command interpreter used.
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 summary, args list, returns section, and warnings. The first sentence is front-loaded and precise. While slightly longer than minimal, every section adds useful information and there is no filler.
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 high-risk remote command execution tool, the description is reasonably complete: it covers purpose, prerequisites, network ports, logging side effects, return behavior, and authorization requirements. It falls slightly short by not addressing authentication precedence when both password and hashes are supplied, or whether the command runs via cmd.exe or PowerShell.
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, so the description fully compensates by explaining all seven arguments. It adds meaningful details such as using '.' for local accounts, password redaction in logs, hashes format 'LM:NT' for pass-the-hash, and timeout as an override in seconds.
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: 'Execute a command remotely on a Windows host via WMI using Impacket wmiexec.' It clearly distinguishes itself from impacket_psexec by noting it is 'stealthier than psexec as it does not create a service.'
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 gives clear usage context by contrasting wmiexec with psexec and stating it avoids service creation. It also lists prerequisites such as 'admin credentials and WMI access (port 135/445)' and 'explicit human authorization.' However, it does not explicitly state when not to use this tool or mention other alternatives beyond psexec.
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 full burden. It discloses Nikto's specific checks, explains tuning categories and the default 'x6' (everything except DoS), and notes timeout override. It does not mention potential network impact or permission requirements, but overall it reveals the tool's behavior well beyond the bare action.
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 clear intro, a concise bullet-like explanation of Nikko's checks, an Args list with helpful details, and a brief Returns line. Every sentence serves a purpose, and the format makes scanning easy.
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 the tool's purpose, all five parameters, the return type (list of findings with descriptions and references), and the default tuning behavior. This is sufficient for an agent to select and invoke the tool correctly given the output schema and no annotations.
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%, yet the description compensates fully. Every parameter (target, tuning, ssl, port, timeout) is explained with e.g. tuning value mappings, default behavior, and the note that port auto-detects from URL. This adds substantial 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 opens with a specific verb and resource: 'Scan a web server for vulnerabilities using Nikto.' It further details the types of issues checked (outdated software, dangerous files, default credentials, misconfigurations), clearly distinguishing this from sibling scanners like nmap_scan or nuclei_scan.
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?
Usage context is implied by the first sentence—use this to scan web servers for vulnerabilities—but the description does not explicitly state when to prefer Nikto over alternatives (e.g., nuclei_scan, zap_active_scan) or mention any exclusions. No direct 'when/when-not' guidance is provided.
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 behavioral disclosure. It mentions prerequisites (image must be pullable or present), return format (counts and top findings), and severity filter values. It does not cover potential side effects like network calls or resource usage, but it is generally transparent 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 Args, Returns, and Note sections, and front-loads the main purpose. Some redundancy exists (severity listed in Args and repeated in Note), but every sentence carries useful information. It is not as tight as a two-sentence description but remains efficient.
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 has 4 parameters and an output schema, the description covers inputs, return summary, and a key prerequisite without over-explaining. It could mention error scenarios or network requirements, but for a moderately complex scan wrapper, it is sufficiently 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 description coverage is 0%, so the description fully compensates by explaining each parameter: target (image/path/URL), scan_type (with enum-like values), severity format, and timeout override. This meets the 'description must compensate' requirement completely.
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 container images, filesystems, or repositories for vulnerabilities using Trivy, with a specific verb and resource. It distinguishes this from sibling scanners like nuclei_scan or nmap_scan by focusing on container/artifact 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 context on what targets and scan types the tool supports (image, fs, repo, config, sbom), which implies when to use it. It does not explicitly mention alternatives or when not to use it, 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?
With no annotations present, the description carries the full burden and provides valuable behavioral notes: it uses python-whois (no subprocess/security benefit), warns about rate limits, and requires the target to be in allowed_hosts. These go beyond basic safety and give practical operational 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 appropriately sized and well-structured with Args, Returns, and Notes sections. It avoids fluff while including essential operational details. Slightly verbose due to the Notes, but every sentence 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?
For a one-parameter tool with no output schema provided, the description covers the return data, input format, prerequisites, and practical caveats. It is complete enough for an agent to use correctly, though a brief note on failure behavior would make it fully comprehensive.
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 only defines 'target' as a string with no description. The description fully compensates by defining it as 'Domain name (e.g. "example.com") or IP address' and adds the allowed_hosts constraint. Given 0% schema coverage, this is excellent compensation.
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 'Perform a WHOIS lookup for a domain or IP address' with a specific verb and resource. It further details the information retrieved (registrar, dates, nameservers, contacts), which distinguishes it from sibling tools like dns_enumerate or shodan_lookup.
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 gives clear context for usage: when you need registration data for a domain or IP. It also notes rate-limiting and the allowed_hosts prerequisite. However, it does not explicitly compare to alternatives or state when not to use this tool, but the context is sufficiently clear for a simple tool.
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 of behavioral disclosure. It notes that Arjun sends many requests and that JSON/XML modes test parameters in the request body, giving useful insight into runtime behavior. It does not cover potential auth or side effects, but the core behavior is transparent.
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 Args, Returns, and Note sections. Every sentence adds value; no redundancy or fluff. The main purpose is front-loaded, and the notes are concise but informative.
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 presence of an output schema and 4 relatively simple parameters, the description fully covers prerequisites, behavior, and parameter semantics. It even includes return value information despite the output schema existing, making it self-contained.
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 0%, so the description must explain all parameters. It does: url, method with options, optional wordlist, and timeout override. This adds meaning beyond raw types, though it omits default timeout details and wordlist format specifics.
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: 'Discover hidden HTTP parameters in web endpoints using Arjun.' This clearly distinguishes it from sibling tools like ffuf_fuzz or gobuster_scan, which focus on fuzzing or directory enumeration.
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: target must be in allowed_hosts, and it warns about rate-limited endpoints. It does not explicitly name alternative tools or state when not to use it, but the context is sufficient for selection.
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 takes responsibility for behavioral disclosure. It states it scans local files only, requires no network access, and needs no allowlist check, signaling a safe, non-exfiltrating read operation. It also describes the return grouping, adding useful behavioral context.
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 sections for Args, Returns, and Note, each adding essential information without redundancy. It is concise and front-loaded with the primary purpose, making it easy to parse quickly.
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 and the existence of an output schema, the description covers purpose, parameters, return values, and operational caveats like local-only scanning and no allowlist need. Minor omissions such as recursion behavior do not detract significantly from its usefulness.
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 has 0% description coverage, but the description fully compensates by explaining each parameter, including allowed framework values and example check IDs. This provides the semantic context the structured schema lacks, leaving no ambiguity about the arguments.
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 Infrastructure as Code for security misconfigurations using Checkov, which distinguishes it from sibling scanners focused on other targets. It lists supported frameworks, providing a precise scope and making the tool's use case immediately obvious.
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?
It provides clear context by enumerating supported IaC frameworks, implying this is the right tool for IaC security scans. However, it does not explicitly name alternative scanners or state when not to use it, so guidance is contextual but not comparative.
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 burden. It explains the return value (catalog with installation status, paths, versions) and implies a read-only, non-destructive behavior. No additional side effects or prerequisites need disclosure for a tool of this simplicity.
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: the first states the primary purpose, the second adds return details and usage context. It is concise, front-loaded, and contains no fluff.
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 zero-parameter, read-only tool with an output schema, the description fully covers what the tool does, what it returns, and when to use it. No additional context is needed.
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 zero parameters, so the baseline is 4. No parameter descriptions are needed, and the schema coverage is trivially 100%.
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 checks which external pentesting tools are installed and available, with a specific verb ('check') and resource. It distinguishes itself from sibling scanning tools by focusing on tool availability rather than performing scans.
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 by stating it is useful for diagnosing missing dependencies before starting a pentest engagement, but does not explicitly mention when not to use it or alternatives.
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 full burden of transparency. It discloses the data sources (NVD and CVE.org) and enumerates the returned fields (CVSS scores, CWE mappings, affected products, references, exploit cross-references). It does not cover potential rate limits or error behavior, but for a read-only CVE lookup this is reasonable. No contradictions with annotations exist (none provided).
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 a summary, Returns list, and Args/Returns sections. It is front-loaded with the primary purpose. However, there is slight redundancy: the first paragraph lists return items that are partially repeated in the Returns section. Still, every sentence earns its place and the length is appropriate.
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 one-parameter tool with an output schema, the description is complete. It explains the input format, the data sources, and the expected return content. There is no ambiguity about what the tool does or how to invoke it. The existing output schema covers return structure, so the description doesn't need to over-explain.
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 provides only a type 'string' for cve_id with 0% description coverage. The description compensates thoroughly by explaining the required format 'CVE-YYYY-NNNNN' and providing a concrete example ('CVE-2024-1234'). This adds essential meaning beyond the bare 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 the tool 'Fetch complete details for a specific CVE' from NVD and CVE.org, using a specific verb ('Fetch') and resource ('specific CVE'). This distinctly differentiates it from the sibling tool 'cve_search', which implies searching rather than fetching a known, single CVE.
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 explicitly says 'for a specific CVE', indicating the tool is intended for when a known CVE ID is available. It does not explicitly name alternatives or exclusions, but the word 'specific' provides clear context against the sibling search tool. The guidance is clear enough for an agent to decide when to invoke it.
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 must carry the burden of behavioral disclosure. It does so by revealing that Feroxbuster recurses by default, requires the target to be in allowed_hosts, and returns status codes, content lengths, and word counts. However, it omits potential side effects like network noise or rate limiting, so it is strong but not exhaustive.
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 clear sections (Args, Returns, Note) and front-loads the critical parameter-naming pitfall. Every sentence adds value—the comparison to Gobuster/FFuf, default recursion behavior, and allowed_hosts note are all necessary. The repeated 'target' reminder is justified given the common mistake.
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?
Despite having no annotations and no schema descriptions, the tool description covers purpose, parameters, return format, and a key prerequisite (allowed_hosts). It leverages the output schema to avoid re-explaning return fields. It falls short of a 5 by not addressing potential error conditions or edge cases like invalid wordlists, which would fully round out the context for an autonomous agent.
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 compensates by explaining every parameter with usage details, defaults, and constraints. For example, it notes the target parameter must be named 'target' not 'url', includes an example, and specifies max values for threads and depth. This is exemplary enrichment 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 opening sentence explicitly states 'Perform recursive content discovery using Feroxbuster,' giving a specific verb and resource. It also distinguishes from siblings by noting 'Unlike Gobuster or FFuf, Feroxbuster recursively discovers directories,' which clarifies its unique scope among similar 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 an explicit comparison with Gobuster and FFuf, indicating when Feroxbuster's recursive behavior is advantageous. It also gives practical deployment context with the allowed_hosts prerequisite and depth control guidance, but does not fully state when to avoid this tool (e.g., for single-path fuzzing).
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 of disclosing behavior. It clearly states the tool is informational ('Get detailed information') and lists what is returned (options, targets, CVE references, description). This sets expectations that it is a read-only lookup, not an execution tool. It does not mention potential errors or prerequisites, but for a benign info query, the description provides sufficient transparency.
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: a clear one-sentence purpose, then an Args section for the parameter, and a Returns section for the output. No unnecessary words or repetition. It is front-loaded with the core purpose.
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 tool is simple (one parameter) and an output schema exists, so the description doesn't need to explain return structure. It covers the essential aspects: what the tool does, the input format with example, and a summary of the return content. It could add a note about module validity or local vs remote lookup, but given the complexity, it is adequately 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 only lists 'module_path' as a string with no description, giving 0% coverage. The description fully compensates by explaining that it is the 'Full module path' and providing a concrete example. This gives the agent all necessary information 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: 'Get detailed information about a specific Metasploit module.' It uses a specific verb ('Get') and resource ('specific Metasploit module'), and the example path demonstrates the exact scope. This distinguishes it from sibling tools like msf_search (which searches for modules) and msf_run_module (which executes modules).
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 implies when to use this tool: when you need detailed info about a specific module, as indicated by 'Get detailed information' and the return listing. It does not explicitly mention alternatives or exclusions, but the context is clear enough for a simple lookup tool. A brief note about using msf_search to find module paths would elevate it to a 5, but it is not necessary for basic usage.
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 available, the description carries the full burden. It discloses that the operation is read-only ('List') and states the return payload (type, target host, session ID). This is sufficient for a simple listing tool, though it does not mention prerequisites like an active Metasploit connection.
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 short sentences, front-loaded with the action verb 'List'. It contains no wasted words and includes return-value details without excessive formatting.
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 zero-parameter scope and presence of an output schema, the description adequately covers the tool's function and return value. It is complete for an AI 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the input schema is empty. The description correctly makes no parameter claims. Per the baseline for parameterless tools, a score of 4 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 uses the specific verb 'List' and identifies the resource as 'all active Metasploit sessions', including session types (shells, meterpreter). It clearly distinguishes from sibling tools like msf_run_module and msf_session_cmd, which perform different actions.
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 clearly states the tool lists active sessions, implying it is the tool to use for session enumeration. It does not explicitly mention when not to use it, but the context is clear. Sibling tools like msf_session_cmd suggest a workflow of listing first, then interacting.
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 reveals the async I/O approach, the handoff to Nmap, the allowed_hosts restriction, and the potential for IDS/IPS alerts. It also specifies the return value ('Discovered open ports and basic service information'). While it doesn't mention resource consumption or non-destructive behavior, the disclosed traits are relevant and go beyond a simple scan description.
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: purpose, explanatory sentence, Args, Returns, and Notes. It is slightly verbose in the marketing-like claim ('scan all 65535 ports in seconds by using async I/O'), but that adds context. Overall, every sentence contributes to understanding, though it could be tightened.
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 moderate complexity and the presence of an output schema, the description is thorough. It covers the purpose, parameters, return value, allowed_hosts prerequisite, and a side-effect warning (IDS/IPS alerts). No critical gaps remain 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 per-property descriptions (0% coverage), so the description is essential. It explains each of the four parameters: target as IP/hostname, ports with examples ('80,443' or '1-65535'), batch_size with default and max, and timeout as an override in seconds. This adds substantial meaning beyond the schema's raw 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 opens with a specific verb+resource: 'Perform ultra-fast port scanning using RustScan.' It also explains the tool's distinct role by noting that it passes discovered open ports to Nmap for service detection, clearly differentiating it from sibling tools like nmap_scan and masscan_scan. The purpose is unambiguous and specific.
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: 'ultra-fast' port scanning with subsequent Nmap service detection. It also mentions a prerequisite: target must be in tengu.toml allowed_hosts, and warns that high batch_size may trigger IDS/IPS alerts. However, it does not explicitly state when not to use this tool or compare it to alternatives like nmap_scan or masscan_scan, so it lacks explicit 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?
No annotations are provided, so the description carries the transparency burden. It discloses that the QR code is written to SET's output directory, that the URL must be allowlisted in tengu.toml, and that the return value is a dict with specific keys. It could go deeper on permissions or failure modes, but for a generation tool this is solid.
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 organized with a purpose statement, usage context, Args, and Returns sections. Every sentence contributes, though the phrasing is slightly more verbose than strictly necessary. Still, it is easy to scan and front-loads the key information.
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 low-complexity tool, the description covers the full context: purpose, physical deployment scenario, parameter constraints, return format, and output location. The presence of an output schema is noted, but the description also explains what the return dict contains, making it self-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?
Schema description coverage is 0%, so the description fully compensates by explaining both parameters: url requires an allowlist entry in tengu.toml, and timeout defaults from config. This adds meaningful constraints beyond what the bare schema shows.
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 a QR code pointing to a malicious URL for physical social engineering.' It clearly identifies the tool's unique purpose among siblings like set_credential_harvester and set_payload_generator by naming SET's QRCode Generator Attack Vector.
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?
It provides clear context for when to use the tool: physical social engineering through printed QR codes on lanyards, posters, and signs to test user awareness. It does not explicitly name alternatives or exclusions, but the use case is distinct and well described.
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 disclosing behavioral traits. It explains that a finding means the CNAME points to an unclaimed resource, notes that manual verification is required, and mentions the use of a subdomain wordlist and configurable threads/timeout. It does not explicitly state whether the scan is active or passive, but the overall behavior is sufficiently conveyed for the agent to understand the tool's operation and expectations.
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 clear sections: a one-sentence summary, a brief explanation of the vulnerability, Args, Returns, and Notes. Every sentence serves a purpose, providing essential information without redundancy. It is appropriately sized for a tool with this complexity.
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 (4 parameters, no annotations, output schema present but not shown), the description covers the core aspects: purpose, parameter semantics, return value, and a key usage note. It does not mention any external prerequisites beyond the allowed_hosts entry, but that is a minor omission. Overall, the description is complete enough for an agent to 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%, so the description fully compensates by documenting all four parameters in the Args section. It explains each parameter's purpose (domain, subdomains_file, threads, timeout), provides default values and constraints (e.g., threads max 100), and describes behavior when subdomains_file is not supplied. This adds significant meaning beyond the bare 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 the tool's function: 'Check for subdomain takeover vulnerabilities using Subjack.' It specifies the resource (subdomain takeover) and the method (Subjack), which distinguishes it from sibling tools like subfinder_enum or dnsrecon_scan that focus on enumeration rather than vulnerability detection. The description also names the relevant services (GitHub Pages, S3, Heroku, Netlify, Azure), making the scope explicit.
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 use: it identifies that findings require manual verification and that the target must be in allowed_hosts, which are important operational prerequisites. However, it does not explicitly mention alternative tools or when not to use this tool, though the context implies it should be used when subdomain takeover is suspected. This is 'clear context, no exclusions' on alternatives.
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 behavioral disclosure burden. It discloses that detect_all tries all WAFs instead of stopping at first match, mentions timeout override, and requires target to be in allowed_hosts. It also summarizes return content. It lacks details on failure modes or side effects but covers the most critical behaviors.
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 (description, args, returns, note). It is concise, though the phrase 'before active scanning' appears twice, slightly redundant. Overall, every sentence adds 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 description covers the tool's purpose, all parameters, return value summary, and a critical prerequisite (allowed_hosts). The presence of an output schema further reduces the need for return detail, making this description complete for a tool of this 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?
Despite the input schema having no descriptions (0% coverage), the Args section thoroughly explains each parameter: target specifies the URL, detect_all controls detection scope, and timeout overrides the scan timeout. This adds significant semantic meaning beyond the bare 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 it detects Web Application Firewalls (WAF) using WafW00f, naming the specific tool and resource. It distinguishes itself from sibling scan tools by focusing on WAF detection rather than general scanning or other specialized activities.
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 explicitly advises running this tool before active scans to avoid false negatives and understand defensive posture. It gives clear workflow context but does not name alternative tools or explicitly state when not to use it.
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 Dalfox's detection methods, behavior when 'parameter' is empty (tests all), and what the return values include. It does not mention safety or side effects, but as a scanner that only sends HTTP requests, this is less critical.
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 an overview, an IMPORTANT callout, an args list, and a Returns section. It is somewhat verbose and repeats the 'url not target' warning, but every section adds value and the layout improves scannability.
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 7 parameters and no schema descriptions, the description provides comprehensive coverage: purpose, all parameter behaviors, and return value format. It is complete enough for an agent to invoke the tool correctly without needing additional 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 by explaining every parameter in detail: 'url' (with mandatory naming warning), 'parameter' (empty means all), 'cookie' (with example), 'header' (with example), 'method' (GET/POST, default), 'data' (with FUZZ placeholder), and 'timeout'. This is exemplary.
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, specific purpose: 'Test for Cross-Site Scripting (XSS) vulnerabilities using Dalfox.' It distinguishes itself from sibling scanners (e.g., sqlmap_scan, commix_scan) by focusing solely on XSS and even lists the detection types (reflected, stored, DOM-based).
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 how to specify the target URL, test POST endpoints with data and FUZZ placeholder, and use cookies for authenticated testing. It does not explicitly mention alternatives or exclusions, but the purpose is so clearly scoped to XSS that the intended use case is evident.
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 full burden and succeeds by stating the tool is intrusive and 'will send potentially malicious payloads'. This is a key behavioral disclosure. It also includes a timeout parameter, giving users control over duration, but does not elaborate on potential side effects or authorization requirements.
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?
Structured with a summary, a warning, Args, and Returns sections. Every sentence serves a purpose, with no fluff. The entire description is compact yet informative.
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 destructive nature and lack of annotations, the description covers prerequisites, parameters, and return value. It is complete for a single tool, though it could mention how to retrieve full alert details (e.g., using zap_get_alerts). The output schema likely covers the return structure, so this 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?
Schema coverage is 0%, so the description fully compensates by explaining each parameter: url gives target and prerequisite, policy explains default behavior, timeout states units. This adds meaning beyond the bare schema definitions.
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 an active vulnerability scan using OWASP ZAP' with a specific verb and resource. It differentiates from siblings like zap_spider (passive crawling) and zap_get_alerts (reading results) by explicitly calling it an active 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?
Provides clear context by noting the URL 'should be spidered first', implying a prerequisite step before running the scan. Also warns it is an 'intrusive operation', indicating cautious use. Does not explicitly mention alternatives, but the 'spidered first' note effectively points to spidering tools.
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 and discloses key behavioral traits: it requires explicit authorization, the target must be in tengu.toml allowed_hosts, and it returns test results with evidence. It could go further by explicitly stating that it sends crafted payloads to the target, but the purpose makes this 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 headers, front-loads the purpose and a critical warning, and uses concise bullet-like sections. Every sentence adds value, and the moderate length is appropriate for a tool with five parameters and safety requirements.
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 the tool's purpose, all parameters, return value, and prerequisites, making it complete for an agent to invoke correctly. The presence of an output schema means the return value description is a bonus, not a necessity.
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 thoroughly explains every parameter (url, method, data, level, timeout) with defaults, examples, and the critical naming constraint. This fully compensates for the schema's lack of descriptions.
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 explicitly states 'Test a URL for OS command injection vulnerabilities using Commix,' clearly defining the tool's function and resource. It distinguishes itself from sibling scanning tools like sqlmap_scan (SQL injection) and xss_scan (XSS) by naming the vulnerability class.
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 clearly indicates when to use the tool (for OS command injection testing) and provides important operational prerequisites like explicit authorization and allowed_hosts. It does not explicitly compare to alternatives or state when not to use it, but the purpose strongly implies the appropriate context.
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 transparency burden. It explains the nature of the scan, the impact of CRLF injection, and the allowed_hosts constraint. It does not explicitly state whether the scan is read-only or mention rate limits, but the provided context (threads, timeout) and return behavior give reasonable insight into the tool's 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 well-organized with clear sections (Description, Impact, Args, Returns, Note). Each sentence adds meaningful information, and the length is appropriate for the complexity of the tool with three parameters and a security-relevant context.
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, parameters, return values, and a usage constraint. It is sufficient for an agent to select and invoke the tool appropriately, especially given the presence of an output schema. The note about allowed_hosts is a critical context piece that is not in the schema.
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?
Despite the input schema having no property descriptions, the description compensates fully with an Args section. It explains each parameter's purpose: url with an example, threads with default and max, and timeout as an override. This is exemplary parameter documentation that goes far beyond 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 states the tool's function: "Scan a URL for CRLF injection vulnerabilities using CRLFuzz." This specifies the exact vulnerability type, the target resource, and the underlying tool, making it easily distinguishable from sibling scanning tools like xss_scan or nuclei_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 clearly implies when to use the tool (to test for CRLF injection) and includes an important prerequisite: "Target must be in tengu.toml [targets].allowed_hosts." However, it does not explicitly contrast with alternative tools or provide when-not-to-use guidance, so it lacks the full differentiation expected for 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?
Since no annotations are provided, the description carries full responsibility for behavioral disclosure. It explicitly discloses that no external process is spawned and that it uses dnspython as a pure-Python client. It also describes the return format: 'DNS records grouped by type with values and TTLs.' While it does not mention error handling or potential network usage, these are inherent to a DNS lookup tool and the key behavioral traits are covered.
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 one-line summary, a behavioral note, and clearly labeled Args and Returns sections. It is appropriately sized, with every sentence contributing useful information and no fluff. The formatting with headers and bullet-like entries enhances readability.
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 three parameters and no annotations, the description provides all necessary invocation details: parameter semantics, defaults, return format, and implementation notes. It even mentions the pure-Python nature to set expectations. The output schema (not shown) likely handles precise return typing, so the description is sufficient for an agent to correctly select and use 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 no parameter descriptions (0% coverage), so the description fully compensates. It explains each parameter with examples and defaults: 'domain: Target domain to query (e.g. "example.com")', 'record_types: List of DNS record types to query. Defaults to all common types...', and 'nameserver: Optional custom DNS resolver IP (e.g. "8.8.8.8"). Defaults to system resolver.' This adds significant meaning beyond the bare 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 the tool's function: 'Query DNS records for a domain.' It specifies the resource (DNS records), the action (query), and enumerates supported record types. It also distinguishes itself from siblings by emphasizing 'No external process is spawned — this is a pure-Python DNS client,' which separates it from tools like dnsrecon_scan that may rely on external binaries.
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: it supports custom record types, defaults to common types, and offers an optional nameserver. It implies lightweight usage by noting the pure-Python implementation, but it does not explicitly name alternatives or state when not to use it, such as 'for comprehensive DNS recon, use dnsrecon_scan.' Thus 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?
With no annotations, the description carries the burden and discloses the passive nature ('only sends DNS queries, no HTTP requests') and the permutation logic. It also explains registered_only and check_mx semantics, but omits potential rate limits or error behavior.
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-organized with distinct sections for purpose, args, returns, and notes. Every sentence provides useful information; the Args list is necessary because the schema lacks descriptions, and there is no repetition or fluff.
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, the description covers purpose, all parameters, return values, and key constraints like allowed_hosts and passive operation. With an output schema present, this is sufficient for an agent to decide on 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 description explicitly explains all five parameters with meanings and defaults, fully compensating for the 0% schema description coverage. The domain example and registered_only/default values add 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 the tool detects typosquatting and phishing domains by generating permutations and checking registration with dnstwist. This specific verb+resource+method distinguishes it from sibling DNS tools like dns_enumerate or whois_lookup.
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 implies usage for typosquatting investigation and includes prerequisites (allowed_hosts) and behavioral context (passive OSINT). However, it does not explicitly mention alternatives or state when not to use this tool, stopping short of full 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 provided, the description carries the full burden. It discloses important behavioral constraints such as target path restrictions ('must be under an allowed directory'), the three scan modes, output formats, and the return structure including 'partially-redacted secret'. It does not mention potential side effects or performance implications, but for a read-only scanner this is adequate.
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 with clear sections (Args, Returns, Note). Every sentence adds useful information, and the total length is appropriate for the tool's complexity.
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 moderate complexity, no annotations, and a schema with no descriptions, the description covers all essential aspects: parameters, return format, usage notes, and constraints. It is sufficient 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 schema has no property descriptions (coverage 0%), but the description compensates fully by explaining each parameter: target (path), scan_type with possible values and meanings, report_format with example formats, and timeout as an override. This adds substantial semantic value beyond the bare 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 the tool's function with a specific verb and resource: 'Scan a repository or directory for secrets and credentials using Gitleaks.' This distinguishes it from sibling scanners like trufflehog_scan by naming the underlying engine, making the 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 Note section provides clear context for when to use each scan_type (e.g., 'Use detect for comprehensive historical scans', 'Use protect as a pre-commit hook'), which guides parameter selection. However, it does not explicitly compare against alternative secret-scanning tools or state when not to use this tool, so alternatives are not addressed.
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 full burden and does a good job by disclosing external dependencies ('Requires Chrome/Chromium'), saving behavior ('Screenshots are saved locally to output_dir'), and the allowed_hosts constraint. It does not discuss rate limits or potential side effects, but the core behavioral traits are covered.
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-organized with clear sections (Args, Returns, Note) and front-loads the primary purpose in the first sentence. Each sentence adds value, such as the return summary and the Chrome/Chromium requirement, without excessive fluff.
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 and a moderate complexity, the description covers parameters, return values, prerequisites, and operational constraints. Even though an output schema exists, it still summarizes the return format, and the notes provide essential environmental context, making it fully self-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 input schema provides no descriptions (0% coverage), so the description's Args section is the sole source of parameter meaning. It explains 'target' as URL, file, or CIDR based on mode; defines 'mode' options; clarifies 'output_dir' default; and notes 'timeout' as an override. This fully compensates for the lack of schema descriptions.
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 'Capture web screenshots for visual documentation using Gowitness', specifying both the action and the resource. It also mentions specific use cases (documenting web interfaces, login pages, web-based findings), distinguishing it from other scanning 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 for when to use it ('Useful for documenting web interfaces, login pages, and web-based findings in penetration test reports') and includes a prerequisite note about allowed_hosts. However, it does not explicitly name alternatives or state when not to use it, so it falls short of full guidance.
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 full burden. It discloses the pattern-matching approach, output (list of possible types with confidence scores and hashcat modes), and the critical parameter naming requirement (hash_value not hash). It lacks details on edge cases or errors, but for a read-only analysis tool, this is sufficient.
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 clear sections (description, IMPORTANT note, Args, Returns). Every sentence adds value, and the repeated emphasis on the parameter name is purposeful for correctness. No unnecessary fluff.
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 a single parameter, an output schema (not shown but referenced), and no annotations, the description explains the return format (list of types with confidence and hashcat mode numbers) and the tool's behavior. It is complete for this simple tool's 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 coverage is 0%, so the description fully compensates by explaining that the parameter is the hash string, must be named 'hash_value', and provides an example. This is significantly more informative than the bare 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 the tool identifies the algorithm used to produce a hash value, with a specific verb ('Identify') and resource ('hash value'). It distinguishes from sibling 'hash_crack' by focusing on identification, not cracking.
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: it is used to identify hash types via pattern matching. It includes an explicit 'IMPORTANT' note on how to call the tool and what to expect. However, it does not explicitly mention when NOT to use it or direct users to alternatives like hash_crack for cracking, so some implicit inference is required.
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 present, so the description must carry the burden of behavioral context. It discloses that it uses the ProjectDiscovery httpx CLI (not the Python library), has a threads parameter with max 200, and requires the target to be in tengu.toml allowed_hosts. It also states return output includes status codes, titles, and detected technologies. This goes beyond the schema, though it could be more explicit about network side effects.
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 summary, argument list, returns, and notes. It is front-loaded with purpose and contains no filler—each line provides value, including the note distinguishing from the Python httpx library.
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 is complete for a tool with an output schema: it covers purpose, all parameters, output highlights, and a critical configuration constraint. The minor ambiguity of 'host or URL list' in the opening line is clarified in the Args section with 'Target URL or host.'
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?
All four parameters are described in the Args section: target with an example, threads with default and max, detect_tech with default, and timeout as an override. This fully compensates for the 0% schema description coverage, adding meaning well beyond type and default.
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 'Probe HTTP services on a host or URL list using ProjectDiscovery httpx,' which uses a specific verb (probe) and resource (HTTP services). It further details capabilities like technology detection, status code enumeration, and title extraction, making it distinct from siblings like nmap_scan (network scanning) or katana_crawl (web crawling).
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 use case: 'Useful for quickly triaging large host lists after subdomain enumeration.' This implicitly tells the agent when to select this tool over others, though it does not explicitly state alternatives or exclusions. The note about allowed_hosts also gives context for when it can be used.
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 takes on the full burden of behavioral disclosure. It explains authentication options (password vs. NTLM hashes), mentions that password is 'redacted in logs', and states target restrictions and permission requirements. It does not explicitly note that listing operations are safe/read-only, but the action choices (list_shares/list_files) make that implicit. This is solid but not exhaustive.
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 front-loaded with the purpose in the first two sentences, followed by a clear Args list, Returns, and Note sections. Each sentence carries useful information—there is no filler. Despite listing 8 parameters, it remains scannable and well-formatted.
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 8 parameters, no annotations, and an output schema that exists, the description covers all essential aspects: purpose, parameter semantics, authentication methods, prerequisites, and what the tool returns ('SMB shares list or file listing'). It also warns about the required target allowlist and permission needs, providing sufficient context for an AI agent to invoke it 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 zero descriptions, so the description's Args section is essential. It fully explains all 8 parameters: target, domain, username, action, share, password, hashes, and timeout. For example, it clarifies the action enum values, the share name format (e.g., 'C$', 'ADMIN$'), and the hashes format 'LM:NT'. This exceeds the schema's information.
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: 'Browse and interact with SMB shares' and specifically 'Enumerates available shares and optionally lists files within a specific share.' This distinguishes it from siblings like impacket_psexec or impacket_secretsdump, which handle remote command execution or credential dumping, respectively.
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 conveys clear context for use: SMB share enumeration and file listing. It also provides prerequisites via the note: 'Target must be in tengu.toml [targets].allowed_hosts' and 'Requires valid credentials with appropriate share permissions.' However, it does not explicitly name alternatives or state when not to use it, so it falls short of a full 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, the description carries the full burden and discloses critical behavioral traits: it is destructive, requires explicit authorization, accepts only numeric session IDs, and returns command output with session type and ID. It does not mention error handling or what happens on session failure, but covers the essential safety and output expectations.
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 clear first-line purpose, a warning, an Args section, and a Returns section. It is concise, with every sentence adding value and no redundancy.
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 the lack of annotations and a relatively simple tool, the description covers the essential aspects: what it does, parameters, safety warning, and return value. The presence of an output schema means it doesn't need to detail return structure further. It is complete for an agent to select and invoke 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 schema provides only types and defaults, but the description richly documents each parameter with examples, constraints (e.g., 'Only digits are accepted' for session_id), and the timeout default. This fully compensates for the 0% schema description 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 'Execute a command on an active Metasploit session (shell or Meterpreter)', identifying the specific verb, resource, and scope. This distinguishes it from sibling tools like msf_sessions_list (listing sessions) and msf_run_module (running modules).
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 implies this is for post-exploitation when an active session exists, and the purpose is specific enough to avoid confusion with alternatives. However, it does not explicitly mention when not to use it or name alternative tools, which would be a 5. The destructive warning and 'requires explicit authorization' provide important usage context.
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 fully carries the behavioral disclosure burden. It explicitly discloses that SYN scan requires root/sudo, OS detection requires root/sudo, and targets must be in the allowed_hosts list. It also explains the default scan type and the existence of a timeout parameter, giving the agent a clear picture of operational constraints and side effects.
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?
Despite being long, the description is well-structured with clear sections (IMPORTANT, Args, Returns, Note). Every sentence adds value: the no-flags warning prevents common mistakes, each parameter is explained concisely, and the notes about privileges and allowed_hosts are critical. No redundant fluff exists.
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 (7 parameters, output schema) and the absence of annotations, the description is exceptionally complete. It covers parameter semantics, return value summary, privilege prerequisites, and configuration constraints. The output schema exists but the description appropriately summarizes the return structure without over-explaining, and it includes all necessary operational context for correct invocation.
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 is the sole source of parameter meaning. It explains every parameter (target, ports, scan_type, timing, os_detection, scripts, timeout) with concrete examples and details, such as scan_type values ('syn (stealthy), connect (no root)') and port formats. It also warns about the absence of a 'flags' parameter, preventing incorrect invocation.
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 'Scan a target for open ports, services, and versions using Nmap.' This is a specific verb+resource combination that distinguishes it from sibling scanners like masscan_scan and rustscan_scan by emphasizing Nmap's service/version detection, while also mentioning key parameters that define its scope.
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 context through its capability description (service/version detection) and notes privilege requirements, but it does not explicitly contrast with alternatives like masscan or rustscan. There is no 'when to use this instead of X' guidance, so the agent must infer when Nmap is the right choice over other scanner siblings.
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 full burden. It discloses API key requirements, passive behavior, and target allowlisting. It also explains the return data and query modes. It stops short of revealing rate limits or error handling, but the disclosed traits are valuable.
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 Args, Returns, and Note sections, each earning its place. It is succinct yet comprehensive, with no fluff or redundancy.
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 (4 parameters, output schema present), the description covers prerequisites, parameter meanings, return values, and usage modes. It provides everything an agent needs to select and invoke the tool correctly, even without richer schema hints.
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 coverage is 0%, but the description fully compensates by explaining every parameter in plain language: target, query_type, query, and limit. It includes examples for the query string, making the semantics clear and actionable.
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: 'Query Shodan for exposed services, vulnerabilities, and device information.' This clearly states the tool's function and scope, and distinguishes it from sibling scan tools (nmap, masscan) by focusing on Shodan's passive database.
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 use, such as 'Passive OSINT — queries Shodan's database, does NOT interact with target directly,' which separates it from active scanners. It also explains the two query modes (host vs search) but does not explicitly name alternatives or exclusions beyond that.
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 full burden. It discloses the passive, non-intrusive nature, API key requirements, and domain restriction. It does not describe failure modes, rate limits, or resource consumption, so it is not fully comprehensive.
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 Args/Returns/Note sections, front-loaded with the purpose, and every sentence provides information. Length is appropriate for the tool's complexity.
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, the description covers purpose, parameters, return type, safety, and constraints. The presence of an output schema means return value details are optional, and the mention of metadata suffices.
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?
All three parameters are explained with examples and guidance (e.g., 'sources' can be left empty to use all configured sources). This fully compensates for the 0% schema description 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 the tool enumerates subdomains passively using Subfinder, specifying the action, target, and method. It distinguishes from sibling tools by emphasizing passive enumeration with no direct probing of the target.
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: it is for passive enumeration only and notes prerequisites such as API keys and allowed_hosts. However, it does not explicitly mention alternatives or when not to use this tool, so it lacks explicit 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 burden and discloses key behavioral traits: it queries multiple public data sources, is passive, and notes that shodan needs an API key. It also mentions the allowed_hosts configuration requirement. It does not cover potential rate limits, timeout behavior, or error handling, but the main safety and prerequisite info is present.
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 header sections (Args, Returns, Note) and no unnecessary filler. Each sentence adds value, and the most important info (purpose and passivity) is front-loaded.
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 and an output schema, the description is thorough: it explains all parameters, notes operational constraints (allowed_hosts, API key), and describes return values. Despite the existence of an output schema, this description remains self-sufficient and 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 description coverage is 0%, so the description must compensate. It does excellently with an Args section explaining each parameter, including the list of available sources, the meaning of limit, and the timeout override. This adds substantial meaning beyond the bare 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 uses a specific verb ('Gather') and resource ('OSINT data') and names the tool 'theHarvester', making its function unmistakable. It also differentiates from other recon tools by stating it queries public data sources passively, which is distinct from active scanning 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?
Provides clear context: 'Passive OSINT — does NOT interact directly with the target' and requires the target to be in allowed_hosts. This signals when to use it (passive recon) and highlights a prerequisite. However, it does not explicitly mention alternatives or when not to use this tool.
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 of behavioral disclosure. It transparently lists the three checks performed and states that it returns validation status and restrictions, giving a solid understanding of the tool's behavior without side-effect details.
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 succinct and well-structured with a numbered list of checks. It front-loads the purpose and each sentence adds value, making it an example of efficient writing.
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 simplicity (one parameter, no annotations) and the presence of an output schema, the description covers all necessary context: purpose, input formats, configuration sources, and return behavior. It is complete for an agent to select and invoke it 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 schema provides only a bare string 'target' with 0% description coverage. The description compensates fully by explaining that the target may be an IP, hostname, CIDR, or URL, providing essential semantic meaning beyond 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 states the tool validates whether a target is allowed for scanning, with a specific verb and resource. It distinguishes itself from the many scanning siblings (nmap, nuclei, etc.) by being a pre-scan validation gate.
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 what the tool does—checks a target against input validation, allowlist, and blocklist—indicating its use as a pre-scan check. However, it does not explicitly name alternatives or exclusions, so it lacks full guidance.
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 read-only nature ('Retrieve', 'Fetches'), supported filters, and return content. It does not mention potential rate limits or pagination, but these are not critical for a fetch operation.
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?
Concise and well-structured with a clear opening statement, followed by parameter descriptions and return value explanation. Every sentence 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, and return content. Since an output schema is present, the return description is a bonus that reinforces completeness. The tool is simple enough that this description provides sufficient context for correct selection and invocation.
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 compensates by explaining all three parameters: url filter, risk_level with allowed values, and max_alerts meaning. This gives agents full semantic understanding of each 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?
Description clearly states it retrieves vulnerability alerts from OWASP ZAP with a specific verb ('Retrieve') and resource. It also distinguishes from sibling tools like zap_active_scan and zap_spider by focusing on fetching alerts rather than running scans.
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?
Implies usage after scanning by referencing alerts from active/passive scanning, but does not explicitly say when to use it vs alternatives or provide exclusions. Clear context is present 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It states the tool downloads the entire website, preserves structure, caps depth at 5, caps max_size at 500 MB, supports timeout overrides, requires HTTrack installation, and enforces the allowed_hosts constraint. It also summarizes the return contents, providing comprehensive behavior 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 well-structured with clear sections (summary, useful-for, args, returns, note) and front-loads the core purpose in the first sentence. It is somewhat lengthy, but each section provides necessary information without redundant fluff, so it remains efficient for the tool's complexity.
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 having no annotations, the description covers purpose, usage scenarios, all parameters, output summary, prerequisites (HTTrack installed, allowed_hosts), and safety caps. Since an output schema exists, the return values are sufficiently described. The description is complete 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 0% description coverage, but the 'Args' section in the description explains all 6 parameters: target, depth, output_dir, max_size, include_assets, and timeout, including defaults, ranges, and constraints. This fully compensates for the lack of schema descriptions.
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 'Mirror a website locally for offline analysis using HTTrack' and elaborates on downloading the full site (HTML, JS, CSS, images), which clearly specifies the verb, resource, and purpose. It also lists concrete use cases that differentiate it from sibling tools like katana_crawl (crawling) or gowitness_screenshot (screenshots).
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 'Useful for' section with three explicit scenarios (forensic snapshots, offline secret search, mapping structure) and advises setting depth=1 for a shallow mirror. It provides clear context on when to use the tool, though it does not explicitly name alternative tools or state when not to use it.
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 full burden and excels. It discloses destructive behavior, creation of a service, high detectability (Event IDs 7045, 4688), authentication requirements, and password redaction in logs. This goes well beyond a simple 'runs a command' and fully informs the agent of consequences.
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 'Args', 'Returns', and 'WARNING' sections, front-loading the core purpose. Each sentence earns its place, and the warnings are essential for a destructive tool. No redundancy or filler.
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 having no annotations and 7 parameters, the description covers purpose, mechanism, prerequisites, authentication methods, detection risk, and return type. An output schema exists, so the vague 'Returns' line is acceptable. This is a complete, self-sufficient description for a complex tool.
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 0%, so the description must compensate. It does so by listing all 7 parameters with meaningful context: target, domain (with '.' for local accounts), username, command, password (redacted), hashes (LM:NT format for pass-the-hash), and timeout override. This adds value beyond bare schema fields, though some descriptions remain terse.
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 'Execute a command remotely on a Windows host via SMB using Impacket psexec' with a specific verb, resource, and method. It also explains the underlying mechanism (uploads a service binary, creates/starts a Windows service), which distinguishes it from sibling tools like impacket_wmiexec or impacket_secretsdump.
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: requires admin credentials and SMB access (port 445), is destructive, and demands explicit human authorization. It implies when to use by describing the command execution scenario, but it does not explicitly contrast with alternatives such as WMI exec or mention when not to use it.
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 full responsibility and does an excellent job. It warns that the operation is 'destructive,' starts an 'active phishing server,' captures credentials, redirects victims, and requires explicit written authorization, giving the agent complete awareness of impacts and prerequisites.
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 (summary, warning, args, returns, note) and each part contributes value. The safety warning is repeated twice ('WARNING' and the note), which is slightly redundant but reinforces the critical human-confirmation requirement; otherwise the length is justified.
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 complex, dangerous tool with no annotations, this description is complete. It covers safety constraints, behavioral mechanics, parameter semantics, return values, and execution prerequisites, leaving no major ambiguity for an agent selecting or 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?
Schema description coverage is 0% but the description fully compensates by explaining each argument: target_url must be in the allowlist, lhost is the POST-back address, listen_port defaults to 80, and timeout defaults from config. This adds critical meaning beyond the raw 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 purpose: 'Clone a website and capture credentials submitted via the phishing page.' It specifies the resource (website clone) and action (credential capture), and distinguishes it from sibling tools like set_payload_generator and set_qrcode_attack by referencing the SET Credential Harvester → Site Cloner module.
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 explicitly restricts usage to 'authorized phishing simulations and social engineering security assessments ONLY' and requires 'explicit human confirmation before execution.' It provides clear context for when to use, though it does not explicitly name alternative tools or state when not to use it beyond the authorization requirement.
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 fully discloses the tool's behavior: it is destructive, generates executable payloads, requires explicit human confirmation, and returns specific truncation behavior for output/errors. This goes beyond minimal disclosure and addresses safety and authorization requirements.
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 (warning, usage, supported types, args, returns, note) and front-loaded with the critical warning. It is slightly verbose but every section earns its place; a bit of trimming could make it more 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?
Given the tool's complexity and danger, the description is complete: it explains purpose, parameters, return value structure, and critical warnings. The output schema exists to cover return details, so the description's coverage is more than 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?
Schema description coverage is 0%, and the description compensates fully by explaining each parameter in detail: payload_type enumerates supported values, lhost/lport describe their role, and timeout notes the default. This adds meaning beyond the raw schema fields.
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: 'Generate a social engineering payload' via SET's 'Create a Payload and Listener' module. It distinguishes itself from sibling tools like set_credential_harvester and set_qrcode_attack by focusing on payload generation for reverse connections.
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 clearly states when to use it: authorized penetration tests and red team engagements only. It emphasizes the requirement for human confirmation and written authorization. However, it does not explicitly contrast with alternative tools or state when NOT to use it, though the context is clear.
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 fully carries the burden of behavioral disclosure. It warns that BloodHound collection is detectable by EDR/SIEM, generates significant LDAP traffic, requires valid credentials, and has an allowed-hosts constraint. It also notes that passwords are redacted in logs and that output is written as JSON/ZIP files, providing rich behavioral context 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 well-structured and appropriately sized. It front-loads the purpose, then uses an Args list, Returns summary, and WARNING section. Every sentence adds value—no filler or repetition—and the format is scannable for an AI agent.
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 parameters, no annotations, and an output schema not shown, the description covers prerequisites, behavior, output, and safety warnings. It explains what the tool returns (collection summary with file locations and AD object counts) and flags operational risks, making it sufficiently complete for correct invocation and expectation setting.
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 compensates by documenting all 8 parameters with meaningful semantics: target is a Domain Controller IP, hashes use LM:NT format, collection_method lists valid values, output_dir writes JSON/ZIP files, and timeout overrides the scan timeout. This fully bridges the schema's lack of descriptions.
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: 'Collect Active Directory data for BloodHound attack path analysis.' It further details what bloodhound-python enumerates (users, groups, computers, GPOs, trust relationships), making the tool's purpose unmistakable and distinguishing it from AD enumeration siblings like impacket_secretsdump or enum4linux_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 context for when this tool is appropriate: it maps attack paths to Domain Admin and requires valid domain credentials. It also includes operational prerequisites such as the target being in tengu.toml allowed_hosts. However, it does not explicitly name alternatives or state when not to use this tool, so it misses the top tier for usage guidance.
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?
Without annotations, the description carries full burden and does well by disclosing that it uses pure Python httpx requests (no subprocess), performs no mutations, and requires allowed_hosts configuration. This gives strong transparency into behavior and safety.
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?
Well-organized with clear sections for summary, checks, args, returns, and notes. Every sentence adds value and the structure makes it easy to scan without unnecessary verbosity.
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?
Covers purpose, parameters, return values (also supported by output schema), prerequisites, and safety profile. No obvious gaps for a tool of this 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 'Args' section explains every parameter (url, check_introspection, authenticated, auth_header, timeout) with examples and semantics, fully compensating for the 0% schema description 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?
Clearly states it 'Perform automated GraphQL security checks' and lists specific check categories (introspection, query batching, depth limit, field suggestion), which distinguishes it from general-purpose scanners among 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?
Provides clear context for GraphQL security testing and includes practical notes like allowed_hosts requirement, but does not explicitly contrast with alternative tools or state when not to use it.
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?
The description is highly transparent about behavioral consequences: it warns of account lockouts, IDS/IPS alerts, log entries, and the need for authorization. Since there are no annotations, this description fully carries the burden of disclosing the destructive nature of the operation, going beyond simple 'mutating' labels.
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-organized into warning, args, returns, and notes. It is a bit long but every sentence adds necessary safety or usage context. It is front-loaded with the core action and warning, making it 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?
For an attack tool with 8 parameters and no annotations, the description is robust: it covers purpose, all parameter meanings, output (list of discovered credentials), and critical prerequisites (authorization, allowed host). This is sufficient for an agent to invoke it correctly, and the note about rate limiting adds responsible usage guidance.
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 a one-line explanation for each of the 8 parameters, including defaults and limits (e.g., 'threads' default 16, max 64). This meaningfully supplements the input schema, which only lists names and types, giving the agent guidance on how to set each 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 a clear verb-object directive: 'Perform a credential brute force attack using Hydra.' It names the specific tool and attack type, distinguishing it from other scanning/attack tools in the sibling list. This establishes a precise 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?
It provides explicit authorization requirements and warnings about destructive impact ('Only use with explicit written authorization', 'Requires explicit human authorization before execution'). It also notes the target must be in an allowed_hosts list, giving clear invocation constraints. However, it does not name alternative tools for when not to use it, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it is destructive/intrusive, detectable by EDR, requires admin credentials and explicit human authorization, and targets must be in allowed_hosts. It also notes that the password is redacted in logs and returns data organized by type. This is comprehensive for a security tool with no annotation support.
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 clear sections (summary, args, returns, warnings). It front-loads the core purpose, uses bullet points for parameters and warnings, and every sentence adds value. The length is appropriate for the tool's complexity.
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 having an output schema, the description still explains return values and includes essential warnings and prerequisites. Combined with the parameter details and clear purpose, it provides a complete picture for an agent to decide when and how to invoke this tool, even among many siblings.
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 Args section gives meaningful explanations for every parameter: target (IP/hostname), domain (use '.' for local), username, password (redacted in logs), hashes (LM:NT format for pass-the-hash), and timeout. This fully compensates for the schema's lack of descriptions.
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: 'Dump SAM, NTDS, and LSA secrets from a Windows target using Impacket secretsdump.' This clearly distinguishes it from sibling impacket tools like impacket_kerberoast, impacket_psexec, and impacket_smbclient, which target different functionalities.
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: to extract credential hashes from Windows systems. It also lists prerequisites (admin credentials, allowed_hosts, human authorization) that act as usage constraints. However, it does not explicitly name alternatives or state when not to use this tool, so it misses the top score for explicit exclusions.
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, the description carries the full burden and does so excellently. It explicitly warns that the operation is destructive, may exploit vulnerabilities, requires human confirmation, and initiates an actual exploit attempt against the target. This goes beyond basic mutation disclosure and covers the critical safety and authorization context.
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 clear sections for arguments, returns, and usage warnings. It is appropriately detailed for a complex, high-risk tool without being verbose or redundant. Each sentence contributes critical information, from parameter examples to authorization requirements.
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 high complexity, absence of annotations, and presence of an output schema, the description is remarkably complete. It covers all parameters, explains return value semantics, and clearly warns about authorization and destructive potential. The output schema handles exact return formatting, so the description appropriately focuses on behavior and prerequisites.
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 compensates fully with detailed explanations for all five parameters: module_path with example, options as key-value pairs, target_index with default, payload with examples and behavior when empty, and payload_options with clarifications. It adds semantic meaning far beyond the schema's raw type definitions.
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: 'Execute a Metasploit module with configured options.' This is a specific verb+resource pairing that distinguishes it from sibling tools like msf_search or msf_module_info, which focus on discovery and metadata rather than execution.
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 clearly communicates the high-risk context: destructive operation, requires explicit authorization and human confirmation. It implies this is for actual exploitation rather than reconnaissance. However, it does not explicitly name alternatives like msf_search for finding modules or msf_module_info for detailing options, so it falls short of full sibling differentiation.
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 full burden and does so thoroughly. It clearly discloses that SQLMap automates detection and exploitation, can cause database errors and data exposure, requires explicit authorization, and notes that higher level/risk values increase request counts. It also explains dump/enum effects and target restrictions.
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 long but well-structured with Args, Returns, and Note sections. Each parameter explanation is concise and informative. Front-loaded summary gives immediate clarity, and no sentence is wasted. The length is justified by the 19-parameter tool.
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 complexity (19 params, high-risk exploitation tool), the description is complete. It covers purpose, authorization, target restrictions, parameter details, return values, and safety warnings. The presence of an output schema means return values need not be elaborated, but the Returns section still provides useful 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 must explain all parameters. It does: every parameter (url, method, data, parameter, headers, level, risk, dbms, technique, prefix, suffix, tamper, batch, dump, enum_*, sql_query, timeout) is described with purpose, example, or consequence. This far exceeds the bare schema and fully compensates for the lack of schema descriptions.
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 statement: 'Test a URL for SQL injection vulnerabilities using SQLMap.' This identifies the specific action (test), the resource (URL), and the tool (SQLMap), distinguishing it from sibling tools like xss_scan or commix_scan. The scope and intent are immediately clear.
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 strong usage guidance: explicit authorization is required, targets must be in allowed_hosts, and level/risk warnings are given. It does not name alternative tools or explicitly state when not to use it, but the context is clear. This falls just short of a 5 because it lacks explicit 'when-not' or alternative comparisons.
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, the description carries full responsibility for behavioral disclosure. It thoroughly explains what the tool does (sends requests with various Origin headers), what it detects (specific vulnerabilities listed), and what it returns (results with evidence). This goes well beyond minimal expectations.
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 efficiently structured, starting with the core purpose, followed by a bulleted list of detected vulnerabilities, and ending with parameter details. Every sentence adds value without unnecessary fluff.
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 (CORS scanner with multiple vulnerability checks), the description covers all necessary aspects: purpose, behavior, parameters, and return value. The output schema further clarifies return structure, so the description is 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 input schema has no descriptions (0% coverage), but the description compensates fully with an Args section: 'url: Target URL to test.', 'custom_origins: Additional origin values to test.', 'timeout_seconds: HTTP request timeout in seconds.' This adds meaning beyond the schema's type definitions.
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 for CORS (Cross-Origin Resource Sharing) misconfigurations.' It specifies the resource (URL), the action (test), and the specific focus (CORS misconfigurations), distinguishing it from sibling tools like analyze_headers or httpx_probe.
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 implies usage when CORS misconfigurations are suspected, providing clear context (detecting origin reflection, null origins, etc.). However, it does not explicitly mention alternatives or when not to use this tool, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses high-rate risks ('may trigger IDS/IPS alerts or crash routers'), root requirement, allowed_hosts constraint, and the lack of service detection. These go well beyond the input schema and prepare the agent for real-world consequences.
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 organized with clear sections (description, Args, Returns, Notes) and every sentence adds value: trade-offs, parameter examples, warnings, and prerequisites. It is appropriately detailed for a security tool with four parameters and significant operational caveats, with no redundancy.
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 requiring root, sending raw packets, and running against potentially large networks, the description covers prerequisites (root, allowed_hosts), behavior limitations (no service detection), safety (rate guidance), and return format. It leaves no critical gap given the complexity and absent schema descriptions.
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?
Input schema has 0% description coverage, so the Args section compensates fully. It explains target with an example CIDR, ports with formats, rate with warning guidance, and timeout as an override. This adds semantic meaning beyond raw JSON types, directly addressing each 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 a specific verb+resource: 'Scan a network range for open ports at high speed using Masscan.' It explicitly distinguishes from Nmap via 'significantly faster ... but produces less detailed results (no service detection)', which differentiates it from the sibling nmap_scan tool.
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 clear guidance: 'Ideal for initial port discovery across large IP ranges' and notes the trade-off vs Nmap. It also includes prerequisites like root/sudo, target whitelist in tengu.toml, and rate recommendations for stealth, giving both when-to-use and operational conditions.
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 excels. It discloses the active poisoning behavior, prerequisites (root/sudo, network interface), detectability by NIDS, and the need for permission. It also explains the difference between analyze_only and full poisoning, and the capture duration behavior.
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 clear summary, an Args list, and a highlighted WARNING section. Every sentence adds meaningful information—purpose, parameters, safety, and behavioral guidance—without redundancy. The length is justified by the ethical and legal importance of the warnings.
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 is complex and dangerous, but the description covers purpose, parameters, prerequisites, safety, operational modes, and expected return content ('Captured NTLM hashes and connection attempts'). An output schema is present, so return details need not be in the description. This is complete for an agent to safely and correctly invoke 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?
Although the schema has no descriptions (0% coverage), the description includes an Args section that fully documents all four parameters: interface with examples, analyze_only with its passive-mode behavior, capture_duration with default and max, and timeout as an override. This exceeds the schema and gives the agent complete parameter understanding.
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: 'Capture NTLM credential hashes via LLMNR/NBT-NS poisoning using Responder.' This clearly states what the tool does and distinguishes it from the many scanning and enumeration sibling tools. The method (Responder, LLMNR/NBT-NS poisoning) is explicit.
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 provides strong usage guidance, including a warning that this is an active MITM attack, requires root/sudo, is detectable by IDS, and needs explicit authorization. It also explicitly recommends using analyze_only=True for passive observation, giving a clear alternative mode and when to use it.
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:

[![tengu MCP server](https://glama.ai/mcp/servers/rfunix/tengu/badges/card.svg)](https://glama.ai/mcp/servers/rfunix/tengu)

Score Badge

Copy to your README.md:

[![tengu MCP server](https://glama.ai/mcp/servers/rfunix/tengu/badges/score.svg)](https://glama.ai/mcp/servers/rfunix/tengu)

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/rfunix/tengu'

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