Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_agent_accept_preview

Read-only

Checks a worker request for cheap acceptance blockers—such as pending lens runs, missing review_ready status, or absent approval—before any work is done. Read-only; writes nothing.

Instructions

READ-ONLY: what would block aiworkhub_agent_accept_review right now, before any work.

Use this for the cheap accept blockers of one candidate; use aiworkhub_review_packet for that candidate's full review evidence.

Measured 2026-09-08: 49 of 159 accept attempts (31%) failed on a blocker that was knowable in advance -- a required lens still running, a target not yet review_ready, an approval not given -- but only after the combined tree had been materialized and two validation runs paid for. This folds exactly those cheap blockers and writes nothing.

A clear preview is NOT an acceptance and NOT a promise of one. The expensive half -- combined tree, declared validations, mechanical gate, reviewer receipt verification by request id -- runs only in aiworkhub_agent_accept_review and can still refuse. blocked False means only that nothing cheap is refusing yet. Leave requested_risk_tier unset to read the tier the finalizer measured; an explicit value can only raise it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aiworkhub_agent_accept_preview"
  }
}

Input Schema

NameRequiredDescriptionDefault
task_idNoId of the task card that request belongs to; required.
request_idNoId of the worker request to accept; it must be in review_ready state. Omit to resolve the card's current review request from task_id (the reply's request_id_source says which).
confirm_high_riskNoSet true to give the explicit human approval that high or critical risk tiers require; default false.
requested_risk_tierNoRisk tier to review at; omit to use the tier the finalizer measured for this candidate. An explicit value can only raise the tier, never lower it.
reviewer_request_idsNoReviewer request ids to verify; omit to use every verified reviewer bound to this request and task, and pass [] to exclude all reviewers.
confirm_destructive_changeNoSet true to accept a candidate whose diff failed a destructive-change check; otherwise accept is refused with destructive_diff_requires_manager_confirmation. Default false.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.12.87
    • addedInput schema / properties / request_id / default
      Added value: +""
    • changedInput schema / properties / request_id / description
      Previous value: -"Id of the worker request to accept; it must be in review_ready state."New value: +"Id of the worker request to accept; it must be in review_ready state. Omit to resolve the card's current review request from task_id (the reply's request_id_source says which)."
    • addedInput schema / properties / task_id / default
      Added value: +""
    • changedInput schema / properties / task_id / description
      Previous value: -"Id of the task card that request belongs to."New value: +"Id of the task card that request belongs to; required."
    • removedInput schema / required
      Removed value: -[
-  "request_id",
-  "task_id"
-]
  2. Changed6 schema fields changedv0.12.67
    • addedInput schema / properties / confirm_destructive_change / description
      Added value: +"Set true to accept a candidate whose diff failed a destructive-change check; otherwise accept is refused with destructive_diff_requires_manager_confirmation. Default false."
    • addedInput schema / properties / confirm_high_risk / description
      Added value: +"Set true to give the explicit human approval that high or critical risk tiers require; default false."
    • addedInput schema / properties / request_id / description
      Added value: +"Id of the worker request to accept; it must be in review_ready state."
    • addedInput schema / properties / requested_risk_tier / description
      Added value: +"Risk tier to review at; omit to use the tier the finalizer measured for this candidate. An explicit value can only raise the tier, never lower it."
    • addedInput schema / properties / reviewer_request_ids / description
      Added value: +"Reviewer request ids to verify; omit to use every verified reviewer bound to this request and task, and pass [] to exclude all reviewers."
    • addedInput schema / properties / task_id / description
      Added value: +"Id of the task card that request belongs to."
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses that the tool writes nothing, enumerates the class of cheap blockers it checks, quantifies the failure rate it addresses, and explains that the expensive half (combined tree, validations, gate, receipt verification) runs only in the accept tool. It further warns that blocked=false means only that nothing cheap is refusing yet — a crucial interpretive caveat not present in annotations.

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 lead sentence is front-loaded with the operative distinction, and the structure moves logically from purpose to alternative to caveat. The 'Measured 2026-09-08: 49 of 159...' statistic is longer than strictly needed, but it earns its place by justifying why the preview exists.

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?

With an output schema present, the description correctly avoids detailing return shape while still explaining the semantics of a false blocked value. For a six-parameter, read-only preflight on a destructive-gated workflow, nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so every parameter is already documented, and the requested_risk_tier guidance ('leave unset to read the tier the finalizer measured; an explicit value can only raise it') largely restates the schema text. The description adds conceptual context about which parameters relate to cheap blockers but does not meaningfully extend individual parameter meaning 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 first line gives a specific verb and resource — a read-only preview of what would block aiworkhub_agent_accept_review — and immediately scopes it to 'before any work.' It is unmistakably distinct from aiworkhub_agent_accept_review (the real accept) and aiworkhub_review_packet (full evidence), both of which are named.

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?

It states exactly when to use this tool ('the cheap accept blockers of one candidate') and names the alternative for the other case (aiworkhub_review_packet for full review evidence). It also sets a clear boundary on what a clear result means — not an acceptance and not a promise of one.

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