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

Annotations already declare destructiveHint=true, but the description adds substantial context beyond them: the preview-first guard, the 30-day restore window, the refusal of a changed record (staleness safety), the restore_id undo path, the $0.10 cost, and the API-key requirement. This is exactly the added behavioral detail expected when annotations only flag destructiveness.

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 workflow and reversibility facts are front-loaded, and the sentences are dense but purposeful. The trailing cost/API-key parenthetical and some workflow repetition make it slightly longer than strictly necessary, but every element carries useful signal.

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 destructive mutation with a required multi-step preview flow, the description covers the full lifecycle: preview, apply, and undo. With an output schema present, it need not detail return values, and it still names restore_id, so an agent has everything needed to call it 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 coverage is 100%, so the baseline is 3, but the description adds meaning: it clarifies that memory_id and false_atom are supplied to the preview call rather than this one, and that preview_id comes from preview_destructive_change while restore_window_acknowledged must be true after review. It explains the reasoning behind request_id idempotency, though the alias field is left to the schema.

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 (remove one exact false atom) against a specific resource (a bundled memory) and explicitly scopes it as surgical: it retains the other text and clears the stale embedding. This distinguishes it from siblings like delete_memory and merge_memory without needing to open any schema.

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?

Gives an explicit two-step workflow: call preview_destructive_change first with the exact arguments, then call correct_memory_atom after user confirmation with preview_id and restore_window_acknowledged. It names the ordering, the prerequisite, and the confirm step, leaving nothing to inference.

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