Sairen

dead_letter_queue

Park failed task executions in a dead-letter queue, let recovery agents inspect and lease them, and manage retry lifecycles with ack/nack. Includes queue stats and purge actions.

Instructions

    [Cost: $0.0010 USDC on Base & Solana] Ephemeral Dead-Letter Queue and Error Vault for Multi-Agent Swarms.
    Parks failed task execution payloads, allows recovery supervisor agents to lease/inspect failed runs,
    and manages retry lifecycles (ack/nack).

    Actions:
    - 'push' : Park a failed tool execution (requires tool_name, error_message, payload).
    - 'pop'  : Lease the oldest failed task for recovery/replay.
    - 'peek' : Inspect failed tasks in the queue without dequeuing.
    - 'ack'  : Acknowledge successful recovery of a task (removes from DLQ).
    - 'nack' : Report retry failure (increments retry count; marks dead if limit reached).
    - 'stats': Get queue health, depth, and failure reason aggregates.
    - 'clear': Purge expired or resolved items from the queue.

Input Schema

TableJSON Schema

Name	Required	Default
`limit`	No
`action`	No	push
`payload`	No
`task_id`	No
`tool_name`	No	unknown
`error_type`	No	UnknownError
`queue_name`	No	default
`max_retries`	No
`ttl_seconds`	No
`error_detail`	No
`error_message`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.3.0Sep 25, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral burden. It discloses important state-changing effects: ack removes from the queue, nack increments retry count and marks dead at the limit, clear purges expired/resolved items, and pop leases the oldest task. It also mentions the ephemeral nature and cost. It does not detail lease timeout or persistence semantics, which prevents a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and concise, front-loading the purpose and then using a clean bulleted list of actions. Every sentence adds useful information: cost, use case, action semantics, and retry lifecycle. There is no fluff or redundancy.

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?

Given the tool's moderate-high complexity (11 parameters, no annotations, no schema-level parameter descriptions), the description does well by explaining each action's behavior and the general retry lifecycle. The presence of an output schema covers return values. It is not fully complete because some parameters like task_id, queue_name, and limit are not explicitly tied to their actions, but the description provides sufficient orientation for correct high-level use.

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 description coverage is 0%, so the description must compensate. It substantially does by defining the action parameter's allowed values and semantics, and explicitly states that 'push' requires tool_name, error_message, and payload. However, it leaves some parameter-to-action mappings implicit (e.g., task_id for ack/nack, limit for stats/peek), so it is helpful but not exhaustive.

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 clearly identifies the resource as a 'Dead-Letter Queue and Error Vault' and states the specific verb 'Parks failed task execution payloads'. It also enumerates distinct actions (push, pop, peek, ack, nack, stats, clear), making the tool's functionality unambiguous and distinct from the sibling tools.

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

Usage Guidelines4/5

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

The description provides clear context: it is intended for multi-agent swarms and recovery supervisor agents to lease, inspect, and manage failed task execution payloads. It does not explicitly name when-not-to-use alternatives, but no sibling tool appears to be a direct DLQ alternative, so the omission is minor.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server