archive_unpack

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states a high-level action and a negative clarification. It does not mention whether the operation extracts all entries by default, writes files to disk, overwrites anything, requires specific permissions, or what the output looks like. This is a significant gap for a potentially mutating tool.

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?

While the description is very short, it is under-specification rather than genuine conciseness. It is a single fragment with no structured organization, and the cryptic parenthetical does little to clarify the tool's behavior. It lacks essential details that the schema and usage require, so it fails to be an efficient, useful description.

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?

For a tool with 6 parameters, 2 required, nested objects, and no output schema or annotations, this description is severely incomplete. It does not explain return values, side effects, error conditions, or the meaning of key parameters like 'scheme'. The description leaves the agent with almost no contextual understanding beyond the bare action of unpacking an archive.

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 description coverage is only 17% (only 'entries' has a description), and the tool description adds almost no meaning to the parameters. It does not explain 'path', 'format', 'output', 'scheme', or 'scheme_params', nor how they interact. The single sentence does not compensate for the low schema coverage, leaving most parameters effectively undocumented.

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?

The description clearly states the tool's action ('Unpack') and resource ('natively supported archive'), which gives a clear sense of purpose. The parenthetical '(NOT script→JSON)' helps distinguish it from script-processing tools, but it doesn't differentiate it from other archive-related siblings like xp3_unpack or archive_pack, so it's not fully distinct.

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 provides only a negative hint ('NOT script→JSON') about when not to use it, but gives no positive guidance on when to use it versus alternatives such as archive_pack, xp3_unpack, or archive_list. There is no explicit context, prerequisite, or exclusion beyond the one negative clarification.

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