Skip to main content
Glama

aiworkhub_review_packet

Read-only

Returns one bounded, read-only packet of persisted review evidence—validation, gate checks, findings, reachability—so a manager can decide a review_ready candidate without extra calls.

Instructions

READ-ONLY: ONE bounded review packet for a review_ready candidate.

Every fact a manager needs to decide a candidate is already persisted -- validation rows with their declared commands and output tails, the quality gate's checks and blockers, the worker MCP gate and its receipt-conformance verdict, required outputs, destructive-diff checks, the effective tier and its per-lens status, the deduped reviewer findings, the reachability observation -- spread across six nested objects on one card. This returns them together, under a measured byte bound.

Measured over all 419 real cards carrying a quality gate: min 1,662 B, p50 6,387 B, p90 8,813 B, max 13,799 B, 0 needing truncation. It replaces per candidate 10 task-scoped calls at p50 (p90 21) and, session-wide, 1,688 hand-written Bash re-derivations (pytest 611, attempt-artifact reads 242, task_queue.sqlite scripts 250, log tails 113, git diff 155) totalling 1.45 MB.

Nothing here is a verdict: every status was decided by the gate that recorded it, and accepting still runs the whole fold in aiworkhub_agent_accept_review. The one live computation is aiworkhub_agent_accept_preview -- itself read-only -- which aiworkhub_completion_inbox cannot call because it holds no launch authority, so it is computed here and passed in.

The decision section prefills the argument dicts for aiworkhub_agent_accept_review, one aiworkhub_manager_review_finding_dispose per undisposed finding, and aiworkhub_task_reject_review; it never picks a disposition or a verdict and is never dropped before an evidence section.

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_review_packet"
  }
}

Input Schema

NameRequiredDescriptionDefault
task_idNoId of the task card that request belongs to; omit to resolve it from the request's status (the reply's task_id_source says which). Not accepted with request_ids.
max_bytesNoByte bound for the packet, default 90000; lowest-priority sections are dropped until it fits and listed under truncation.dropped_sections. With request_ids it is split evenly across the packets.
request_idNoId of the review_ready worker request to build the packet for; leave empty when request_ids is given, or pass task_id alone to use that card's current review request (the reply's request_id_source says which).
request_idsNoUp to 8 review_ready request ids to read in one call instead of request_id; returns {packets, per_packet_max_bytes}, each packet built exactly like a single call with the split budget, and a member that fails carries its own error without failing the batch.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.87
    • changedInput schema / properties / request_id / description
      Previous value: -"Id of the review_ready worker request to build the packet for; leave empty when request_ids is given."New value: +"Id of the review_ready worker request to build the packet for; leave empty when request_ids is given, or pass task_id alone to use that card's current review request (the reply's request_id_source says which)."
  2. Changed6 schema fields changedv0.12.85
    • changedInput schema / properties / max_bytes / description
      Previous value: -"Byte bound for the packet, default 90000; lowest-priority sections are dropped until it fits and listed under truncation.dropped_sections."New value: +"Byte bound for the packet, default 90000; lowest-priority sections are dropped until it fits and listed under truncation.dropped_sections. With request_ids it is split evenly across the packets."
    • addedInput schema / properties / request_id / default
      Added value: +""
    • changedInput schema / properties / request_id / description
      Previous value: -"Id of the review_ready worker request to build the packet for."New value: +"Id of the review_ready worker request to build the packet for; leave empty when request_ids is given."
    • addedInput schema / properties / request_ids
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Up to 8 review_ready request ids to read in one call instead of request_id; returns {packets, per_packet_max_bytes}, each packet built exactly like a single call with the split budget, and a member that fails carries its own error without failing the batch.",
      +  "title": "Request Ids"
      +}
    • changedInput schema / properties / task_id / description
      Previous value: -"Id of the task card that request belongs to; omit to resolve it from the request's status (the reply's task_id_source says which)."New value: +"Id of the task card that request belongs to; omit to resolve it from the request's status (the reply's task_id_source says which). Not accepted with request_ids."
    • removedInput schema / required
      Removed value: -[
      -  "request_id"
      -]
  3. Changed3 schema fields changedv0.12.67
    • addedInput schema / properties / max_bytes / description
      Added value: +"Byte bound for the packet, default 90000; lowest-priority sections are dropped until it fits and listed under truncation.dropped_sections."
    • addedInput schema / properties / request_id / description
      Added value: +"Id of the review_ready worker request to build the packet for."
    • addedInput schema / properties / task_id / description
      Added value: +"Id of the task card that request belongs to; omit to resolve it from the request's status (the reply's task_id_source says which)."
  4. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is free; the description adds non-obvious behavior on top: a measured byte bound with the worst real card at 13,799 B, a drop policy that lists truncated sections, and the guarantee that 'decision' is never dropped before an evidence section. It also warns that nothing here is a verdict and that accept_preview is computed here rather than by the inbox. That is substantive disclosure beyond annotations, though rate limits and failure modes are left to the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is well front-loaded and the verdict/fold caveat is useful. However the middle paragraph is largely self-justifying telemetry -- p50/p90/max byte figures plus a breakdown of 1,688 hand-written Bash re-derivations (pytest 611, log tails 113, git diff 155) -- which an agent invoking the tool does not need and which dilutes the operational content.

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 an output schema present, the description needn't explain return values, and it does not have to; instead it explains the truncation budget, the per-member error isolation in batch mode, and that the decision block never picks a verdict. For a read-only aggregation tool with full annotation and schema coverage, little an agent needs 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 description coverage is 100%, so the four parameters are already fully documented, including the task_id/request_id resolution rules, the 90,000-byte default and the up-to-8 batch split. The description repeats the batching idea in prose ('one ... per undisposed finding' / batch context) but adds no syntax, precedence or format detail the schema lacks. Baseline 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 opening line states a specific verb, resource and scope ('ONE bounded review packet for a review_ready candidate') and then enumerates the six nested sections the packet joins. It actively distinguishes itself from siblings: accept_review 'runs the whole fold' while this is read-only, and completion_inbox 'cannot call' accept_preview, which explains why the packet computes it. An agent can place this tool without opening its schema.

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?

It positions itself clearly in the workflow: gather evidence here, then accepting 'still runs the whole fold in aiworkhub_agent_accept_review', and the decision block prefills arguments for accept_review, review_finding_dispose and task_reject_review. It also claims to replace '10 task-scoped calls at p50', which is a strong reason to prefer it over ad-hoc reads. It stops short of explicit when-not-to-use cases or naming which sibling to use for narrower questions (e.g. task_show, task_review_summarize).

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