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

Adds real information beyond the annotations: a still-pending post never publishes and its $0.02 spend is refunded, a due post is not refunded, and an already-published post is only removed locally while remaining live on the network. The refund and partial-deletion semantics are exactly the kind of context destructiveHint cannot convey, though the garbled phrasing ('so it is not') blunts the clarity of the no-refund case.

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 core purpose is front-loaded, but the middle clause ('one whose time came may have gone out, so it is not') is grammatically broken and hard to parse, and the trailing 'Free. Free.' is a duplicated fragment that reads as an editing artifact with no added meaning.

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 single-parameter destructive tool with no output schema, the description covers the relevant behavioral surface: what gets deleted, what is refunded, and what cannot be undone here. It stops short of saying whether anything is returned (e.g., a refund amount or status) or that the call is non-idempotent, a gap the annotations partly cover.

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% and the schema already tells the agent to source post_id from social_post or social_posts, so the baseline is 3. The description contributes only the cascade note '(with its thread)', which describes the effect of the call rather than clarifying the parameter itself.

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?

Opens with a specific verb and resource ('Delete a post (with its thread)') and scopes it to the business's social workspace, which distinguishes it from read-side siblings like social_posts or social_post_check. It never names a sibling explicitly, so the differentiation is implicit rather than stated.

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?

The description implies when this applies by describing three post states (scheduled, due, already published), which effectively tells the agent which posts can and cannot be deleted here. However it never phrases this as guidance ('use this when...', 'do not use this for...') and only parenthetically points to an out-of-band alternative ('delete it there').

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