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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, so 'changes nothing' largely restates structured data. The description does add genuinely new facts — that the call is free/uncosted and that it only works by replaying the original call's identifiers — but leaves unresolved what happens when no receipt exists (error vs empty).

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?

One sentence plus a two-word cost/safety clause; the recovery condition and identifier requirement are front-loaded with zero preamble or filler.

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?

There is no output schema, and the description never says what the receipt actually reveals — presumably whether the ambiguous save landed, and at which revision — which is the entire reason an agent would call this. For a recovery tool the payoff of the call should be stated, not inferred.

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 carry the load; it names all three parameters and establishes the crucial semantic that they must be the same values used in the original save call. It still doesn't explain what draftRevision represents (version counter?) or why clientRequestId exists, so the compensation is partial.

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 and resource ('Read the original receipt') plus the exact originating call it relates to ('an earlier soclo_posts_save_drafts call'), which distinguishes it from save_drafts and from plain draft reads. An agent can tell what this tool returns without opening the 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 a clear trigger condition: use after an uncertain result from soclo_posts_save_drafts, and requires replaying the same three identifiers. It does not explicitly exclude alternatives such as soclo_posts_get_draft or soclo_posts_drafts, so it stops short of a full when/when-not routing statement.

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