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

With no annotations, the description carries the full burden, and it does disclose two real behavioral traits: the capsule hash is verified and tampered capsules are refused. It says nothing about permissions, whether the operation is idempotent or reversible, or what happens to an existing hold, so significant disclosure gaps remain.

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?

Two tight sentences with the action front-loaded and the requirement list relegated to the back. The parenthetical is compact and informative rather than wasted, though the trailing required-parameter list is redundant with the schema.

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?

A mutating, unattended operation with no annotations, no output schema, and no explanation of the opaque 'budget' parameter or the failure mode on a hash mismatch. The hash-verification note helps, but an agent still lacks what it needs to invoke this safely and correctly.

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 0% for three parameters, so the description is the only source of meaning. It merely restates the required parameter names ('Requires api_token, capsule_id, budget') without explaining budget units or limits, token format, or capsule_id provenance, adding essentially nothing over the schema's required list.

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?

States a specific verb and resource (restore a snapshot capsule) plus the target scope (a NEW hold), which is more specific than the sibling hold-management tools. It does not explicitly contrast itself with demurrage_register_hold or demurrage_release_hold, so the differentiation is only partial.

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?

There is no statement of when this tool should be chosen over the sibling hold tools, nor any prerequisites or exclusions beyond the parenthetical about tampered capsules. The phrase 'into a NEW hold' hints at the use case but the agent must infer the selection criteria itself.

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