Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_task_supersede

Supersede a stale or active task with a replacement, archive the original as superseded, and optionally record the successor task ID.

Instructions

COORDINATOR WRITE: supersede a stale/active task with a replacement.

Archives the card as superseded (allowed even from processing) and records the optional replacement task id via by. Full coordinator- capability gate; atomic; no direct SQLite patching.

Replies with a receipt (aiworkhub.task_supersede_receipt.v1): task_id, status, card_sha256/card_bytes plus any server-derived keys the core call attached. include_card = none (default) | summary (baselines and evidence folded) | full (the exact post-transition card).

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

Input Schema

NameRequiredDescriptionDefault
byNoId of the replacement task, recorded as superseded_by; it must be an existing task other than task_id and must not create a dependency cycle. Omit for none. With continue_capped it names the successor to create instead.
reasonNoWhy the card is being superseded, recorded with the audit event; default empty.
task_idYesId of the stale or active card to supersede; allowed even while it is processing.
include_cardNoCard view to attach to the receipt: none (default), summary (baselines and evidence folded) or full (the exact post-transition card).none
continue_cappedNoWhen true, task_id must be a pending card stopped by the reject depth cap whose rework predecessor has a verified sealed delta; a pending successor with the same contract (id by, else <task_id>-c<N>) is created, inherits that delta and the reason as rework feedback, and then supersedes task_id. The reply gains continuation {successor_task_id, predecessor_request_id, delta_digest}; the successor is not launched. Default false leaves the call unchanged.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.12.80
    • changedInput schema / properties / by / description
      Previous value: -"Id of the replacement task, recorded as superseded_by; it must be an existing task other than task_id and must not create a dependency cycle. Omit for none."New value: +"Id of the replacement task, recorded as superseded_by; it must be an existing task other than task_id and must not create a dependency cycle. Omit for none. With continue_capped it names the successor to create instead."
    • addedInput schema / properties / continue_capped
      Added value: +{
+  "default": false,
+  "description": "When true, task_id must be a pending card stopped by the reject depth cap whose rework predecessor has a verified sealed delta; a pending successor with the same contract (id by, else <task_id>-c<N>) is created, inherits that delta and the reason as rework feedback, and then supersedes task_id. The reply gains continuation {successor_task_id, predecessor_request_id, delta_digest}; the successor is not launched. Default false leaves the call unchanged.",
+  "title": "Continue Capped",
+  "type": "boolean"
+}
  2. Changed4 schema fields changedv0.12.67
    • addedInput schema / properties / by / description
      Added value: +"Id of the replacement task, recorded as superseded_by; it must be an existing task other than task_id and must not create a dependency cycle. Omit for none."
    • addedInput schema / properties / include_card / description
      Added value: +"Card view to attach to the receipt: none (default), summary (baselines and evidence folded) or full (the exact post-transition card)."
    • addedInput schema / properties / reason / description
      Added value: +"Why the card is being superseded, recorded with the audit event; default empty."
    • addedInput schema / properties / task_id / description
      Added value: +"Id of the stale or active card to supersede; allowed even while it is processing."
  3. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Well beyond the annotations: it discloses that the card is archived as 'superseded', that processing-state cards are permitted, that a full coordinator-capability gate applies, that the operation is atomic, that no direct SQLite patching occurs, and that a versioned receipt is returned. Only the reversibility/rollback story and error modes are left unstated.

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?

Three short blocks: what it does, how it behaves, what it returns. Front-loaded and nearly waste-free; the receipt paragraph is slightly denser than needed but earns its place by naming the schema version.

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 gated mutation tool with an output schema, the description covers safety gating, atomicity, state transition, and receipt contents, which is close to everything needed before calling. The one significant gap is that the richest parameter, continue_capped, is never mentioned in the prose.

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 baseline is 3. The description adds a little meaning by explaining that `by` records an optional replacement task id and by naming the include_card modes, but it omits continue_capped entirely, leaving the schema to carry that complex conditional.

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 first line gives a specific verb and resource ('supersede a stale/active task with a replacement') plus an explicit 'COORDINATOR WRITE' classification, so the agent knows exactly what the call does. It does not explicitly distinguish itself from the near-name sibling aiworkhub_task_archive or aiworkhub_manager_task_supersede, which keeps it below a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives conditions implicitly ('stale/active task', 'allowed even from processing') and the schema covers the continue_capped special case, but the prose never states when to pick this over aiworkhub_task_archive or other lifecycle tools. Usage is inferable but not routed.

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