Skip to main content
Glama

aiworkhub_task_show

Read-only

Retrieve a single task card by task_id to inspect lifecycle status, review evidence, or full stored details; select brief, summary, evidence, or full output and page large evidence.

Instructions

Show a single task card by task_id.

Use this for one card by task_id; use aiworkhub_task_list to find cards or aiworkhub_agent_task_status for a launched request's live state.

detail="brief" (default) keeps the card's lifecycle facts only (status, substatus, title, runner, topic, current/last request ids and the terminal_review verdict and blocker) plus the identity fields. Measured over 21 days the former summary default averaged 11,255 B/call (424 calls, 96% the stdout card string). A red card still returns its validation_failed_packet.

detail="summary": retained baseline hash maps (tree, workspace and parent baselines) are folded to entry count plus sha256, and the evidence blobs (terminal_review.evidence.{validation, quality_gate, quality_review, quality_review_receipt, worker_mcp_gate, workspace} and accept_evidence.{validation, quality_gate}) are folded to {summarized, bytes, sha256, verdict/status, failed_count, first_failure}. terminal_failure and rework_predecessor are folded to the facts a reviewer reads (substatus/reason/category/first_error and task_id/request_id/outcome/reason); template_provenance.expanded_contract is folded to identity only. detail="evidence" keeps all of the above exact (baselines still folded); detail="full" or full=True returns the exact stored card. Summary/evidence renders are compact JSON; full keeps the indented one.

The manager-authored bodies (review_feedback, recovery_feedback, history) fold to identity plus their counts in the summary render, and every summary/evidence reply carries card_sha256/card_bytes plus review_findings_count when the card records reviewer reports: measured avg 11.5 KB/call over 31 calls (NF-2026-01447).

detail="evidence" is bounded (NF-2026-02256): when the card's compact JSON exceeds evidence_paging.EVIDENCE_PAGE_CAP_BYTES (64 KB) stdout holds the leading card keys that fit and the reply carries 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

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task_id": "<task_id>"
    },
    "name": "aiworkhub_task_show"
  }
}

Input Schema

NameRequiredDescriptionDefault
fullNoSet true to return the exact stored card, the same as detail=full; default false.
cursorNocontinuation_cursor from a previous detail=evidence reply, to read the next evidence page; default empty (first page).
detailNoHow much of the card to return: brief (default, lifecycle facts only; a red card returns its validation_failed_packet), summary (baselines and evidence folded), evidence (evidence kept exact, baselines still folded, paged at 64 KB) or full (the exact stored card).brief
task_idYesId of the task card to show.

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: -"How much of the card to return: brief (default, lifecycle facts only; a red card returns its validation_failed_packet), summary (baselines and evidence folded), evidence (evidence kept exact, baselines still folded) or full (the exact stored card)."New value: +"How much of the card to return: brief (default, lifecycle facts only; a red card returns its validation_failed_packet), summary (baselines and evidence folded), evidence (evidence kept exact, baselines still folded, paged at 64 KB) or full (the exact stored card)."
  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: -"How much of the card to return: summary (default, baselines and evidence folded), evidence (evidence kept exact, baselines still folded) or full (the exact stored card)."New value: +"How much of the card to return: brief (default, lifecycle facts only; a red card returns its validation_failed_packet), summary (baselines and evidence folded), evidence (evidence kept exact, baselines still folded) or full (the exact stored card)."
    • changedInput schema / properties / detail / enum
      Previous value: -[
      -  "summary",
      -  "evidence",
      -  "full"
      -]New value: +[
      +  "brief",
      +  "summary",
      +  "evidence",
      +  "full"
      +]
  3. Changed3 schema fields changedv0.12.67
    • addedInput schema / properties / detail / description
      Added value: +"How much of the card to return: summary (default, baselines and evidence folded), evidence (evidence kept exact, baselines still folded) or full (the exact stored card)."
    • addedInput schema / properties / full / description
      Added value: +"Set true to return the exact stored card, the same as detail=full; default false."
    • addedInput schema / properties / task_id / description
      Added value: +"Id of the task card to show."
  4. 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 only declare readOnlyHint/openWorldHint, but the description discloses the substantive behavior: what each detail mode retains or folds, the 64 KB evidence page cap, the truncation markers (evidence_truncated, evidence_total_bytes, continuation_cursor), and the evidence_cursor_stale refusal when the card changed. That is exactly the extra context annotations cannot carry.

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?

It is front-loaded well, with purpose and sibling routing first and detail modes after, but the prose is bloated with justification trivia ("11,255 B/call (424 calls, 96% the stdout card string)", "NF-2026-01447", "NF-2026-02256") that does nothing for an agent choosing or calling the tool. The backtick-heavy density makes scanning harder than necessary.

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 annotations, a full output schema, and quoted error codes, the description covers everything an agent needs: mode tradeoffs, size bounds, pagination continuation, and stale-cursor handling. There is no material ambiguity about how to invoke it or what comes back.

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%, so the baseline is 3; the description still adds real meaning by enumerating the concrete fields kept in brief mode, the specific blobs folded in summary mode, and the paging contract behind cursor. It stops short of ordering/precedence edge cases (e.g. full=True combined with detail=brief is only implicitly addressed).

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?

Opens with a specific verb and resource ("Show a single task card by task_id") and immediately differentiates itself from aiworkhub_task_list (finding cards) and aiworkhub_agent_task_status (live request state). An agent can select this tool 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?

Gives an explicit routing rule: this tool for one card by id, task_list for discovery, agent_task_status for launched-request state. It also specifies the practical selection criterion among detail levels (payload size vs. exactness) and when to pass a continuation cursor.

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