Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_completion_inbox

Read-only

Retrieve a read-only snapshot of review queues, operational failures, stale processing tasks, runner mismatches, and latest validation facts in one call for Codex orchestration.

Instructions

READ-ONLY: combined completion-inbox facts for Codex orchestration.

Returns five facets in one call: review_queue (tasks awaiting Codex review, as aiworkhub_task_review_queue lists them), operational_failures (legacy finalizer failures eligible for retained retry), stale_processing (claimed tasks with no recent artifact/validation activity, default threshold 24h), runner_mismatch_warnings (batch-token mismatches between a runner name and the task_id it claimed -- a local pure replica of AITools/taskctl.py::_runner_task_batch_mismatch), and latest_validation_facts (the most recently recorded validation_status/ validation_error/blocker_reason per task).

FROZEN READ-ONLY CONTRACT -- no write-gate toggle, no mutation parameters. Only issues taskctl list/taskctl show (both read-only). Never calls taskctl done/review/start/auto-pickup/add-card/export-jsonl. Never mutates queue or audit state. Never launches agents or processes beyond the existing taskctl.py read-only child-process calls.

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

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum cards read per queue status (pending, processing, review, blocked); default 200, clamped to 1-500.
topicNoOnly include tasks with this topic; omit to include every topic.
stale_processing_hoursNoHours without recorded activity after which a processing task is listed under stale_processing, oldest first; default 24.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.12.67
    • addedInput schema / properties / limit / description
      Added value: +"Maximum cards read per queue status (pending, processing, review, blocked); default 200, clamped to 1-500."
    • addedInput schema / properties / stale_processing_hours / description
      Added value: +"Hours without recorded activity after which a processing task is listed under stale_processing, oldest first; default 24."
    • addedInput schema / properties / topic / description
      Added value: +"Only include tasks with this topic; omit to include every topic."
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Beyond readOnlyHint=true and openWorldHint=false, the description discloses the implementation boundary: only taskctl list/show are issued, and done/review/start/auto-pickup/add-card/export-jsonl are never called, nor are agents or processes launched. That is genuinely useful context, though it partly restates the read-only annotation and says nothing about latency or cost of the child-process calls.

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 five-facet enumeration is front-loaded and each facet gets a compact parenthetical definition; the nested backtick references are dense but purposeful. Minor redundancy in stating read-only twice ('READ-ONLY' and 'FROZEN READ-ONLY CONTRACT').

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?

For a five-facet aggregator with an output schema, the description defines every facet clearly enough to interpret results, and the read-only contract is fully spelled out. It leaves minor gaps around ordering and how limit is applied across statuses, but nothing essential to correct invocation 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 the baseline is 3. The description reinforces the default 24h stale threshold that stale_processing_hours controls, but it does not explain limit's per-status clamping or topic's filtering semantics beyond what the schema already states.

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 description names a specific resource (completion-inbox facts for Codex orchestration) and enumerates exactly the five facets returned: review_queue, operational_failures, stale_processing, runner_mismatch_warnings, latest_validation_facts. It also distinguishes itself from sibling aiworkhub_task_review_queue by noting that facet mirrors what that tool lists, making the aggregate-vs-single-purpose split obvious.

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?

Usage context is clear: this is the single-call aggregate for completion/health triage, and the facet definitions tell the agent what each section is for (e.g. legacy finalizer failures eligible for retained retry, stale claimed tasks). It stops short of explicit routing guidance such as 'use this instead of calling task_review_queue and task_health separately' or when to prefer task_show for a single task.

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