Server Quality Checklist

Tool Scores

• send_input_to_commandC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but lacks critical behavioral details. It doesn't disclose whether this is a read/write operation, potential side effects (e.g., command execution), error conditions, or response format. The mention of 'running interactive command' implies state dependency but doesn't elaborate on session management or failure modes.

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

  Conciseness3/5

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

  The description is brief but includes a parenthetical note that adds complexity without clear value. It's front-loaded with the core action but could be more streamlined by removing the ambiguous parenthetical, which doesn't earn its place in a concise tool description.

  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?

  Given no annotations, no output schema, and interaction with running commands (implying statefulness), the description is incomplete. It doesn't cover return values, error handling, or how it integrates with sibling tools for command lifecycle management, leaving significant gaps for an AI agent to use it effectively in context.

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

  Parameters3/5

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

  Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional parameter semantics beyond implying 'input' is sent to a command and 'session_id' identifies an interactive session. This meets the baseline for high schema coverage but doesn't enhance understanding of parameter usage or constraints.

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

  Purpose4/5

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

  The description clearly states the action ('send user input') and target ('to a running interactive command'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'execute_command' or 'get_command_output', and the parenthetical '(自行判断是AI输入还是用户手动输入)' adds some ambiguity about the source determination.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'execute_command' for non-interactive commands or 'close_interactive_command' to end sessions. It mentions 'running interactive command' but doesn't specify prerequisites or contrast with sibling tools, leaving usage context unclear.

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

• close_interactive_commandC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('close') but doesn't explain what happens upon closing (e.g., whether resources are freed, if the session is terminated permanently, or any side effects). This is a significant gap for a mutation tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence in Chinese ('关闭交互式命令会话。') that directly states the purpose without unnecessary words. It's front-loaded and appropriately sized for the tool's complexity.

  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?

  Given the tool's complexity (a mutation operation to close sessions), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like effects of closing, error conditions, or return values, making it inadequate for safe and effective use.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the parameter 'session_id' documented as '交互式会话ID' (interactive session ID). The description doesn't add any meaning beyond this, such as format examples or sourcing details. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description '关闭交互式命令会话' (close interactive command session) clearly states the verb ('close') and resource ('interactive command session'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'execute_command' or 'start_interactive_command' beyond the 'close' action, missing specific sibling comparison.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active session from 'start_interactive_command'), exclusions, or context for choosing it over other command-related tools, leaving usage unclear.

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

• get_command_outputC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks critical behavioral details: it doesn't specify if this is a read-only operation (implied but not explicit), whether it returns only the latest output or a history, error conditions (e.g., invalid session), or performance characteristics like rate limits.

  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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the complexity (interactive command output retrieval) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., text, structured data), error handling, or dependencies on other tools like 'start_interactive_command'. For a tool with no structured behavioral hints, more context is needed.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the single parameter 'session_id' documented as '交互式会话ID' (interactive session ID). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('获取' meaning 'get') and the resource ('交互式命令的最新输出' meaning 'latest output of interactive command'), making the purpose immediately understandable. It distinguishes from siblings like 'execute_command' (which runs commands) and 'send_input_to_command' (which sends input), but doesn't explicitly contrast with 'close_interactive_command' or 'start_interactive_command'.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing an active session), when not to use it, or how it relates to sibling tools like 'execute_command' for non-interactive output or 'send_input_to_command' for providing input.

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

• execute_commandB
  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 behavioral disclosure. It mentions the environment (Kali Linux penetration testing) and command types, but lacks critical behavioral details: it doesn't specify execution context (e.g., shell, permissions, isolation), output handling, error behavior, security implications, or rate limits. For a command execution tool with zero annotation coverage, this is a significant gap.

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

  Conciseness4/5

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

  The description is concise and front-loaded, with two sentences that directly address the tool's function and scope. The first sentence states the core purpose with a clarifying exclusion, and the second sentence expands on supported commands. There's minimal wasted text, though it could be slightly more structured.

  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?

  Given the complexity of a command execution tool in a security context, with no annotations and no output schema, the description is incomplete. It lacks details on execution behavior, output format, error handling, and security warnings, which are crucial for safe and effective use. The description doesn't compensate for the absence of structured data.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the 'command' parameter well-documented in the schema itself. The description adds marginal value by reinforcing the command types (security testing, vulnerability scanning, password cracking) and the Kali Linux context, but doesn't provide additional syntax, format, or constraint details beyond what the schema already states.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: '在Kali Linux渗透测试环境中执行命令' (execute commands in a Kali Linux penetration testing environment). It specifies the verb (execute) and resource (commands) with context (Kali Linux, penetration testing). However, it doesn't explicitly differentiate from sibling tools like 'start_interactive_command' or 'get_command_output', which appear related to command execution workflows.

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

  Usage Guidelines3/5

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

  The description provides some implied usage context by mentioning '(无需交互式比如ping 127.0.1)' (no interactive commands like ping 127.0.0.1) and listing supported command types (security testing, vulnerability scanning, password cracking). However, it doesn't explicitly state when to use this tool versus alternatives like 'start_interactive_command' or provide clear exclusions beyond the interactive example.

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

• start_interactive_commandB
  3.3/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 discloses that the tool returns a session ID and that interactive commands can receive user input. However, it lacks critical behavioral details: whether this requires specific permissions in Kali Linux, what happens if the command fails to start, rate limits, or how the session ID is used with other tools. For a tool that starts interactive commands (potentially with security implications), this is inadequate.

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

  Conciseness4/5

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

  The description is appropriately sized and front-loaded: the first sentence states the core purpose, and the second adds useful context about interactivity and sibling tools. There's no wasted text, though it could be slightly more structured (e.g., separating usage notes).

  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?

  Given the complexity (starting interactive commands in Kali Linux), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the returned session ID looks like, how to use it with other tools, error conditions, or security considerations. For a tool with potential destructive capabilities and no structured safety hints, more guidance is needed.

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

  Parameters3/5

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

  The schema description coverage is 100% (one parameter 'command' with description '要在Kali Linux环境中执行的交互式命令'), so the baseline is 3. The description adds minimal value beyond the schema: it emphasizes that the command should be interactive (e.g., 'mysql -u root -p') and mentions the Kali Linux environment, but doesn't provide additional syntax, format, or validation details for the command parameter.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: '在Kali Linux环境中启动一个交互式命令，并返回会话ID' (start an interactive command in Kali Linux environment and return a session ID). It specifies the verb ('启动' - start), resource ('交互式命令' - interactive command), and environment ('Kali Linux环境中'). However, it doesn't explicitly distinguish from sibling tools like 'execute_command' which might also execute commands but not return session IDs for interactive sessions.

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

  Usage Guidelines4/5

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

  The description provides clear context for when to use this tool: for interactive commands that require user input (e.g., 'mysql -u root -p'). It mentions the relationship with sibling tools: '可以在不close_interactive_command的情况下同时执行execute_command' (can execute execute_command without closing interactive_command). However, it doesn't explicitly state when NOT to use it or provide alternatives for non-interactive commands.

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