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

With no annotations, the description carries the burden well: it discloses that archival is reversible ('a message to it brings it back'), that open tasks move with it, and — critically — that routines keep running, which is a non-obvious side effect. It omits permissions/auth needs and whether the call is idempotent or errors on an already-archived agent.

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

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

Front-loads the core action, which is good, but the UI analogue is stated twice ('as Archive agent on the Agents page does' and 'as in the app'), and the middle clause 'open tasks and all' is loose where precision is needed. Trimmed of redundancy it would be two tight sentences.

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

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

No output schema and no annotations, yet the description covers the state change, reversibility, side effects on tasks and routines, and the unarchive override — enough to call it correctly. The remaining hole is return/error behavior and the identifier format for 'agent'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It handles 'unarchive' well ('puts it back in the list'), but gives no format guidance for the required 'agent' parameter — whether it takes an ID, a name, or a slug. That is the single most likely invocation error for this tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb+resource pairing ('Archive one of the user's agents') with an explicit anchor to the equivalent UI action, so the agent knows exactly what operation this represents. It implicitly distinguishes itself from siblings like organize_agents, update_agent, and list_agents by being about archiving rather than listing/editing, though it never names them.

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

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

The description implies usage ('as Archive agent on the Agents page does') and names one alternative path weakly — pause_routine is referenced as the way to stop routines. But there is no explicit 'use this when…/do not use this when…' guidance versus siblings such as organize_agents or update_agent, and no preconditions stated.

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