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

Annotations already establish readOnly, idempotent, closed-world and non-destructive behavior, so the description rightly spends its words elsewhere. It adds genuinely non-obvious semantics: 'Delivered' means only a saved provider acknowledgment, unknown outcomes are never auto-replayed, and the response redacts credentials, checkpoints and raw provider errors. That is substantive beyond the structured hints, though auth/permission prerequisites are still unstated.

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?

Four sentences, no filler, and the core read scope is front-loaded in the first sentence. The opening sentence is dense with compound noun phrases ('bounded per-channel delivery receipt'), which costs a little readability but nothing is redundant.

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?

An output schema exists, so return structure need not be restated, and the annotations cover the safety profile; the description fills the remaining gaps (what 'delivered' actually proves, no automatic replay, redaction). The one omission for a single-parameter read tool is a clear statement of which sibling to call when the goal is the live post or the operation record.

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 single parameter already carries a description, so the schema does the heavy lifting. The phrase 'belonging to this original key' reinforces that plan_id must match the original request rather than a retry, but adds no format or provenance detail beyond what the schema states.

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 uses a specific verb ('Read') and names the exact resources returned: the frozen social plan, the approval state, and the bounded per-channel delivery receipt, all keyed to the supplied identifier. An agent can distinguish it from webanto_get_social_post (the post itself) and from list_social_posts, though the description never names those siblings explicitly.

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?

Usage is only implied: the tool reads a saved review 'belonging to this original key,' which suggests calling it after preparation or operation recovery. There is no explicit when-to-use, no when-not, and no pointer to the closest alternative (webanto_get_operation_result or webanto_get_social_post) for callers who want the live post rather than the frozen review.

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