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

With no annotations provided, the description carries the full burden and exceeds it. It discloses irreversibility, exactly what data is erased, unspent credits loss, confirmation failure behavior with error code 422, the 409 conflict condition, key invalidation across the account, REST equivalence, and cost. Nothing about the destructive or conditional behavior is left to inference.

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?

Roughly 100 words of dense, high-signal prose. The most critical information (destructiveness, irreversibility) is front-loaded, followed by confirmation requirements, conflict conditions, return format, and side effects. Every sentence earns its place; no filler or repetition of schema fields.

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 an irreversible 2-parameter operation with zero annotations and zero schema descriptions, everything an agent needs to call it correctly and safely is present: preconditions (run-in-flight check), exact confirmation value, error codes, side effects, response shape, REST equivalent, and cost. The output schema exists per context, so return values are also structurally covered.

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%, so the description must compensate. It does so thoroughly for confirm — specifying the exact literal value ('delete my account'), the failure mode, and its error code — which is the parameter an agent is most likely to get wrong. The api_key parameter receives no explanation, but its title is self-describing and it defaults to null, so the gap is minor.

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 first sentence states a specific verb and resource: 'Erase your account and everything in it, for good,' followed by a concrete inventory of what is destroyed (API keys, runs, hooks, decisions, conversations, messages, unspent credits). This clearly distinguishes it from siblings like revoke_key (key-scoped), clear_decision (decision-scoped), and create_account (creation, not destruction).

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?

Provides clear operational context: the exact confirmation string required, the 409 run_in_flight refusal with instruction to wait via get_run first, and mentions create_account as the follow-up for a new account. It lacks a formal when-not-to-use exclusion (e.g., 'for lighter scopes use revoke_key or clear_decision instead'), but 'It cannot be undone' plus the run-in-flight condition gives an agent strong sequencing guidance.

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