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

Annotations already mark this as non-read-only and non-idempotent; the description adds that a fresh controller proof is required, that the envelope is AES-256-GCM sealed with key_kind=controller_key, and that the bearer form is legacy. It does not disclose write side effects such as overwriting or retention, but the annotations cover the basic safety profile.

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?

Three terse sentences, each carrying a distinct fact: the endpoint and required payload, the envelope encryption details, and the legacy/ownership constraint. There is no filler or repetition, and the action is front-loaded.

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 7-parameter write tool with a nested envelope and cryptographic proof requires more walk-through than this. It never explains how the controller proof is derived beyond the schema's nonce hint, what the required body parameter is for, or how this relates to locker_seal for envelope creation. The output schema covers returns, but the input workflow is largely left implicit.

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 71%, covering nonce, envelope, leave, controller_signature, and controller_public_key, but bag and body lack descriptions. The description confuses rather than clarifies by calling 'Bearer {bag, body}' legacy while the schema still requires body, leaving an agent uncertain whether to send body and what it means. It adds some value for envelope sealing and the nonce-based proof, but not enough for a complex 7-parameter call.

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 names the exact endpoint (POST /api/locker) and the payload composition (fresh controller proof, bag, envelope), which identifies this as the locker write path and differentiates it from locker_read/seal/purge. It stops short of a 5 because it relies on domain jargon like 'GRITH-CONTINUITY/1' and never states the plain-language action 'store this data'.

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 explicit when-to-use or when-not-to-use statement naming sibling tools. The description gives only implied context: a fresh controller proof is required, it is limited to 'your bags only,' and 'Bearer {bag, body} remains legacy' hints that the new proof-based path is preferred over the old bearer method.

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