Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_task_review_summarize

Read-only

Inspect the review queue, group tasks by topic or runner, and return a Codex review checklist with validation commands.

Instructions

READ-ONLY: Inspect review queue, group tasks by topic/runner, return Codex review checklist.

Use this for a topic/runner-grouped review checklist; use aiworkhub_task_codex_handoff for per-task risks and finalize commands.

Calls the B110 review_summarizer core (read-only contract). Returns grouped tasks, validation commands, allowed_writes counts, and a Codex-ready review checklist shape.

FROZEN INPUT SCHEMA — no write-gate toggle, no mutation parameters. Never calls taskctl done/review/start/auto-pickup/add-card. Never mutates queue or audit state. Never launches agents or model processes. Writes remain default-off regardless of input values.

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

Input Schema

NameRequiredDescriptionDefault
task_idsNoOnly keep these task ids in codex_review_checklist; omit to keep every task waiting in the review queue.
batch_labelNoFree-text label echoed back as batch_label in the reply; it does not filter anything.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.12.67
    • addedInput schema / properties / batch_label / description
      Added value: +"Free-text label echoed back as batch_label in the reply; it does not filter anything."
    • addedInput schema / properties / task_ids / description
      Added value: +"Only keep these task ids in codex_review_checklist; omit to keep every task waiting in the review queue."
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with concrete specifics: it names the B110 review_summarizer core, lists the forbidden taskctl operations (done/review/start/auto-pickup/add-card), and asserts writes stay default-off regardless of input. That is more than restating the annotation, though the non-mutation guarantee is repeated across several sentences and no failure modes or queue-size limits 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 purpose and the sibling routing are front-loaded in the first two lines, so an agent gets the key decision information immediately. The trailing read-only paragraph is somewhat repetitive ('Never... Never... Never...' plus a separate 'Writes remain default-off' line) and could be compressed without losing meaning.

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 only two optional parameters, 100% schema description coverage, and an output schema covering the grouped-tasks/checklist return shape, the description supplies everything else needed: selection criteria, the alternative tool, and the safety contract. Nothing required to invoke 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 description coverage is 100%, and the schema already explains that task_ids narrows the checklist and batch_label is an echoed free-text field. The description adds nothing about either parameter, so the baseline of 3 applies since the schema carries the full explanatory burden.

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?

States a specific verb and resource ('Inspect review queue, group tasks by topic/runner, return Codex review checklist') and names the concrete artifact it produces. It is clearly differentiable from per-task siblings like aiworkhub_task_codex_handoff because the grouping-by-topic/runner scope is explicit.

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 says 'Use this for a topic/runner-grouped review checklist' and routes the agent to aiworkhub_task_codex_handoff for 'per-task risks and finalize commands'. That is a direct when-to-use plus named alternative, which is the strongest form of selection guidance.

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