Server Quality Checklist

Tool Scores

• launch_subagentA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and openWorldHint=true, so the description adds 'detached tmux window' as extra behavioral context. However, it does not disclose important traits like the default dangerous=true (skip permission prompts) or that it generates and runs a wrapper script. It provides some value but lacks deeper behavioral nuance.

  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, front-loaded sentence with no wasted words. It efficiently communicates the core action and environment context, earning a top score for conciseness.

  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?

  Given the tool's complexity (14 parameters) and the presence of a full input schema and output schema, the one-line description provides a sufficient high-level understanding. It could be slightly more complete by noting the background execution or permission implications, but overall it is adequate for a schema-rich tool.

  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 the baseline is 3 even though the description itself does not mention any parameters. The description adds no additional meaning beyond what the parameter descriptions already provide.

  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 uses a specific verb ('Launch') and resource ('coding-CLI subagent') with a distinguishing detail ('detached tmux window'). It clearly differentiates from sibling tools (check, list, send, stop) by indicating creation/startup rather than inspection or messaging.

  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 explicit guidance on when to use this tool versus alternatives. While the name and first word imply starting a new subagent, there is no mention of use cases, prerequisites, or exclusions, and it does not reference the sibling tools.

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

• send_to_subagentA
  3.6/5.0
  Behavior3/5

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

  The annotation destructiveHint=true already signals potential destructive outcomes, and the description does not contradict it. The description adds minimal behavioral context beyond the annotation, not detailing what happens when the message is sent or whether it interrupts the subagent.

  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 concise sentence that fully conveys the tool's core purpose without unnecessary filler. It is appropriately front-loaded and easy to parse.

  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?

  Given the tool's simplicity, the rich schema, and the presence of an output schema, the description is mostly complete. It could include a bit more about side effects or expected outcomes, but for a low-complexity tool, this is sufficient.

  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 fully documented in the schema. The description itself adds no parameter details, but since the schema covers all three parameters, the baseline score is appropriate.

  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 a follow-up message') and target ('running subagent'), using a specific verb and resource. It differentiates from siblings like launch_subagent and stop_subagent, though it could more explicitly name alternatives.

  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 'to a running subagent' implies this tool is used after launch and before stopping, providing clear context. However, it does not explicitly state when not to use it or mention any alternatives, so guidance is implied rather than direct.

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

• list_subagentsA
  3.8/5.0
  Behavior4/5

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

  The readOnlyHint annotation already indicates safety, and the description adds useful context by mentioning reconciliation with live tmux pane state. This goes beyond the annotation, though it doesn't detail what reconciliation entails.

  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, well-structured sentence that conveys the core function and key behavioral nuance without redundancy.

  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?

  With a simple parameter set, a read-only annotation, and an output schema, the description sufficiently captures the tool's intent. The term 'reconcile' is slightly ambiguous but doesn't critical hinder understanding for a list operation.

  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 provides 100% coverage for the single 'session' parameter, so the description doesn't need to elaborate. It adds no additional parameter semantics beyond the schema, justifying the baseline score.

  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 lists subagents and adds the distinctive 'reconcile them with live tmux pane state' behavior, making its purpose specific and differentiated from sibling tools like check_subagent or launch_subagent.

  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 explicit guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions or alternatives, leaving the user to infer usage context.

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

• stop_subagentA
  3.8/5.0
  Behavior3/5

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

  The description clarifies the two modes of operation (interrupt vs. kill-window), which adds context beyond the destructiveHint annotation. However, it does not disclose potential side effects such as cleanup of child processes or consequences of killing the tmux window. The annotation already flags destructiveness, so the description offers modest additional value.

  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 sentence, front-loaded with the action verb and resource, and contains no redundant or extraneous words. It is an exemplar of concise and efficient communication.

  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?

  Given the tool's simplicity, the comprehensive schema, and the destructiveHint annotation, the description covers the essential purpose and safety profile. Because an output schema exists, return values are not required. A brief note about handle formats or typical use cases might add slight value, but overall it is sufficiently 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?

  The input schema fully documents both parameters (handle and kill_window) with descriptions and a default value, covering 100% of the parameter semantics. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.

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

  Purpose5/5

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

  The description uses the specific verb 'Interrupt or kill' and clearly identifies the resource 'a running subagent'. This unambiguously distinguishes it from sibling tools like launch_subagent, check_subagent, and list_subagents. The purpose is immediately understandable.

  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 usage for stopping running subagents but does not provide explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or the recommended workflow, though the schema indicates the handle is required. The context is clear but alternatives are not addressed.

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

• check_subagentA
  4.2/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, so the safety profile is known. The description adds the constraint that only running subagents are supported and specifies 'last output,' which is useful context. There is a minor ambiguity with the schema's 'pane top' phrasing, but overall the description provides valuable behavioral context.

  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 concise sentence of nine words, communicating the essential function without any fluff or redundancy. Every word contributes to understanding.

  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?

  An output schema exists, so return values are covered. The description explains the core purpose and the 'running subagent' constraint. It does not address error conditions like non-running subagents, but for a simple read-only tool, this is adequately 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?

  The schema has 100% coverage for both parameters with clear descriptions, so the description does not need to add parameter details. It adds no extra semantics beyond what the schema provides, which aligns with the baseline for well-documented schemas.

  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 uses a specific verb 'capture' and resource 'last output from a running subagent', clearly distinguishing it from siblings like list_subagents, send_to_subagent, and stop_subagent. There is no ambiguity about what the tool does.

  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 context is clear: use this tool to retrieve recent output from an active subagent. It does not explicitly mention alternatives or when-not-to-use, but the purpose alone makes the appropriate use case evident.

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