Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_task_archive

Idempotent

Archive stale non-processing tasks atomically with per-task receipts and dry-run previews; use selectors or explicit IDs to avoid direct SQLite writes.

Instructions

COORDINATOR WRITE: archive stale non-processing tasks atomically (archived_at + card_json + an archived task_events row each). Runs the full coordinator-capability write gate per item -- use this instead of patching SQLite. For an active/orphaned card use supersede.

Targets: one task_id, task_ids (<= 200), or a selector (status/topic/older_than_hours/task_id_prefix, conjunctive). dry_run=True previews the exact ids (and the processing cards that would be refused) without writing. Replies with per-id receipts {task_id, ok, status_after, error?}; one refusal never hides the rest.

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

Input Schema

NameRequiredDescriptionDefault
topicNoSelector: only archive cards with exactly this topic.
reasonNoWhy the cards are archived, recorded with each audit event; default empty.
statusNoSelector: only archive cards whose status equals this value; all selectors given must match.
dry_runNoSet true to list the exact ids that would be archived, and the processing cards that would be refused, without writing; default false.
task_idNoId of a single card to archive; omit when passing task_ids or a selector.
task_idsNoExplicit list of card ids to archive, at most 200; merged with task_id and de-duplicated, and not combinable with a selector.
task_id_prefixNoSelector: only archive cards whose id starts with this prefix.
older_than_hoursNoSelector: only archive cards last updated at least this many hours ago.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.12.67
    • addedInput schema / properties / dry_run / description
      Added value: +"Set true to list the exact ids that would be archived, and the processing cards that would be refused, without writing; default false."
    • addedInput schema / properties / older_than_hours / description
      Added value: +"Selector: only archive cards last updated at least this many hours ago."
    • addedInput schema / properties / reason / description
      Added value: +"Why the cards are archived, recorded with each audit event; default empty."
    • addedInput schema / properties / status / description
      Added value: +"Selector: only archive cards whose status equals this value; all selectors given must match."
    • addedInput schema / properties / task_id / description
      Added value: +"Id of a single card to archive; omit when passing task_ids or a selector."
    • addedInput schema / properties / task_id_prefix / description
      Added value: +"Selector: only archive cards whose id starts with this prefix."
    • addedInput schema / properties / task_ids / description
      Added value: +"Explicit list of card ids to archive, at most 200; merged with task_id and de-duplicated, and not combinable with a selector."
    • addedInput schema / properties / topic / description
      Added value: +"Selector: only archive cards with exactly this topic."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), it discloses that writes are atomic, that each item passes a coordinator-capability gate, that processing cards are refused rather than archived, and that partial success is possible with per-id receipts. This is exactly the mutating-behavior context the annotations do not carry.

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?

Front-loaded with the mode marker and purpose, then targeting modes, then dry_run, then response shape — a sensible ordering with little waste. Some density (backticks, 'conjunctive', receipt tuple notation) costs readability for an agent skimming.

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 destructive-ish batch mutation the description covers atomicity, gating, partial failure, preview mode, and the sibling alternative, and it summarizes the receipt shape even though an output schema exists. Nothing an agent needs to call it safely is missing.

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 value by grouping the three targeting modes (single id, id list, conjunctive selector set) and by noting dry_run also surfaces the processing cards that would be refused. It largely restates schema-level facts such as the 200 cap and the merge with task_id rather than extending them.

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 verb and resource ('archive stale non-processing tasks') and immediately specifies the exact writes performed ('archived_at + card_json + an ``archived`` task_events row each'), so the agent knows it is not a soft status flip. It also routes away from the sibling 'supersede' for the active/orphaned case, making it distinguishable from aiworkhub_task_supersede and aiworkhub_manager_task_archive.

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?

It gives an explicit replacement directive ('use this instead of patching SQLite') and an explicit exclusion ('For an active/orphaned card use supersede'). It also states the dry_run preview path as the safe first step, so when-to-use and when-not-to-use are both covered.

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