Back up the credentials and encryption key

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

The description adds material behavior beyond annotations: Obsideo holds no copy of the encryption key, losing the local file makes encrypted objects unrecoverable, and destination format changes the copy mode (.tar.gz archive vs. plain files vs. default home archive). This is exactly the kind of risk context an agent needs before invoking the 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?

The description is compact: four focused sentences covering purpose, critical risk, call timing, and path behavior. Every sentence earns its place, and the most important caveat about the encryption key 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?

For a simple one-optional-parameter tool, the description covers everything needed to invoke it correctly: what is copied, where it goes, how the destination format changes the result, and when to call it. The absence of an output schema is fine because the tool's action is a file-copy operation, not a returned data structure.

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 100%, so the schema already documents the destination parameter and its default. The description adds meaningful semantics on top by explaining what each destination form produces ('one archive' vs. 'plain copies'), which helps an agent choose the right value confidently.

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 a specific action ('Copy everything needed to recover this account's data') and a concrete resource set (credentials, signing key, encryption key, upload commitments). It clearly distinguishes this from the sibling tools by framing it as a local backup/recovery operation rather than an account-management or data-plane call.

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?

Explicit guidance is given on when to call: right after account creation and after any signup that rotates keys. It also explains how destination type changes behavior. It does not explicitly mention when not to call or name alternatives, but no sibling tool is a true alternative, so the guidance is strong.

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