Skip to main content
Glama

aiworkhub_task_review_summarize

Read-only

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

Instructions

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

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.

Input Schema

NameRequiredDescriptionDefault
task_idsNo
batch_labelNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior5/5

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

Beyond readOnlyHint, the description discloses important behavioral boundaries: it calls the B110 core, never calls taskctl mutation commands, never mutates queue or audit state, never launches agents/processes, and writes remain default-off. This is unusually strong transparency for a read-only tool.

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 description front-loads the read-only status and purpose, then enumerates safety guarantees in a structured way. It is somewhat repetitive in reinforcing no-mutation behavior, but the repetition is purposeful for a safety-sensitive tool.

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 description covers the read-only contract and general return contents, and an output schema exists. However, it lacks parameter guidance and sibling differentiation, which are meaningful gaps for invoking the right tool with the right arguments.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The two parameters are task_ids and batch_label, but the description does not explain their meaning or effect. With 0% schema description coverage, the description fails to compensate for missing parameter documentation.

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 description states a specific read-only action: inspect the review queue, group tasks by topic/runner, and return a Codex review checklist. It is clear what the tool does, though it does not explicitly distinguish itself from siblings such as aiworkhub_task_review_queue or aiworkhub_review_packet.

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?

It indicates the tool is read-only and produces a Codex checklist, but gives no explicit guidance on when to use this instead of related review tools. Alternatives are not named and no inclusion/exclusion conditions are provided.

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