Server Quality Checklist

Tool Scores

• kali_run_nmapB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only says it 'runs Nmap,' with no mention of potential side effects, runtime duration, network exposure, permission requirements, or behavior on failure. This is a meaningful gap for an unannotated scanning tool.

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

  Conciseness4/5

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

  The description is compact and front-loaded with the core action. The Args section is brief and adds necessary parameter context without repeating boilerplate from the schema.

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

  Completeness3/5

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

  The output schema covers return-value details, so that gap is acceptable. However, for a command-execution tool with no annotations, the description omits important operational context such as expected runtime, safety considerations, and when to prefer the generic kali_execute_command instead. It adequately covers the two parameters but not the surrounding usage context.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must add meaning beyond bare property names. It does so by specifying target formats ('IP address, hostname, or subnet') with concrete examples, and by explaining that options are Nmap flags with a default and intent ('fast service version scan').

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

  Purpose4/5

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

  The description states a specific verb ('Runs'), the resource (Nmap), and the general target ('target hosts'), so the tool's purpose is clear at a glance. It distinguishes itself from sibling scanners like sqlmap and gobuster, though it doesn't explicitly contrast with the generic kali_execute_command sibling.

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

  Usage Guidelines2/5

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

  The description gives no guidance about when to use this tool versus alternatives such as kali_execute_command, kali_run_sqlmap, or kali_run_gobuster. There are no stated prerequisites, exclusions, or context cues to help an agent choose this tool over another.

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

• kali_execute_commandB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It does add useful context about the timeout terminating the command and the default working directory, but for an arbitrary shell execution tool it omits important traits: it does not mention that commands can mutate the host filesystem or system state, what happens on non-zero exit codes, whether output is captured and returned, or what privileges the command runs with.

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

  Conciseness5/5

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

  The description is compact and front-loaded with a one-sentence purpose followed by a clean parameter list. Every sentence adds meaningful information, and there is no filler or redundant restatement.

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

  Completeness3/5

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

  The description covers the basic invocation details for all three parameters, and an output schema exists so return-value documentation is less critical. However, for a dangerous raw shell execution tool with no annotations, the description remains incomplete because it lacks guidance about side effects, command failure behavior, and how this tool relates to the specialized Kali sibling tools.

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

  Parameters4/5

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

  The input schema has no descriptions, so the description compensates well by explaining all three parameters, giving defaults for timeout_seconds and cwd, and providing a realistic command example. However, the stated cwd default './kali_workspace' conflicts with the schema's default of null, which introduces ambiguity and prevents a perfect score.

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

  Purpose4/5

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

  The description clearly states the verb 'executes' and the resource 'shell command on the Kali Linux host system', with concrete examples like 'nmap -sS 192.168.1.1'. However, it does not explicitly distinguish itself from sibling specialized tools such as kali_run_nmap or kali_run_sqlmap, and the example commands actually overlap with those tools, so it stops short of a 5.

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

  Usage Guidelines2/5

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

  There is no guidance on when to prefer this generic executor over the specialized sibling tools. The description even gives 'nmap' and 'nikto' as examples, which could mislead an agent into using this tool instead of kali_run_nmap or other dedicated wrappers. No when-to-use or when-not-to-use conditions are provided.

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

• kali_run_gobusterB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It mentions that the tool runs a brute-forcer, but does not disclose that it actively sends network requests, may require authorization, or could generate significant traffic. This is a notable gap for a security scanning tool.

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

  Conciseness5/5

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

  The description is short, front-loaded with the main purpose, and uses a clear Args list. Every sentence adds value, specifically the defaults and examples, without unnecessary fluff.

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

  Completeness2/5

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

  While an output schema exists and parameter details are covered, the description lacks important contextual information: when to choose gobuster over other enumeration tools, that it performs active scanning, and any authorization or caution notes. For a brute-forcing tool, these are significant omissions.

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

  Parameters4/5

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

  The input schema has 0% description coverage, so the description must compensate. It does so by providing a target URL example, a default wordlist path, and an example of the options flag format, giving meaningful guidance for all three parameters.

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

  Purpose5/5

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

  The description clearly states the tool runs Gobuster, a URI/directory brute-forcer, with a specific verb and resource. This distinguishes it from sibling tools like kali_run_nmap and kali_run_sqlmap, which target different scanning tasks.

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

  Usage Guidelines2/5

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

  There is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusions. The description only states what the tool does and lists arguments, leaving the agent to infer the appropriate context.

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

• kali_run_searchsploitA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description must carry the full behavioral burden, but it only says the search is offline via Searchsploit. It does not disclose what the search returns, whether it invokes a new process, or any execution constraints.

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

  Conciseness5/5

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

  The description is two short sections with no fluff, front-loads the purpose, and keeps the parameter documentation immediately accessible in an 'Args' block.

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

  Completeness3/5

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

  For a single-parameter search tool with an output schema, the core invocation is adequately specified. However, the missing usage guidance and minimal behavioral detail leave an agent with only the tool name and one sentence to decide when and how confidently it should be used.

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

  Parameters4/5

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

  The schema has no parameter description (0% coverage), so the description's 'Args' section compensates by explaining query as 'Search keywords' and giving concrete examples for Apache, WordPress, and Linux Kernel. This gives an agent a clear template for the only required parameter.

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

  Purpose5/5

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

  The description names a specific verb and resource: it 'Searches Exploit-DB offline database via Searchsploit,' which clearly differentiates it from siblings like nmap, sqlmap, or gobuster. The scope is unmistakable.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to choose this tool over alternative Kali tools or the sibling kali_search_tools. There is no mention of scenarios, prerequisites, or exclusions; the 'offline database' phrase only weakly implies the use case.

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

• kali_get_tool_helpA
  3.9/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden. It transparently states that the tool retrieves documentation rather than executing the target tool, which implies a read-only, non-destructive operation. This is adequate for a simple help-retrieval tool, though it does not discuss edge cases like unavailable tools.

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

  Conciseness5/5

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

  The description is concise and front-loaded with the core purpose in the first sentence. The Args section adds necessary parameter context without redundancy or filler.

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

  Completeness4/5

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

  For a single-parameter, read-only help tool with an output schema, the description provides enough information to select and call it. It could be slightly stronger with explicit guidance about when to use it relative to the specialized run_* siblings, but overall it is complete.

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

  Parameters4/5

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

  The schema provides no description for tool_name, but the tool description compensates by defining it as the binary utility name and giving concrete examples ('nmap', 'sqlmap', 'john', 'aircrack-ng'). This is sufficient for correct invocation.

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

  Purpose4/5

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

  The description clearly states the tool retrieves manual or --help documentation for any Kali Linux tool, which is a specific verb and resource. It is distinguishable from siblings like kali_execute_command and kali_run_nmap, though it does not explicitly name an alternative.

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

  Usage Guidelines3/5

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

  The phrase 'for any Kali Linux tool' implies this is the general-purpose help tool, distinct from the specialized run_* commands and the search tool. However, it does not explicitly state when to prefer this over siblings 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.

• kali_manage_workspaceA
  3.9/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden and does disclose destructive behavior: write is 'create/overwrite' and delete is 'remove file.' It also states that content is only required for write. It doesn't mention error cases or path restrictions, but the main safety-relevant effects are explicit.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the resource and purpose, followed by a concise parameter/action list. No filler or redundant restatement.

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

  Completeness3/5

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

  The definition covers the core operations and their effects, and an output schema exists so return values need not be described. The main gap is the conditional filename requirement and the absence of any notes about edge cases (e.g., missing file, non-workspace paths), so it is only minimally complete.

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

  Parameters3/5

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

  With 0% schema description coverage, the Args block compensates by explaining each parameter and the valid action values. However, it fails to state that filename is effectively required for read/write/delete, even though schema marks only action as required and defaults filename/content to empty.

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

  Purpose5/5

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

  Clearly identifies the resource (local Kali workspace folder), a specific verb (manages), and enumerates four concrete operations (list/read/write/delete). This distinguishes it from sibling tools that execute commands or search tool help.

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

  Usage Guidelines3/5

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

  The description implies use whenever workspace file operations are needed and clearly is not for running Kali commands, but it does not explicitly state when to prefer this tool over alternatives or call out exclusions. Usage context is inferable but not stated.

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

• kali_search_toolsA
  3.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the behavioral disclosure burden. It communicates that this is a lookup operation over installed tools and enumerates valid categories, but it does not specify matching behavior, case sensitivity, result format, or whether query and category can be combined.

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

  Conciseness4/5

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

  The description is compact and front-loaded, and the category list earns its place as an enumerated set of valid inputs. The one-category-per-line formatting makes it slightly longer than necessary, but there is no filler.

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

  Completeness4/5

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

  For a simple search tool with two optional parameters and no annotations, the description covers core semantics and accepted category values. Since an output schema exists, omitting return-value details is acceptable; a brief usage example or combination rule would have made it fully complete.

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

  Parameters4/5

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

  The schema provides 0% description coverage, so the description must compensate. It gives practical meaning to the query parameter as a name/keyword search and provides an explicit list of accepted category values, which is enough for correct invocation.

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

  Purpose5/5

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

  Description uses a specific verb 'Searches' with a clear resource 'installed Kali Linux tools' and identifies three search dimensions: name, keyword, or category. This clearly separates it from sibling tools that execute commands or run specific tools.

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

  Usage Guidelines3/5

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

  Usage context is implied: use this tool to locate an installed Kali tool by name, keyword, or category. However, it does not explicitly state when to prefer this over execution-focused sibling tools or give any exclusion conditions.

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

• kali_run_sqlmapA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose that the default invocation is '--batch --banner' and 'non-interactive banner scan', which is useful. However, it does not mention the potential impact of custom 'options' flags, output behavior, or any caution about running a security tool that could perform intrusive database operations.

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

  Conciseness5/5

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

  The description is concise and well-structured: one purpose sentence followed by a compact Args block. It front-loads the tool's purpose, uses an example to remove ambiguity, and contains no filler. Every sentence earns its place.

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

  Completeness4/5

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

  For a two-parameter wrapper with an output schema, the description covers the core invocation surface: tool purpose, target URL format, optional flags, and default non-interactive mode. It is slightly incomplete in not providing usage boundaries or risk context for a security tool, but nothing essential to making a correct call is missing.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description must compensate, and it does. It explains target_url with a concrete example URL, and options as 'Sqlmap flags' with a clear default and mode. Both parameters are meaningfully documented beyond their bare schema names and types.

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

  Purpose5/5

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

  The description states a specific verb ('Runs'), a specific tool ('Sqlmap'), and its domain ('SQL injection and database takeover'), which clearly distinguishes it from siblings like kali_run_nmap and kali_run_gobuster. The example target URL further clarifies what the tool operates on. This is specific, non-tautological, and easy for an agent to match to the right task.

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

  Usage Guidelines3/5

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

  The description implies the tool is for SQL injection testing through phrases like 'SQL injection and database takeover' and the vulnerable-URL example, but it never explicitly states when to choose this tool over alternatives or when not to use it. No sibling tools or exclusion conditions are mentioned, so usage guidance is only 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.