Server Quality Checklist

Tool Scores

• worker_cancelA
  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 full burden. It discloses the destructive action of terminating the worker process tree and indicates the return value (terminal state). This provides meaningful behavioral context beyond a simple 'cancel' command.

  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 succinct with two sentences, front-loading the core action and return value. Every word contributes information, with no redundancy or fluff.

  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 (one param, no output schema), the description covers the essential purpose and behavior. It could mention error conditions or prerequisites, but it is sufficiently complete for a cancel operation.

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

  Parameters2/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, but it only implicitly references the task_id parameter without describing its format or adding meaning. The parameter 'task_id' is left without any elaboration in the description.

  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's purpose: cancel a running or queued delegated task and terminate its worker process tree, and it returns the task's terminal state. The verb 'cancel' is specific and directly distinguishes this from sibling tools like worker_delegate and worker_status.

  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 tasks that are running or queued, but does not provide explicit guidance on when not to use this tool or mention alternatives. It lacks clear context for selecting this tool over siblings beyond the name.

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

• worker_logsA
  4.2/5.0
  Behavior3/5

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

  No annotations provided, so description carries full burden. Discloses paging behavior and event types, but does not mention any potential side effects, authorization needs, or output format details beyond being a 'normalized event log'. Adequate but not comprehensive.

  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?

  Two sentences, no fluff. Purpose is front-loaded in the first sentence, and paging guidance is in the second. Every word 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?

  Given 2 parameters and no output schema or annotations, description covers the main return type (normalized event log) and paging mechanism. Does not detail event structure or how to interpret the log, but sufficient for an agent to understand basic usage.

  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 has 0% description coverage, so description adds significant meaning: 'after' is explained as an event_id for paging. 'task_id' is implied by context but not explicitly described. Provides enough semantic value for agent to understand parameter roles.

  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 clearly states it returns the normalized event log for a delegated task, listing specific event types (worker.started, progress, etc.) and mentions streaming-style progress, which distinguishes it from siblings like worker_status or worker_cancel.

  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?

  Explicitly explains how to page through results using the 'after' parameter with an event_id, providing clear usage context. Lacks explicit when-not-to-use or alternative suggestions, but appropriate for this tool.

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

• list_workersA
  4.4/5.0
  Behavior4/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 states that workers listed are 'installed and healthy' and includes capabilities, which gives insight into the tool's behavior. It does not mention side effects or performance characteristics, but for a read-only list tool, this is adequate.

  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 with two sentences, no wasted words. It front-loads the main action and adds a usage hint in the second sentence.

  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 no output schema, the description explains that the tool returns workers 'with their capabilities', but does not detail the structure of the output. For a simple list tool, this is mostly adequate, but a more complete description could specify the output format.

  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 zero parameters. According to guidelines, 0 parameters yields a baseline score of 4. The description does not need to add parameter semantics beyond the schema.

  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 available coding workers with their capabilities, using a specific verb 'list' and resource 'coding workers'. It distinguishes itself from sibling tools like worker_delegate by specifying it is meant for checking which workers are available.

  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 explicitly tells when to use this tool: 'Call this to see which worker values worker_delegate can use before delegating.' This provides clear context and implies a workflow. However, it does not mention when not to use it or any alternatives beyond the implied sibling.

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

• worker_statusA
  4.4/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It describes return fields (status, summary, changed files, verification result, artifact paths) and behavior difference with/without task_id. It implies read-only nature for polling, which is adequate.

  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?

  Two concise sentences with front-loaded purpose. No superfluous words. Each sentence adds value.

  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 simplicity (1 optional param, no output schema, no annotations), description covers key behaviors, use case, and mentions sibling (worker_delegate). Could add that it's read-only, but otherwise 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?

  Schema has no description for task_id (0% coverage). Description adds meaning: with task_id returns detailed info, without lists recent tasks. This compensates for schema gap, though lacks format/constraints.

  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 checks delegated worker tasks, with specific behaviors for with/without task_id. It distinguishes from siblings like worker_delegate (starts tasks) and worker_logs (gets logs).

  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?

  Explicitly says 'Use to poll a task started by worker_delegate.' This provides clear context for usage. Could mention when not to use (e.g., for logs use worker_logs), but the guidance is sufficient.

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

• worker_delegateA
  4.8/5.0
  Behavior4/5

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

  No annotations provided, so description carries full burden. It discloses background execution, independent verification, and optionally blocking. However, it lacks details on failure modes or timeouts, but is sufficient for a delegation 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?

  Well-structured with a clear first sentence, usage guidelines, and parameter list. Every sentence serves a purpose. No fluff.

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

  Completeness5/5

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

  Given 7 parameters, no output schema, and no annotations, the description covers all necessary aspects: purpose, when to use, parameter details, and background behavior. It feels complete for the tool's complexity.

  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 coverage is 0%, but the Args section explains all 7 parameters (objective, repository, worker, permission, verify, base_ref, wait) with clear descriptions, adding substantial value beyond the schema.

  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 action: 'Delegate a scoped coding task to an external AI coding worker in an isolated git worktree, then independently verify the result.' This distinguishes it from sibling tools like list_workers, worker_cancel, worker_logs, and worker_status, which are for management/status.

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

  Usage Guidelines5/5

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

  Explicitly when to use: 'USE for: implementing a feature, fixing a bug across files, a refactor or migration.' And when not: 'DO NOT USE for a trivial one-line edit, or non-coding work.' Also mentions polling with worker_status for background tasks.

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