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 privileged access is required and the exact flags used, which is useful. However, it does not mention potential side effects such as intrusiveness, scan duration, or output format, which is a significant gap for a scan tool.

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

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

The description is a single sentence that front-loads the purpose and includes the key flags. It is concise with no redundant words.

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

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

The tool is moderately complex with no output schema or annotations. The description explains the scanning techniques and privilege requirement but does not cover what the output looks like or when to prefer this over sibling tools. It is adequate but not fully 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?

The input schema fully describes all three parameters, so the baseline is 3. The description adds no additional parameter-level detail beyond naming the scan techniques.

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

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

The description clearly states the tool performs a 'comprehensive scan' and enumerates the techniques (SYN scan, service detection, OS detection, default scripts) with specific flags (-sS -sV -O -sC). This distinguishes it from sibling tools like nmap_scan or nmap_service_scan which target individual techniques.

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

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

The description provides clear context by framing this as a comprehensive scan and notes the privileged access requirement. However, it does not explicitly mention when to use this over the more specific sibling tools or when to avoid it (e.g., for a quick scan).

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 provided, the description carries the full burden of disclosing behavior. It mentions the need for privileged access and that detection is attempted, but it does not disclose potential side effects, network activity, accuracy limitations, or what happens on failure. This lack of depth is insufficient for a tool that performs active scanning.

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 concise sentences that are front-loaded with the primary operation ('Perform OS fingerprinting') and include a critical prerequisite. No unnecessary words or repetition are present.

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 simple tool with clear parameters and no output schema, the description provides the essential purpose and a key constraint. However, the lack of guidance on when to use it versus siblings and the sparse behavioral disclosure prevent a higher score, though it is not critically 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?

The input schema descriptions cover all three parameters with meaningful details (target, retries, aggressive mode). The description text itself does not add parameter-specific semantics beyond the schema, so the baseline score of 3 is appropriate given the 100% schema coverage.

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

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

The description clearly states the tool's function as OS fingerprinting using the -O flag, and specifically identifies the goal of determining the operating system of target hosts. This distinctly separates it from sibling tools like nmap_service_scan or nmap_vuln_scan, which have different purposes.

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

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

The description implies the use case when OS identification is needed and notes a prerequisite (privileged access), but it does not explicitly state when to use this tool over alternatives or provide exclusionary criteria. No comparison to sibling tools is given, so 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.

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action (parse) and the input source, but does not describe what the output looks like, how invalid XML is handled, or any side effects. This leaves a significant gap in understanding the tool's behavior.

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 exactly two sentences and every word earns its place. It states the core function first, then adds a usage note. No redundancy or fluff.

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

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

This is a simple tool with one parameter and no output schema. The description conveys the basic purpose and usage context, but because there are no annotations or output schema, it would benefit from specifying what the parsed output contains (e.g., hosts, ports, services). For its low complexity, the description is minimally adequate but not fully 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?

The schema already provides a description for xmlContent with 100% coverage, so the baseline is 3. The tool description adds no extra parameter-level detail, but the schema sufficiently explains the parameter's meaning and format.

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 uses a specific verb "Parse" with a clear resource "nmap XML output", immediately distinguishing it from sibling scan tools. It also mentions the source (previous scan or file), making the tool's function unambiguous.

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 phrase "from a previous scan or file" and "Useful for analyzing saved scan results" clearly indicate when this tool should be used (when XML output already exists). It does not explicitly compare to alternatives, but the context is sufficient for a simple parser.

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 burden. It clearly discloses that this is a non-destructive discovery tool and excludes port scanning, which is core behavioral transparency. It lacks details on potential privilege requirements for certain techniques or output format, but the main behavior is clear.

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

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

The description is two short sentences that immediately state the tool's scope ('Host discovery only (-sn)') and its purpose. Every word contributes, with no fluff 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 simple discovery tool with a well-documented schema, this description is sufficiently complete. It covers the key difference from port scanning, and while it doesn't mention output format, the schema and the tool's nature make this acceptable.

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

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

The input schema provides 100% coverage with descriptions for both 'target' and 'technique', including enum values. The description does not add extra parameter-specific meaning, so the baseline score of 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?

The description clearly identifies the tool's purpose: host discovery using nmap's -sn flag, without port scanning. This is a specific verb-resource combination that immediately distinguishes it from sibling tools like nmap_scan or nmap_service_scan.

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 when you need live hosts in a network and explicitly states it does not perform port scanning. However, it does not name alternative tools or provide explicit when/when-not guidance compared to the sibling 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 provided, the description carries the full burden of disclosure. It clearly discloses the key behavioral trait: scanning fewer ports than default via the -F preset. This is the core trade-off of the tool. It does not mention other potential behaviors (e.g., output format or lack of service detection), but for a simple scan preset, this is reasonably transparent.

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

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

The description is extremely concise, consisting of two short sentences that pack in the preset name, the behavioral difference, and the intended use case. Every word adds value with no redundancy.

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

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

For a simple tool with two parameters and no output schema, the description covers the essential purpose, behavior, and use case. It could be slightly more explicit about the trade-off relative to more comprehensive scans, but it is largely complete for its complexity.

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

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

Schema coverage for parameters is 100%, with both target and topPorts having explicit descriptions in the input schema. The tool description adds no additional parameter-level context beyond what the schema already provides, so the baseline of 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?

The description clearly states the tool performs a fast scan preset (-F) and scans fewer ports than default, which is a specific behavior. It differentiates itself from sibling tools like nmap_scan and nmap_comprehensive_scan by emphasizing quick reconnaissance and reduced port count.

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 phrase 'for quick reconnaissance' provides clear context for when to use this tool. However, it does not explicitly mention when not to use it or name alternative tools for more thorough scans, so it falls short of a 5 but is above implied-only usage.

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 of behavioral disclosure. It only states the core action and output, omitting important traits such as requiring root for SYN scans (though the schema mentions it), potential network impact, or any prerequisites. It does not disclose how results are formatted beyond 'hosts and open ports'.

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 concise sentences, front-loaded with the primary purpose and including only essential scope information (target types and output). No filler or repetition.

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 simple port-scan tool, the description gives a high-level understanding but lacks context on how this fits among the many nmap siblings. It does not describe the output format beyond 'discovered hosts and open ports', and with no output schema, more detail on return structure would be beneficial.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific insight beyond what the schema already provides; it repeats target format support but does not elaborate on port syntax or timing trade-offs.

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

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

The description clearly states a specific verb ('perform') and resource ('nmap port scan'), and specifies 'basic' to distinguish from more specialized scans like service or OS detection. It also mentions supported target formats and returned data, leaving no ambiguity about the tool's purpose.

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 explicit guidance is given on when to use this tool versus the sibling tools. The word 'basic' implies a simple scan but does not directly state exclusions or mention alternatives like nmap_quick_scan for fast scans or nmap_service_scan for version detection.

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 must carry the full burden of behavioral disclosure. It only mentions the number of scripts available, but fails to disclose that many NSE scripts are intrusive, can be noisy on the network, or may take a long time to run. This is a significant gap for a tool with potential 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.

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

The description is two sentences long, front-loaded with the primary action ('Run NSE scripts'), and includes a useful detail (600+ scripts). Every word earns its place, making it an efficient and well-structured description.

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

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

Given the tool's complexity, the absence of annotations, and no output schema, the description is too minimal. It lacks details on script safety, execution time, output format, and how this tool diverges from sibling nmap tools, making it incomplete for confident tool selection and invocation.

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

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

The input schema provides 100% coverage for all four parameters, including descriptions for ports, target, scripts, and scriptArgs. The description adds no additional parameter semantics beyond the schema, 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 clearly states the tool runs NSE scripts for advanced reconnaissance and vulnerability assessment, which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like nmap_vuln_scan, which also targets vulnerabilities.

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

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

No guidance is provided on when to use this tool versus sibling tools such as nmap_vuln_scan or nmap_comprehensive_scan. The description implies usage for advanced recon and vulnerability assessment but offers no exclusions or alternative selection criteria.

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 provided, the description carries the full burden. It clearly states the tool performs version detection and identifies services, but it does not mention that this involves sending network probes, potential intrusiveness, or that it only scans open ports (implied by 'on open ports' but not explicit). No contradictions with annotations exist.

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

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

The description is a single sentence that is both concise and information-dense, providing the verb, flag, and expected outcome without any 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?

The tool is simple (4 params, no output schema), and the description adequately covers the purpose and what it returns ('Identifies service names and versions'). It could be more complete by noting that the scan may take time or that intensity/lightMode affect accuracy, but the schema already covers those, and the description is sufficient for basic selection.

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

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

Schema coverage is 100%, with every parameter described meaningfully. The description adds no additional parameter-level detail beyond the schema, which already explains ports, target, intensity, and lightMode. The baseline of 3 applies because schema carries the weight.

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 uses a specific verb ('Perform service version detection') and identifies the exact Nmap flag (-sV), clearly distinguishing it from siblings like nmap_os_detect and nmap_script_scan. It also states the outcome: identifying service names and versions on open ports.

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 the tool is for service version detection, which gives some usage context. However, it does not explicitly state when to use this tool versus alternatives like nmap_comprehensive_scan or nmap_quick_scan, nor does it mention any exclusions or prerequisites.

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 provided, the description carries the safety and behavior disclosure burden. It clearly states the tool checks accessibility via SSH or locally, implying a read-only status check. However, it does not explicitly state that it has no side effects or what 'configuration' inspection entails.

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 short sentences, front-loaded with the primary purpose. There is no wasted text 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?

Given the zero-parameter signature and lack of output schema, the description adequately covers the tool's scope for a simple status check. It could elaborate on the exact output format, but for a preflight tool the provided information is likely sufficient.

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

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

The tool has zero parameters and the schema shows 100% coverage (vacuously). The description adds no parameter information, but none is needed; the baseline for zero-parameter tools is 4.

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 uses a specific verb ('Check') and identifies the resource ('nmap availability and configuration'), clarifying the tool's function. It also distinguishes itself from the sibling scan tools by noting it checks accessibility via SSH or locally, though it could more explicitly state it is a preflight status check.

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?

Usage context is implied: it checks nmap availability before running scans. However, the description does not explicitly state when to use this tool versus the scan siblings, nor does it mention that it should be run first as a prerequisite.

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 provided, the description carries the full burden for disclosing behavior. It mentions specific evasion techniques but omits critical traits such as scan type, potential side effects (e.g., firewall alerts, slowness), permission requirements, or safety implications. This leaves significant gaps for an agent.

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 only two sentences, front-loading the main purpose and adding relevant detail about techniques. There is no redundancy or filler, making it highly concise and well-structured.

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

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

Given the tool's complexity (6 params, no output schema, no annotations), the description is too minimal. It does not explain how to combine parameters, what the return format looks like, or any operational caveats. The schema covers param names but not deeper usage context, and the description fails to compensate.

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

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

The input schema already provides descriptions for all 6 parameters (100% coverage). The description adds some context by linking decoys, fragmentation, and timing to evasion, but does not go beyond the schema's semantics or provide additional syntax or examples. 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 clearly states the tool's function: a stealth scan using evasion techniques such as timing options, fragmentation, and decoys. This distinguishes it from sibling nmap tools like nmap_scan or nmap_service_scan, providing a specific verb and resource.

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

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

The description implies usage when stealth is needed ('to avoid detection') but does not explicitly state when to choose this tool over alternatives or provide exclusionary guidance. The context is present but not fully developed.

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 behavioral context. It only states the script family and purpose; it does not disclose that the category parameter can select potentially intrusive categories like brute or dos, nor mention output format or safety considerations.

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, front-loading the core action with the exact --script vuln flag and adding one clarifying clause. There is no wasted text.

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?

The description captures the primary purpose but omits the broader category options and any caveats about script behavior or output. It is adequate for basic tool selection but leaves out important context that would help an agent fully understand the tool's scope.

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

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

The input schema provides 100% coverage with descriptions for target, ports, and the category enum. The description adds no additional parameter meaning, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Run vulnerability scanning scripts (--script vuln)' and states it checks known vulnerabilities on target services. It is clear and mostly distinguishes from sibling NMAP tools, though the category parameter allowing exploit/brute/dos is not mentioned.

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 purpose implies when to use it (when vulnerability detection is required), but it does not explicitly state when to prefer this tool over siblings like nmap_script_scan or nmap_service_scan, nor gives any exclusions.

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