Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_manager_reconcile_dead_processing

Reconcile an exact authenticated dead worker claim on a blocked task by providing its task ID, request ID, and claim epoch, clearing stale processing state.

Instructions

MANAGER WRITE: reconcile one exact authenticated dead blocked claim.

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>",
      "request_id": "<request_id>",
      "claim_epoch": "<claim_epoch>"
    },
    "name": "aiworkhub_manager_reconcile_dead_processing"
  }
}

Input Schema

NameRequiredDescriptionDefault
task_idYesId of the blocked card whose worker claim is dead.
request_idYesLaunch request id of the worker that held the dead claim; blank is refused with reconcile_identity_invalid, and a request still finalizing with reconcile_failed:process_finalizing.
claim_epochYesEpoch of the dead claim, a positive integer; anything else is refused with reconcile_identity_invalid.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.12.67
    • addedInput schema / properties / claim_epoch / description
      Added value: +"Epoch of the dead claim, a positive integer; anything else is refused with reconcile_identity_invalid."
    • addedInput schema / properties / request_id / description
      Added value: +"Launch request id of the worker that held the dead claim; blank is refused with reconcile_identity_invalid, and a request still finalizing with reconcile_failed:process_finalizing."
    • addedInput schema / properties / task_id / description
      Added value: +"Id of the blocked card whose worker claim is dead."
  2. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

Annotations already declare this is a write, non-read-only, non-open-world, non-destructive operation, so the safety profile is covered. The description adds that the claim must be exact and authenticated, but it does not explain the effect of reconciliation, irreversibility, or required authority beyond the identity fields.

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 definition is a single front-loaded sentence with no filler, and the 'MANAGER WRITE' prefix immediately signals the operation class. It is appropriately terse, though the density of terms like 'dead blocked claim' risks under-clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a write operation with meaningful recovery semantics, the description does not explain what reconciliation actually does or what state transition results. The rich schema, output schema, and annotations reduce the burden, but the core effect of the tool remains opaque.

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 description coverage is 100%, and the parameter descriptions already define task_id, request_id, and claim_epoch in detail including refusal codes. The description only reinforces exact authenticated identity, so it adds little beyond the schema.

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 description names a specific verb (reconcile) and a tightly scoped resource (one exact authenticated dead blocked claim). It is not tautological, but the jargon is dense and it does not differentiate this tool from nearby task-recovery or review-resolution siblings.

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?

The phrase 'one exact authenticated dead blocked claim' implies the qualifying condition, so usage is partially inferable. However, there is no explicit when-to-use guidance, no when-not-to-use condition, and no named alternative among the many task/agent recovery tools.

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