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

Annotations indicate destructiveHint:true and readOnlyHint:false, but the description does not explain the destructive nature (e.g., network noise, potential detection). It adds value by stating the network segment constraint and that it returns IP, MAC, hostname, and vendor, but lacks details on rate limits or 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, front-loaded with purpose and key differentiator, followed by return values and a constraint. Every sentence is essential; no redundant or vague phrasing.

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 one parameter and no output schema, the description covers purpose, return values, and a network constraint. It could mention privilege requirements (e.g., root/administrator) for completeness, but overall it is adequate.

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 covers the single parameter 'cidr' with a description and example. The tool description does not add additional meaning or format details beyond what the schema provides. With 100% schema coverage, 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 'Layer 2 LAN host discovery — finds ALL devices on local network including those that block ICMP/TCP', specifying the verb (finds) and resource (devices on local network), and distinguishes from higher-layer tools like ping_sweep and port_scan by noting it works even when ICMP/TCP is blocked.

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 gives clear context: use this tool for discovering all devices on the local network segment, especially those that block ICMP/TCP. It mentions the constraint 'Only possible from a machine on the same network segment', which helps an agent decide when to use it. However, it does not explicitly name sibling tools 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.

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

The description lacks critical behavioral details beyond 'Audit'. It does not clarify that it makes HTTP requests (relevant to destructiveHint=true), or that results may vary over time. The destructiveHint annotation is not explained and seems inconsistent with a read-like 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?

The description is concise and front-loaded, consisting of two short sentences that cover purpose, specifics, and output. No wasted 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 description covers the basic action and output (score/grade) but omits context like network access requirements, interpretation of the score, and potential side effects. Without an output schema, more detail on return values would improve completeness.

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?

With 100% schema description coverage, the parameter is well-documented in the schema. The tool description adds no additional semantic meaning beyond what the schema provides, meeting the baseline.

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 action ('Audit') and target ('HTTP security headers of a URL'), listing specific headers checked and output format. It distinguishes from sibling tools focused on network scanning or port inspection, though it could explicitly state it does not perform deeper vulnerability scanning.

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 no guidance on when to use this tool versus alternatives like ssl_inspect or check_cves. It does not mention prerequisites (e.g., URL must be accessible) or typical use cases.

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?

Annotations already include destructiveHint=true, and the description adds no further behavioral context (e.g., whether connections are closed gracefully or side effects). The description is accurate but does not enhance transparency beyond the annotations.

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 long, front-loaded with the main action, and every word adds value. There is no unnecessary information, 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 simple nature of the tool, the description covers the core functionality and mentions protocol variety. The lack of output schema means the agent might wonder about the banner format, but for a raw capture tool this is acceptable. Overall, it is sufficiently 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 is 100%, so each parameter has a description in the schema. The tool description does not add any extra meaning or usage nuance to the parameters; it merely restates the tool's action, making the baseline score of 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 clearly states the tool connects to a TCP port and captures the raw service banner. It distinguishes itself from HTTP fetching and lists example protocols (SSH, FTP, etc.), making the purpose explicit and differentiated from siblings like port_scan or audit_headers.

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 contrasts with HTTP fetching, suggesting when to use this tool over HTTP-specific tools. However, it does not provide explicit 'when not to use' or mention alternative tools among siblings, leaving some room for improvement.

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?

Annotations are already present (readOnlyHint=false, destructiveHint=true). The description adds context about hardware necessity but does not elaborate on the destructive nature implied by the annotation. No contradiction, but limited additional insight.

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 concise sentences: first covers purpose and output, second adds a critical constraint. No unnecessary words, front-loaded with key 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?

Given the absence of output schema and parameters, the description adequately covers the tool's function and a key constraint. Minor missing details (e.g., 'type' definition) do not significantly reduce completeness for a simple scan tool.

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?

No parameters are defined, so schema coverage is 100%. Per guidelines, baseline for 0 params is 4. The description does not need to add parameter info and does not.

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 action (scan), resource (nearby Bluetooth devices), and output details (device name, address, type, pairing status). It distinguishes itself from siblings by emphasizing local hardware requirement.

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 states the prerequisite (physical Bluetooth adapter) and rules out usage in cloud environments. It does not name alternative tools but provides clear context for when to use.

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?

Description says 'check', implying read-only, but annotation destructiveHint=true indicates it may be destructive. This contradiction undermines transparency, and no further behavioral context is provided.

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 concise sentences, the first explaining the core function and the second adding a key constraint (no API key). No wasted 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?

No output schema, and description does not explain what the tool returns or any side effects. The annotation contradiction adds confusion. Given low complexity, more detail on output and behavior is needed.

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?

Only one parameter 'path' is fully described in the schema (100% coverage). The description adds no extra meaning beyond what the schema provides, so 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?

Description clearly states the tool checks npm dependencies against the OSV vulnerability database, with a specific verb and resource. It differentiates from siblings like port_scan or supply_chain_audit by focusing on npm and stating no API key is needed.

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?

Description provides a clear use case (check npm dependencies) and mentions no API key is needed, but does not explicitly state when not to use or compare to alternatives like supply_chain_audit.

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?

The description goes beyond annotations by explaining that 'baseline' saves SHA-256 hashes to disk (destructive side effect) and that 'check' compares against saved baseline. It also mentions detecting world-writable files and overly permissive SSH keys. However, it does not explicitly state whether the baseline action overwrites existing files or if the tool requires elevated permissions, which would add further transparency.

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 paragraph of three sentences that efficiently conveys purpose, actions, and file coverage. It front-loads the core function. While it could be slightly more structured (e.g., list actions), it remains concise and readable without superfluous 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?

Given the tool has no output schema, the description adequately covers the three actions and file scopes. It lacks example output or notes on permissions, but for a file integrity monitor, the core behavior is well-described. The annotations (destructiveHint) are consistent, and no critical information is missing for an agent to use the tool.

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?

With 100% schema coverage, the description adds value by elaborating on the 'action' parameter with example values, providing a default path for 'baseline_file', and explaining that 'extra_paths' are comma-separated and extend defaults. This clarifies usage beyond the schema's short descriptions.

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 as monitoring critical system files for unauthorized changes, detailing three specific actions (scan, baseline, check) and the types of files covered (SSH keys, shell profiles, /etc/hosts, etc.). This distinguishes it from sibling tools like file_watch or hash_files, which have different scopes or 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 explains what each action does but provides no guidance on when to use this tool versus alternatives. It does not mention limitations, prerequisites, or when not to use it. For example, it doesn't clarify if this tool should be used instead of file_watch for real-time monitoring or persistence_scan for persistence 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?

There is a clear contradiction: the description states 'enumerate' (a read operation), but annotations set destructiveHint=true and idempotentHint=false. This misalignment undermines behavioral transparency. Additionally, no details about network access, rate limits, or potential side effects are provided.

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, information-dense sentence with no filler. It front-loads the primary purpose and lists specifics concisely.

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 omits any mention of output format or return structure, which is especially relevant since no output schema is provided. It addresses core functionality but lacks completeness for an agent to fully anticipate results.

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 clear description for the single 'domain' parameter. The description adds no additional semantic context beyond what the schema offers. With full schema coverage, a baseline score of 3 is appropriate.

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

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

The description specifies the verb 'enumerate' and resource 'DNS records for a domain', listing specific record types (A, AAAA, MX, NS, TXT, CNAME) and additional detection of missing SPF/DMARC. This clearly distinguishes it from sibling tools like port_scan or ping_sweep.

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 DNS records are needed, but does not provide explicit when-to-use or when-not-to-use, nor mention alternatives. Given the sibling list includes no other DNS-specific tools, it is somewhat clear but lacks guidance on prerequisites or edge cases.

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?

Description claims non-destructive monitoring (captures events) but annotations set destructiveHint=true, a contradiction. Also readOnlyHint=false conflicts with the read-only nature of watching. The description does not resolve or acknowledge these inconsistencies.

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, front-loaded with the action and key details. The last sentence provides context but could be considered slightly informal; overall concise and effective.

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 100% schema coverage and no output schema, the description adequately explains the tool's behavior (real-time capturing of events, kernel-level mechanism). Missing potential output format info, but acceptable for a monitoring tool.

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 descriptions fully cover both parameters (path and seconds). Description adds no additional parameter semantics beyond what the schema provides, maintaining baseline score.

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?

Clearly states it watches files/directories for changes using kernel events, listing event types. However, does not differentiate from sibling tool 'critical_file_monitor' which might serve 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.

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

Implies usage when real-time file monitoring is needed in a background process, but lacks explicit guidance on when not to use or comparison to alternatives like 'critical_file_monitor'.

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?

The description claims the tool 'reads local disk' and computes hashes, implying a read-only operation. However, annotations indicate destructiveHint=true and readOnlyHint=false, suggesting the tool may have destructive side effects. This contradiction undermines transparency.

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 with no unnecessary words. The purpose is stated first, followed by use cases and a key constraint. Every sentence adds value.

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 covers core purpose, use cases, and a constraint. However, it does not mention output format, potential performance impact, or reconcile the annotation contradiction, leaving gaps for a tool with destructiveHint=true.

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 fully describes the 'path' parameter with a description that includes 'recursively'. The tool description adds context about the directory and algorithm but does not add significant new semantic meaning beyond the schema.

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 verb 'Compute SHA-256 hashes' and the resource 'all files in a directory'. It provides specific use cases (integrity baselines, tampering detection) and distinguishes from sibling tools that focus on network or system scanning.

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 explains when to use the tool (creating integrity baselines, detecting tampering) and notes that it only works locally ('Reads local disk — not possible remotely'). However, it does not explicitly mention when not to use it or suggest alternatives.

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?

The description adds value by detailing the local analysis and security warnings (expired token, 'none' algorithm). However, the annotations indicate destructiveHint=true and readOnlyHint=false, which contradict the tool's expected read-only behavior. The description does not mention any destructive side effects, creating a mismatch that reduces trust.

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 core purpose, and contains no superfluous words. 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?

Given the tool's simplicity (one parameter, no output schema), the description covers the purpose, local operation, and output elements (header, payload, expiry, algorithm, security warnings). It lacks details on error handling or return format, which a fully complete description might include, but it suffices for this context.

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?

With 100% schema description coverage and a single parameter 'token' already described in the schema, the description adds context about local decoding and output details but does not enhance the parameter's meaning beyond the schema.

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 decodes and analyzes JWT tokens locally. It specifies the resource (JWT token) and actions (decode, analyze). Among sibling tools focused on network scanning and other security tasks, this tool is distinct and 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 description implies local use ('without sending it anywhere') but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use guidance. The context suggests it's for local JWT analysis, but no direct comparisons or exclusions are given.

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?

The description claims a read-only operation ('List active network connections'), but the annotations set readOnlyHint=false and destructiveHint=true, creating a direct contradiction. The description does not disclose any behavioral traits beyond the basic output, such as permissions required, side effects, or performance impact. This inconsistency severely undermines trust.

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, concise sentence that is front-loaded with the core action and resource. Every part serves a purpose: the verb, resource, analogy, and output details. No redundant words or clutter.

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 no output schema and no parameters, the description covers the basic output fields (local/remote address, state). However, it omits details like protocol (TCP/UDP), process information (PID/name), and whether the snapshot is real-time. These are reasonable expectations for a 'netstat'-like tool, leaving the agent with incomplete context.

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?

With zero parameters and 100% schema coverage (trivially), the baseline is 4. The description adds value by specifying the output details ('local/remote address and connection state'), which is helpful since there is no output schema. No further enrichment is needed.

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 verb 'List' and the resource 'active network connections on this machine', with an analogy to 'netstat' for familiarity. This distinguishes it from sibling tools like port_scan (remote scanning) and arp_scan (ARP table), 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.

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

The description uses 'like netstat' as an analogy, which implicitly suggests usage for inspecting network connections. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., port_scan for remote ports, wifi_scan for wireless interfaces). No 'when not to use' or prerequisites are mentioned, which is a 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?

The description states 'List files, sockets, and pipes' indicating a read-only operation, but the annotations set destructiveHint=true and readOnlyHint=false, contradicting the described behavior. This is a serious inconsistency that misleads the agent about potential side effects. No additional behavioral details (e.g., privilege requirements, performance impact) are provided.

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 very concise with two sentences that front-load the core purpose. Every word adds value, and the structure efficiently communicates what the tool does, including a practical note about lsof.

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 no output schema, the description partially explains return values ('shows exactly what a process is reading, writing, or listening on'), but lacks structured details. The contradiction with annotations undermines completeness regarding behavior. For a tool with one optional parameter and no heavy nesting, this is adequate but leaves gaps about the actual response format.

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 the filter parameter already described as 'Process name or PID to filter (optional — leave empty for all).' The description merely repeats this ('Filter by process name or PID') without adding extra meaning or examples, meeting the baseline for full 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 purpose: listing files, sockets, and pipes opened by processes. It uses a specific verb ('List') and resource ('files, sockets, pipes currently open by processes'), and the scope (filter by process name or PID) distinguishes it from sibling tools like proc_list, net_connections, etc.

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 inspecting open file descriptors via 'Uses lsof — shows exactly what a process is reading, writing, or listening on.' However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., when a network connection is needed vs. file handles). No when-not or exclusions are mentioned.

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?

The description says 'scan,' which implies read-only behavior, but the annotations include destructiveHint: true, creating a contradiction. The description does not disclose any potential side effects or required permissions, and the contradiction undermines trust. Score 1 due to annotation contradiction.

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, front-loading the core action and listing specifics efficiently. Every sentence adds value with no wasted words.

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

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

The description covers what the tool does and when to use it, but with destructiveHint: true and no output schema, it should mention potential side effects or return format. Still, for a zero-parameter scan tool, it is mostly 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?

There are no parameters, so schema coverage is 100%. With zero parameters, the description need not add parameter details, so baseline score 4 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 scans for malware persistence mechanisms, listing specific types (LaunchAgents, systemd units, cron jobs, shell profile injections) and flagging high-risk patterns. This is a specific verb+resource that distinguishes it from sibling tools like arp_scan or port_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 explicitly says 'Essential first step when investigating a potentially compromised machine,' providing clear usage context. However, it does not mention when NOT to use the tool or suggest alternatives, though the sibling list implies other scanning tools for different purposes.

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?

Annotations indicate destructive hint, but description does not explain potential network disruption or detection risks. The statement 'Claude cannot send ICMP packets' is contradictory to the tool's apparent function, reducing transparency.

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 plus a tangential note about Claude's inability. While concise, the note adds unnecessary complexity and could be removed.

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?

No output format or behavioral details (timeouts, permissions, rate limits) are provided. For a potentially destructive tool, more operational context is needed.

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 already describes the single parameter with 100% coverage. Description adds example and context but not beyond what schema provides, meeting baseline.

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?

Description clearly states it sends ICMP pings to a CIDR range to find live hosts, and differentiates from port_scan by noting it works without open TCP ports. However, the note about Claude's inability to send ICMP packets could confuse the 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?

Implicit guidance from 'works on the local network' and 'finds hosts even if they have no open TCP ports' suggests use cases, but no explicit comparison to siblings like arp_scan or conditions for when not to use.

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

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

Annotations indicate destructiveHint=true, and the description adds behavioral context about using 200 concurrent goroutines. However, it does not elaborate on potential side effects or network impact beyond what annotations imply.

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—two sentences—with no wasted words. It front-loads the purpose and adds a performance note efficiently.

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 no output schema, the description should clarify return format more. It mentions 'Returns open ports with service guesses' but lacks detail on structure or pagination. Complexity is low, but completeness is moderate.

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 parameters are already well-documented. The description adds no further detail about parameter semantics, such as the meaning of timeout or default ranges.

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 TCP port scan on a host and returns open ports with service guesses. It uses specific verbs and nouns, distinguishing from siblings like arp_scan and bluetooth_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 mentions speed ('fast') and the fact that Claude cannot do this natively, implying usefulness. However, it does not explicitly state when to use this tool versus alternatives or 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.

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

The description claims read-only listing, but annotations set destructiveHint=true, creating a contradiction. No additional behavioral context (e.g., permissions, side effects) is disclosed beyond the contradictory annotations.

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 with no wasted words. The purpose is front-loaded immediately: 'List running processes on this machine.' Efficient and clear.

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?

Describes output fields (PID, CPU%, memory, command), which is helpful without an output schema. However, it lacks notes on authorization, performance impact, or potential destructive behavior hinted by annotations.

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 single parameter 'filter' is already fully described in the schema (substring match). The tool description does not add any extra meaning beyond what is provided in the schema, so 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 states it lists running processes with specific resource (processes) and verb (List). It mentions optional filtering, making it distinct from sibling tools that focus on network or security scans.

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 use this tool vs alternatives (e.g., sys_info, net_connections). The description only states what it does, not context or exclusions.

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?

The description portrays a read-only scanning operation, but the annotation destructiveHint is true, indicating potential destructive side effects. This contradiction is not addressed. The description fails to disclose any behavioral traits beyond the surface action, especially given annotations do not fully align.

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?

Single sentence with no wasted words. Front-loaded with the core action and includes specific examples of secrets scanned, making it efficient and informative.

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?

Does not describe the return format or structure of findings. Without an output schema, the agent lacks information on how to interpret results (e.g., list of matches, locations, severities). The reference to '20+ patterns' is insufficient.

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 a clear description of the 'path' parameter as 'Absolute path to a file or directory'. The description adds no extra meaning, which is acceptable since the schema already defines the parameter well.

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?

Clearly states the tool scans files/directories for hardcoded secrets, listing specific types (AWS keys, GitHub tokens, etc.). The verb 'scan' and resource 'file or directory' are precise, and it differentiates from sibling scan tools like port_scan and arp_scan that operate on networks rather than files.

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 use this tool versus alternatives, no prerequisites, and no mention of when not to use it. The description simply states functionality without context for decision-making.

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?

Annotations set destructiveHint: true, implying the tool may modify state, but the description calls it 'Inspect' (read-only). No clarification is provided about side effects (e.g., network connections that could trigger alarms), rate limits, or the impact of the destructive hint. This inconsistency reduces transparency.

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, front-loaded with the action and resource. Every word is necessary and adds value. No redundant statements 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?

For a tool with two simple parameters and no output schema, the description adequately covers what it does and what it returns. However, it does not mention error conditions (e.g., unreachable host) or the fact that port must be numeric, but these are minor given the schema already specifies type number.

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?

Both parameters have schema descriptions (100% coverage). The description adds contextual meaning by explaining what the tool does with the inputs (inspects certificate chain) and what it returns, which complements the schema. It does not repeat schema details but enhances understanding.

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 the verb 'Inspect' and identifies the resource as 'full TLS certificate chain of a host'. It lists specific return values (expiry countdown, issuer chain, SANs, key size, weak-config warnings), making the tool's purpose concrete and distinct from sibling network tools like banner_grab or port_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?

No explicit guidance on when to use this tool versus alternatives (e.g., banner_grab also deals with TLS). The description does not mention prerequisites, typical use cases, or scenarios where other sibling tools would be more 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?

Annotation sets destructiveHint=true but description says 'reads local filesystem', which is contradictory and not explained. No disclosure of whether scripts are executed or files modified.

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?

Compact description with front-loaded purpose; every sentence adds unique detail. Minor improvement could combine lines.

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?

Adequate for a simple one-param tool with annotations, but no output schema and lack of clarification on destructive hint leaves gaps for agent decision-making.

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?

Single parameter 'path' with schema description specifying absolute path and required files. Description adds minimal extra value beyond schema (checks node_modules). Baseline 3 due to 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?

Clearly states the tool audits Node.js dependencies for supply chain attack indicators, listing specific checks (dangerous lifecycle scripts, typosquatting, eval). Distinguishes from siblings like port_scan or check_cves.

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 context about reading local filesystem and not using remote services, implying privacy benefit. However, no explicit when-not-to-use or comparison to alternatives among siblings.

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?

The description claims the tool 'Reads from local hardware', implying a non-destructive read operation, which contradicts the annotation 'destructiveHint: true'. No other behavioral traits are disclosed beyond the contradictory annotation.

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 efficiently conveys the tool's function and key detail (local-only). No extraneous 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?

Given no output schema and the complexity of system information, the description provides a good overview of what is returned. However, it lacks details on the return format and does not address the annotation contradiction.

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 has no parameters, so schema description coverage is 100%. The description adds value by detailing the information returned (CPU, RAM, disk, etc.), which is helpful beyond the empty schema.

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 purpose: 'Get detailed local system information', listing specific hardware and network details. It distinguishes from siblings by highlighting that it reads from local hardware and is not available via any remote service.

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 implicitly guides usage by stating the tool reads from local hardware, suggesting it is for local system checks. However, it does not explicitly list when not to use or provide alternatives like remote services.

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?

Annotations set destructiveHint=true, but the description does not detail destructive behavior. However, it adds important behavioral context beyond annotations: the tool requires raw sockets, which may not be available in Claude's environment. This transparency about operational feasibility is valuable for an agent deciding whether to invoke the 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 consists of two short sentences. The first sentence clearly states the action and method, the second explains the result and a critical limitation. Every word serves a purpose, and the structure is front-loaded with the core functionality.

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 simplicity (two parameters, no output schema), the description adequately explains what the tool does and its result: 'Shows every router between this machine and the target.' It also highlights the limitation about raw sockets. However, it does not describe the output format or provide examples, but completeness is sufficient for this straightforward tool.

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 all parameters described in the input schema. The description does not add additional semantics beyond what the schema already provides. Baseline score of 3 is appropriate since the description adds no extra parameter information.

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 action: 'Trace the network path to a host hop-by-hop using ICMP TTL probes'. It identifies the specific resource (network path) and the method (ICMP TTL probes), and it distinguishes itself from sibling tools like ping_sweep and port_scan by focusing on hop-by-hop tracing.

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 mentions a key limitation: 'Requires raw packet sending — Claude cannot do this.' This gives some guidance on when the tool cannot be used. However, it does not explicitly state when to use this tool over alternatives or provide context on prerequisites or typical scenarios.

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?

Description claims a read-only operation ('List', 'Reads'), but annotations set destructiveHint=true, which contradicts. This is a serious inconsistency. The description does add value by stating it's local, but the contradiction overrides.

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 with no waste, front-loaded with action and returns. Efficient and clear.

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?

List of return fields is provided, though no output schema exists. Tool is simple and description covers essentials. Minor gap: does not mention if any filtering is possible (but parameters are none).

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?

No parameters exist (schema coverage 100%). Baseline score of 4 is appropriate since description adds no param info but none is needed.

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?

Description clearly states it lists USB devices, specifies return fields (name, vendor, product ID, speed, manufacturer), and distinguishes itself from sibling tools by focusing on USB enumeration.

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?

Description implies local-only usage and explicitly mentions no remote enumeration, but does not provide alternatives or when-not-to-use scenarios. Good context but no exclusions.

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?

The description adds that scanning uses local hardware and returns specific fields. However, given annotations indicate destructiveHint=true (potential system impact) and idempotentHint=false, the description could elaborate on side effects like network disruption or detection risk.

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 with no wasted words: first states purpose and return data, second provides crucial usage constraint. Front-loaded with key 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?

Although no output schema exists, the description lists the returned fields sufficiently. It doesn't cover administrative privileges or ordering, but for a simple scanning tool the information is adequate.

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?

With no parameters in the input schema (100% coverage trivially), the description's explanation of what the tool does and returns adds meaning beyond the schema. A baseline of 4 is appropriate for zero-parameter tools.

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?

Description clearly states the tool scans Wi-Fi networks and lists specific return fields (SSID, BSSID, signal strength, channel, security type). This distinguishes it from sibling tools like bluetooth_scan or port_scan by focusing on Wi-Fi specific data.

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?

Explicitly notes requirement for physical Wi-Fi hardware and that Claude cannot perform it remotely. This provides a clear condition for when to use or avoid the tool, though it does not mention alternative tools for remote scanning.

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