Skip to main content
Glama

Archive a worker

archive_worker
Destructive

Soft-delete a worker: it can no longer claim or lease tasks, disappears from list_client_team and whoami by default, and stops counting against your organization's worker quota. All history — past task assignments, receipts, transparency-log entries — remains intact and queryable. Reversible with unarchive_worker. API reference: https://tango.applayer.io/docs/api/tools/archive_worker

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonNoWhy this worker is being retired.
worker_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true and readOnlyHint=false; the description goes far beyond by enumerating concrete effects (cannot claim/lease tasks, drops out of list_client_team and whoami, frees quota) and, importantly, what is NOT destroyed (history, receipts, transparency-log entries stay queryable). It also flags reversibility, which tempers the destructive hint meaningfully.

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?

Three compact sentences, front-loaded with the core action and effects, followed by the reversibility escape hatch and a reference link. Every sentence earns its place; no filler.

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 no output schema, the description carries the return/effect burden and does so thoroughly (state changes, list visibility, quota, preserved history, reversibility). Nothing an agent needs to invoke this destructively-but-reversibly is missing.

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 50%: worker_id carries format/pattern but no prose, while reason is documented in the schema itself ('Why this worker is being retired.'). The description adds no parameter-level meaning beyond the schema, so this sits at the baseline for a partially documented schema.

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?

States a precise verb+resource ('Soft-delete a worker') and immediately clarifies the scope of that soft-delete, distinguishing it from the sibling delete_worker and from unarchive_worker. An agent can pick this tool over its near-neighbors without opening any other definition.

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?

Explicitly names the reverse operation ('Reversible with unarchive_worker') and spells out the operational consequences that motivate choosing this tool. It stops short of an explicit when-to-use-this-vs-delete_worker rule, but the soft-delete framing makes the choice fairly clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources