Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_quality_reviewer_launch

Launches an independent anti-anchored quality reviewer for a worker request's candidate, using a single correctness, security, or code-quality lens to catch anchoring bias before approval.

Instructions

DUAL-GATED: launch one independent anti-anchored quality reviewer.

timeout_seconds is retained only as non-enforcing compatibility metadata; this API never installs a reviewer wall-clock deadline.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "target_request_id": "<target_request_id>",
      "target_task_id": "<target_task_id>",
      "reviewer_task_id": "<reviewer_task_id>",
      "runner": "<runner>",
      "adapter_id": "<adapter_id>",
      "lens": "<lens>"
    },
    "name": "aiworkhub_quality_reviewer_launch"
  }
}

Input Schema

NameRequiredDescriptionDefault
lensYesReview lens: correctness, security or code_quality; only one live reviewer per target request and lens is allowed.
modelNoOptional model override for the reviewer; omit to use the adapter default.
runnerYesRunner name that executes the reviewer.
adapter_idYesAdapter that launches the reviewer process, e.g. claude_cli.
target_task_idYesId of the task card that target request belongs to.
timeout_secondsNoCompatibility metadata only, default 1800; no wall-clock deadline is enforced and the value is echoed in the reply.
reviewer_task_idYesId of the reviewer task card that carries this review.
target_request_idYesId of the worker request whose candidate is reviewed.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.12.67
    • addedInput schema / properties / adapter_id / description
      Added value: +"Adapter that launches the reviewer process, e.g. claude_cli."
    • addedInput schema / properties / lens / description
      Added value: +"Review lens: correctness, security or code_quality; only one live reviewer per target request and lens is allowed."
    • addedInput schema / properties / model / description
      Added value: +"Optional model override for the reviewer; omit to use the adapter default."
    • addedInput schema / properties / reviewer_task_id / description
      Added value: +"Id of the reviewer task card that carries this review."
    • addedInput schema / properties / runner / description
      Added value: +"Runner name that executes the reviewer."
    • addedInput schema / properties / target_request_id / description
      Added value: +"Id of the worker request whose candidate is reviewed."
    • addedInput schema / properties / target_task_id / description
      Added value: +"Id of the task card that target request belongs to."
    • addedInput schema / properties / timeout_seconds / description
      Added value: +"Compatibility metadata only, default 1800; no wall-clock deadline is enforced and the value is echoed in the reply."
  2. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the agent knows this is a non-destructive but mutating launch. The description adds one genuinely useful behavioral note — timeout_seconds is never enforced — though that exact fact is already spelled out in the schema description. It omits other behavioral traits an 8-param launcher would warrant: idempotency on duplicate launch, what resource cost / process lifecycle results, and what happens if a live reviewer already exists.

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?

Two short sentences, with the core action front-loaded before the timeout caveat. It is not padded, but the leading "DUAL-GATED" token is dense jargon that costs the reader more than it conveys, and the second sentence largely duplicates 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 tool has an output schema and full annotation coverage, so return values and safety are handled elsewhere, and those do not need description space. But for an 8-parameter, 6-required launch mutation with no stated preconditions, idempotency, or sibling routing, the description is thinner than the tool's complexity warrants.

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 schema already documents every parameter including the lens enum and the timeout_seconds compatibility caveat. The description adds no meaning beyond the schema — it only reiterates the timeout non-enforcement already present. Baseline 3 applies when structured fields carry the load.

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 verb+resource is concrete: "launch one independent anti-anchored quality reviewer." That is more specific than a tautology and tells an agent it is spawning a reviewer process rather than inspecting or scoring something. However, the qualifiers "DUAL-GATED" and "anti-anchored" are unexplained jargon, and it never names the sibling review/quality tools it is meant to supersede, so differentiation is only partial.

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 never states when to use this tool, when not to, or what alternative to pick (e.g. vs. aiworkhub_quality_run_checks or aiworkhub_agent_accept_review). The only implicit constraint is "one reviewer" and the schema's note that only one live reviewer per target request and lens is allowed, which lives in the schema, not the description. An agent must infer the usage context.

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

Deploy Server

Other Tools