PwnBridge

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses the parallel execution model (ZAP + Nuclei), the underlying machine (Kali), the auth support matrix, and the output as a 'versioned consolidated report saved on Kali.' It doesn't mention scan duration, rate limits, or whether it requires the target to be reachable from the Kali machine, but the operational profile is substantially richer than average.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the core action, then engines, then auth, then output. No filler and each sentence adds incremental information. Slightly dense but well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 13-param tool with no annotations and no output schema, the description covers what the tool does, its engines, auth options, and output location. It does not need to explain return values (report is saved, not returned) and the schema handles parameters. Minor gaps around sibling selection and failure modes remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 13 parameters in detail, including enums and defaults. The description adds the auth-mode summary ('HTTP Basic, Bearer token, Cookie injection, Form-based login') and names the two engines, but this is largely redundant with the schema. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Perform Dynamic Application Security Testing (DAST) against a running web application.' It further distinguishes itself by naming the exact toolchain (OWASP ZAP spider + passive/active scan, Nuclei) and scope (running web app). Against siblings like nmap_scan, nikto_scan, or sqlmap_scan, the function is clearly differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for a running web application and lists supported auth modes, but never explicitly states when to choose this over siblings like nikto_scan or sqlmap_scan, nor when-not to use it. For an agent selecting among ten security scan tools, this is a meaningful gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that execution happens on a remote Kali machine, but says nothing about request volume/rate, detectability, runtime, permissions on the Kali host, or how results are surfaced for a high-volume active fuzzing operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: the first front-loads what the tool is and where it runs, the second explains the FUZZ injection marker and the main use cases. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, and the description does not explain result format, where output lands, or runtime expectations for a 7-parameter active scanning tool. It is adequate for purpose and the FUZZ mechanic but leaves the agent guessing about results and operational side effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; every parameter is already documented with examples in the schema. The description adds only a mild note that FUZZ can also be placed in 'headers', which has no corresponding schema parameter, so it adds little usable meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Run ffuf web fuzzer against a target URL') plus the distinctive FUZZ-keyword mechanism, so the agent knows exactly what it does. It does not differentiate itself from the closely related sibling gobuster_scan, which also does directory discovery, so it stops 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Useful for directory discovery, parameter fuzzing, and virtual host enumeration' gives implied usage contexts but never says when to choose this over gobuster_scan, nmap_scan, or sqlmap_scan, and offers no exclusions or prerequisites. Coverage 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden, and it does add one valuable operational fact: the scan runs on a remote Kali machine. However, it omits run-time traits like expected duration, noisiness/intrusiveness, timeouts, or whether results are streamed or returned at completion.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the action and resource, with the discovery outcome second. No filler, though it is brief enough that it could have afforded one more sentence of routing guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter brute-force tool with no annotations and no output schema, the description covers the basics but leaves gaps around authorization assumptions, runtime expectations, and result format. Adequate minimum viability, not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all six parameters including mode semantics and defaults. The description adds no parameter-level detail beyond the mode list, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (run Gobuster enumeration) and resource (directory/file/subdomain targets), and names the three discovery outcomes (hidden paths, files, virtual hosts). It implicitly separates itself from nmap_scan and ffuf_fuzz by naming Gobuster's modes, but never explicitly contrasts with the similarly-scoped ffuf_fuzz sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to choose this over the closely related ffuf_fuzz tool, nor any prerequisites (e.g., needing a valid target, being authorized). The description only describes what the tool does, leaving the agent to infer when it is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full disclosure burden, and it does add one useful fact: the attack executes on a remote Kali machine, not locally. However, it never warns that brute-forcing is noisy, may trigger account lockouts or IDS alarms, requires explicit authorization, or can take arbitrarily long. For a high-risk offensive tool these omissions are significant.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, with the action front-loaded before the protocol coverage. Nothing needs to be cut and nothing is buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nine-parameter, unannotated, no-output-schema offensive tool, the description is thin. It says nothing about what a successful run returns (recovered credentials?), the time cost, lockout risk, or any safety/authorization expectation, all of which an agent needs before invoking a password brute-forcer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each of the nine parameters documented in the schema itself, so this is a baseline 3. The description's protocol list loosely corresponds to the 'service' enum but adds no syntax or usage detail beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific tool, action, and resource: 'Run Hydra password brute-force/dictionary attack against a target service.' It also lists supported protocols, which is enough for an agent to distinguish it from siblings like nmap_scan or sqlmap_scan. It stops short of explicitly contrasting itself with any sibling by name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives (e.g., metasploit_exec, which also has credential attack modules) and no stated prerequisites such as authorization, scope, or network reachability of the target. The agent is left to infer context entirely from the tool's name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that execution is non-interactive, runs a single module, and exits cleanly, which is useful behavioral context. However, it says nothing about required privileges, side effects on the target, timeout behavior, or whether the output is captured, leaving materially important traits undisclosed for a remote exploitation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action and execution context, followed by a scoping constraint. Efficient and free of filler, though the final authorization sentence could arguably be considered boilerplate rather than tool-selection-relevant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter remote exploitation tool with no annotations and no output schema, the description covers purpose, method, and authorization scope. It omits operational expectations an agent would need to call it safely and correctly, such as session handling, expected output, and error behavior. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters including examples and the run_command enum. The description adds no parameter-level detail beyond what the schema provides. Per the rubric baseline, this is a 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Execute') and resource ('Metasploit Framework module') plus the execution context (non-interactively on remote Kali via msfconsole). It is distinguishable from siblings like nmap_scan or sqlmap_scan, but it does not explicitly contrast with shell_exec, which could also run arbitrary commands. Clear purpose, but sibling differentiation is implicit rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides the authorization constraint ('Only for authorized penetration testing engagements') and specifies single-module non-interactive execution, implying when to use it. However, it gives no explicit when-to-use vs alternatives guidance, such as when to pick this over shell_exec or sqlmap_scan. Usage context is implied but not fully delineated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It usefully discloses that execution happens on a remote Kali host and that it probes for dangerous files and misconfigurations, but says nothing about intrusiveness, scan duration, authentication/network prerequisites, or that extra_args can meaningfully change behavior. Some context is added, but key operational traits are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, front-loaded with the action and target, followed by the finding categories. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter scanning tool with no annotations and no output schema, the description covers purpose and detection scope but omits runtime expectations, safety profile, and how to interpret results. Adequate as a minimum-viable definition, with clear gaps for an agent that must decide between it and nine sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents url, port, ssl, and extra_args with examples. The description adds no parameter-level detail beyond the schema, which is the baseline-3 case when structured fields do the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific tool (Nikto), a specific verb (run), a specific resource (web server vulnerability scan), and the execution location (remote Kali machine), plus the classes of findings it produces. This distinguishes it from nmap_scan (port scanning), whatweb_fingerprint (fingerprinting), and sqlmap_scan (SQL injection).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says what the tool does but never states when to reach for it versus siblings like nmap_scan, whatweb_fingerprint, or the generic dast_scan. There are no prerequisites, no exclusions, and no routing guidance for an agent choosing among ten scan/attack tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden, but it discloses almost nothing beyond recon intent and remote execution. It doesn't state noise/detectability level, authorization requirements, runtime or timeout behavior, or whether a scan may be intrusive — all material for a port-scanning tool. The 'remote Kali machine' detail is the one useful behavioral note.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences with the core action front-loaded and the reconnaissance use case following. No filler, though it could have used the space to note a behavioral constraint instead of restating the purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter tool with full schema coverage and no output schema, the description covers what the tool does and roughly when to use it. It is adequate but leaves behavioral gaps (detectability, auth, timing) unaddressed for a network-scanning operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the enum for scan_type is fully documented in the schema, including profile meanings and the ports override. The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Run an nmap port scan against a target host or network on the remote Kali machine,' naming the exact tool and execution environment. An agent can distinguish it from siblings like nikto_scan, sqlmap_scan, or gobuster_scan by the resource and method, though it doesn't explicitly contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use for reconnaissance: discovering open ports, running services, and OS detection' gives a clear use context. However, it names no alternatives (e.g., whatweb_fingerprint for web fingerprinting) and states no exclusions, so routing decisions between siblings are only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses that source is synced off-machine to Kali over SFTP, that the consolidated report is written to the Kali host (not locally), and that uploaded source is deleted after scanning — materially important side effects. It omits prerequisites such as Kali connectivity/credentials and failure behavior, so it falls short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly packed sentences with the core action front-loaded, followed by execution mechanics and cleanup semantics. No filler or restatement of the tool name, and every clause conveys operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that depends on external infrastructure (Kali host, SFTP) there are no annotations or output schema to fill gaps, and the description never says what the caller receives back, where the versioned report lives, or what happens on connection failure. It covers the pipeline well but leaves the calling contract and prerequisites underspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters including the tool enum and Bandit's Python-skip behavior. The description only echoes the engine list and adds no parameter-level meaning, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb (Perform SAST) plus precise resource (a local code directory), and the description enumerates the exact engines run (Semgrep, Bandit, Gitleaks, Graudit). This cleanly separates it from the dynamic/network siblings like dast_scan, nikto_scan, and nmap_scan without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Local code directory" implies the usage context (source you own, on disk) versus the remote-target siblings, but the description never explicitly states when to prefer this over dast_scan or names any alternative. No prerequisites or exclusions are given, leaving routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full behavioral burden. It adds a warning that this is an escape hatch and should be avoided when dedicated tools suffice, which is useful context. However, it does not disclose critical behavioral traits for arbitrary shell execution, such as privilege level, potential destructiveness, reversibility, or output handling, leaving significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tight sentences with zero waste, front-loading the core action and following immediately with the critical usage warning and restriction. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity tool like arbitrary shell execution with no annotations and no output schema, the description covers purpose and usage guidance well. However, it does not explain return values, error behavior, or execution context (e.g., whether output is captured, how errors are surfaced), which an agent would need to call it correctly without an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters ('command' and 'timeout_ms') are already well documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Execute') and resource ('arbitrary shell command on the remote Kali Linux machine'), and it distinguishes itself from the many specific scanning siblings by framing itself as an escape hatch to be used only when dedicated tools don't cover the need. An agent can immediately tell what this tool does and when it is appropriate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent when to use this tool ('escape hatch for advanced scenarios', 'commands not covered by dedicated tools') and when not to ('prefer specific tools'). The alternative is named as a category ('specific tools') even if individual siblings aren't listed, which is sufficient to route correctly given the sibling set is visible elsewhere.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden and mostly fails it. It hints at active exploitation ('exploits SQL injection vulnerabilities') and notes execution on a remote Kali machine, but says nothing about authorization requirements, typical runtime, or that dump/risk=3 can extract data or stress the target.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and target, and free of filler. There is mild redundancy in restating 'SQL injection' twice (testing vs. detection/exploitation), which keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a potentially destructive offensive-security tool with no annotations and no output schema, the description is too thin: it does not describe what results are returned, how long a scan typically takes, or any safety/authorization caveat. The rich parameter schema compensates partially, but the behavioral picture remains incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters (url, data, dbms, dump, risk, level) are already documented with examples and defaults in the schema. The description adds no parameter meaning beyond that, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific tool (sqlmap), a specific vulnerability class (SQL injection), and the target (a URL), which cleanly separates it from nmap_scan, gobuster_scan, and whatweb_fingerprint. It does not, however, explicitly contrast itself with the closest sibling, dast_scan, leaving that distinction to the agent's own knowledge.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance: nothing says this should follow reconnaissance, that the URL must contain testable parameters, or when dast_scan/nikto would be the better choice. The agent must infer routing entirely from the tool name and the single sentence of purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It does add one genuinely useful fact – execution happens on a remote Kali machine – but it omits that this is a read-only reconnaissance probe, that it generates live requests to the target, and that the aggression parameter controls how noisy/detectable the scan is. Those are the traits an agent most needs before invoking it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, both earning their place: the first front-loads the verb, resource, and execution environment; the second lists the identification targets. No filler or repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Parameters are fully documented in the schema, but there is no output schema, so the description should ideally say something about what is returned (report format, findings structure) and when this tool fits into a recon workflow. With no annotations and no output schema, the definition is adequate but leaves real gaps for an agent deciding among the scanning siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both params (url and aggression) are already documented in the schema, including the aggression level semantics. The description adds no parameter-level meaning beyond that, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Run WhatWeb web technology fingerprinting against a target URL") and enumerates what it identifies (technologies, CMS, frameworks, server software, plugin versions). This clearly separates it from vulnerability-adjacent siblings like nikto_scan or nmap_scan, though the description never names or contrasts those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description never states when to choose this tool over nmap_scan, nikto_scan, or gobuster_scan, nor any prerequisites or when-not-to-use conditions. An agent must infer that this is the passive fingerprinting option purely from the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.