Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_agent_task_status

Read-only

Inspect one launched worker request and its authoritative task card in read-only mode, returning brief, summary, evidence, or full lifecycle status for manager review.

Instructions

READ-ONLY: inspect one launched process and its authoritative task card.

Use this for one launched request and its card; use aiworkhub_agent_list_processes to find recent requests or aiworkhub_task_show for a card by task_id alone.

detail="brief" (default) keeps only the lifecycle facts a manager reads to learn state: the identity and lifecycle fields, the card's scalar lifecycle fields and the latest event's state, exit code, timestamps and usage totals. Measured over 21 days the former summary default averaged 12,765 B/call (792 calls); review decisions come from aiworkhub_review_packet. detail="summary" folds the card's baseline hash maps and evidence blobs, its terminal_failure/rework_predecessor/ template_provenance.expanded_contract, and its static contract text (objective/acceptance/validation/read_first/template_provenance/ project_context/forbidden/required_outputs/mandatory_changed_outputs) to {summarized, bytes, sha256} -- identity and lifecycle fields (task_id, title, status, substatus, runner, topic, request ids, allowed_writes count) stay exact. The latest event's validation/quality_gate/ worker_mcp_gate/token_budget/project_context fold the same way, without redundant field-name inventories. Repeated retry/reroute reasons and the minimality contract fold to identity; named artifact/delivery/review receipts retain status, errors and explicit observed/unknown flags alongside identity. Failure/liveness fields and usage metrics stay exact. The manager-authored bodies (review_feedback, recovery_feedback, history) fold the same way, and the reply carries card_sha256/card_bytes plus review_findings_count when the card records reviewer reports: measured avg 11 KB/call over 48 calls, max 33 KB (NF-2026-01447). "evidence" keeps all of the above exact (baselines still folded); "full" returns the raw status payload. "evidence" is bounded (NF-2026-02256): when the compact JSON of the task_card and latest_event sections exceeds evidence_paging.EVIDENCE_PAGE_CAP_BYTES (64 KB) the reply carries the leading section keys that fit plus evidence_truncated, evidence_total_bytes, evidence_sha256 and continuation_cursor; pass that cursor back to read the next page. A cursor for a card that changed since refuses with evidence_cursor_stale.

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

Input Schema

NameRequiredDescriptionDefault
cursorNocontinuation_cursor from a previous detail=evidence reply, to read the next evidence page; default empty (first page).
detailNobrief (default) keeps the lifecycle facts only; summary folds bulky card and event bodies to size and sha256 digests while identity and lifecycle fields stay exact; evidence keeps the evidence exact too, paged at 64 KB; full returns the raw status payload.brief
task_idNoId of the task card whose latest launched request to inspect, used only when request_id is omitted; default empty.
request_idNoId of the launched worker request to inspect; omit and pass task_id to inspect that card's latest launched request (the reply's request_id_source says which).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.13.0
    • addedInput schema / properties / cursor
      Added value: +{
+  "default": "",
+  "description": "continuation_cursor from a previous detail=evidence reply, to read the next evidence page; default empty (first page).",
+  "title": "Cursor",
+  "type": "string"
+}
    • changedInput schema / properties / detail / description
      Previous value: -"brief (default) keeps the lifecycle facts only; summary folds bulky card and event bodies to size and sha256 digests while identity and lifecycle fields stay exact; evidence keeps the evidence exact too; full returns the raw status payload."New value: +"brief (default) keeps the lifecycle facts only; summary folds bulky card and event bodies to size and sha256 digests while identity and lifecycle fields stay exact; evidence keeps the evidence exact too, paged at 64 KB; full returns the raw status payload."
  2. Changed3 schema fields changedv0.12.94
    • changedInput schema / properties / detail / default
      Previous value: -"summary"New value: +"brief"
    • changedInput schema / properties / detail / description
      Previous value: -"summary (default) folds bulky card and event bodies to size and sha256 digests while identity and lifecycle fields stay exact; evidence keeps the evidence exact too; full returns the raw status payload."New value: +"brief (default) keeps the lifecycle facts only; summary folds bulky card and event bodies to size and sha256 digests while identity and lifecycle fields stay exact; evidence keeps the evidence exact too; full returns the raw status payload."
    • changedInput schema / properties / detail / enum
      Previous value: -[
-  "summary",
-  "evidence",
-  "full"
-]New value: +[
+  "brief",
+  "summary",
+  "evidence",
+  "full"
+]
  3. Changed4 schema fields changedv0.12.87
    • addedInput schema / properties / request_id / default
      Added value: +""
    • changedInput schema / properties / request_id / description
      Previous value: -"Id of the launched worker request to inspect."New value: +"Id of the launched worker request to inspect; omit and pass task_id to inspect that card's latest launched request (the reply's request_id_source says which)."
    • addedInput schema / properties / task_id
      Added value: +{
+  "default": "",
+  "description": "Id of the task card whose latest launched request to inspect, used only when request_id is omitted; default empty.",
+  "title": "Task Id",
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "request_id"
-]
  4. Changed2 schema fields changedv0.12.67
    • addedInput schema / properties / detail / description
      Added value: +"summary (default) folds bulky card and event bodies to size and sha256 digests while identity and lifecycle fields stay exact; evidence keeps the evidence exact too; full returns the raw status payload."
    • addedInput schema / properties / request_id / description
      Added value: +"Id of the launched worker request to inspect."
  5. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/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 that with a leading "READ-ONLY" marker. Beyond annotations it discloses the paging cap (64 KB), truncation fields, continuation_cursor usage, the evidence_cursor_stale refusal condition, and measured payload costs per detail mode — all behavioral facts an agent cannot get from structured fields.

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 critical routing sentence is correctly front-loaded, but the body is a dense wall of prose. Measurement statistics ("12,765 B/call (792 calls)", "avg 11 KB/call over 48 calls, max 33 KB") and internal ticket identifiers (NF-2026-01447, NF-2026-02256) consume space without helping an agent decide whether or how to call the tool.

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?

For a no-required-parameter inspection tool with an output schema, this covers everything an agent needs: which identifier selects what (request_id vs. task_id and the request_id_source signal), the four detail levels, cost/size expectations, and the truncation/continuation protocol. Nothing material is left to inference.

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

Parameters4/5

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

Schema coverage is 100% and the enum descriptions already sketch each detail mode, so the baseline is 3. The description earns an extra point by explaining the substantive difference between modes (what folds to {summarized, bytes, sha256} in summary vs. what stays exact in evidence) and by defining the cursor round-trip and its staleness failure, but it largely restates the enum rather than introducing new parameter meaning.

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 and resource ("inspect one launched process and its authoritative task card") and immediately scopes it to a single request. It names the two sibling tools it is not (aiworkhub_agent_list_processes for discovery, aiworkhub_task_show for card-by-task_id), so an agent can discriminate without opening any schema.

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?

Explicit when-to-use and when-to-use-something-else guidance: "Use this for one launched request and its card; use aiworkhub_agent_list_processes to find recent requests or aiworkhub_task_show for a card by task_id alone." It also routes review decisions to aiworkhub_review_packet, giving three concrete alternatives with their selecting conditions.

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