Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_manager_review_hold_resolve

Resolve a durable reviewer-route hold by exposing a recorded callback, authorizing one bounded distinct-route successor, or re-arming the exact reviewer attempt after its blocker is repaired.

Instructions

MANAGER WRITE: resolve one exact durable reviewer-route hold.

Every chain, candidate and retired-attempt identity is mandatory. The action can only expose an already-recorded callback, authorize the one bounded distinct-route successor, or re-arm the exact pre-provider reviewer attempt after its operational blocker was repaired. It never accepts the target and never relaunches its implementation worker.

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_task_id": "<target_task_id>",
      "target_request_id": "<target_request_id>",
      "claim_epoch": "<claim_epoch>",
      "candidate_sha256": "<candidate_sha256>",
      "lens": "<lens>",
      "attempt_index": "<attempt_index>",
      "reviewer_task_id": "<reviewer_task_id>",
      "reviewer_request_id": "<reviewer_request_id>",
      "decision": "<decision>"
    },
    "name": "aiworkhub_manager_review_hold_resolve"
  }
}

Input Schema

NameRequiredDescriptionDefault
lensYesReview lens of the held chain: correctness, security or code_quality.
decisionYesauthorize_distinct_route_successor allows the one bounded successor on a distinct route; callback_reconcile exposes the already-recorded callback; retry_existing_attempt re-arms the exact pre-provider attempt once its operational blocker is repaired.
claim_epochYesClaim epoch identifying the held reviewer chain; it must match the recorded chain exactly.
attempt_indexYesIndex of the retired reviewer attempt being resolved; it must match the recorded attempt.
target_task_idYesId of the implementation task under review whose reviewer route is held.
candidate_sha256YesSHA-256 of the sealed candidate that reviewer chain examined; it must match the recorded value.
reviewer_task_idYesId of the reviewer task card of that retired attempt.
target_request_idYesId of the implementation worker request under review.
reviewer_request_idYesId of the reviewer request of that retired attempt.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.12.67
    • addedInput schema / properties / attempt_index / description
      Added value: +"Index of the retired reviewer attempt being resolved; it must match the recorded attempt."
    • addedInput schema / properties / candidate_sha256 / description
      Added value: +"SHA-256 of the sealed candidate that reviewer chain examined; it must match the recorded value."
    • addedInput schema / properties / claim_epoch / description
      Added value: +"Claim epoch identifying the held reviewer chain; it must match the recorded chain exactly."
    • addedInput schema / properties / decision / description
      Added value: +"authorize_distinct_route_successor allows the one bounded successor on a distinct route; callback_reconcile exposes the already-recorded callback; retry_existing_attempt re-arms the exact pre-provider attempt once its operational blocker is repaired."
    • addedInput schema / properties / lens / description
      Added value: +"Review lens of the held chain: correctness, security or code_quality."
    • addedInput schema / properties / reviewer_request_id / description
      Added value: +"Id of the reviewer request of that retired attempt."
    • addedInput schema / properties / reviewer_task_id / description
      Added value: +"Id of the reviewer task card of that retired attempt."
    • addedInput schema / properties / target_request_id / description
      Added value: +"Id of the implementation worker request under review."
    • addedInput schema / properties / target_task_id / description
      Added value: +"Id of the implementation task under review whose reviewer route is held."
  2. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare this a non-read-only, non-destructive, closed-world write, so the description's added value is the explicit safety boundary: it 'never accepts the target and never relaunches its implementation worker.' That tells the agent exactly what this mutation does not do, which is the most consequential behavior for a write tool. It leaves the success/failure effect on the held chain partially unstated but the critical guardrails are disclosed.

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 safety-critical action verb and scope are front-loaded, followed by the identity requirement and the three permitted outcomes. The jargon is dense but each sentence carries a distinct constraint; there is little 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?

With a full output schema present, return values need not be explained here. All nine required parameters are documented in the schema and the description covers permitted outcomes and hard boundaries, leaving only the precise failure/error semantics of an identity mismatch unaddressed.

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% and the two enums are fully spelled out in the schema, so the schema already carries parameter meaning. The description adds only the framing that 'every chain, candidate and retired-attempt identity is mandatory,' which mildly reinforces the exact-match requirement but adds no field-level syntax beyond the structured data.

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 definition leads with a specific verb and resource ('MANAGER WRITE: resolve one exact durable reviewer-route hold'), which distinguishes it from read-side review tools and from adjacent finding-disposal siblings. It stops short of naming the sibling an agent should fall back to when no hold exists, so differentiation is implied rather than stated.

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 three decision values are outlined, which effectively tells an agent which resolution path applies, and 'retry_existing_attempt' carries the precondition that the operational blocker was repaired. However, there is no explicit when-not-to-use or named alternative (e.g. against review_finding_dispose or task_reject_review), leaving the selection context implicit.

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