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

Annotations already cover the safety profile (readOnly, non-destructive, not idempotent), and the description adds substantial independent context: it returns missing/failed checkpoints as well as successes, distinguishes observed_at from snapshot_at, and warns that null counters mean unknown rather than zero. That is exactly the kind of interpretive disclosure annotations cannot carry.

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 usage trigger is front-loaded, followed by return semantics and then interpretation caveats. Six sentences is dense but each carries distinct information (age-at-capture guidance, snapshot_at meaning, null semantics, non-finality). Slightly longer than necessary, 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?

With no output schema, the description must explain returns, and it does: checkpoints, missing/failed observations, observed_at vs snapshot_at, and null handling, with pagination delegated to a well-documented schema. The main omission is any pointer to sibling tools for cross-post comparison, which the age-comparison note gestures at but doesn't route.

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 67%: limit and cursor are thoroughly documented in the schema, but post_id carries only a UUID pattern with no prose. The description refers to 'a specific post' but adds no format, existence, or lookup details beyond what the pattern already implies, so it neither compensates for the gap nor adds meaning.

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 — retrieving how a specific post's recorded engagement changed — and the scope (a single post, historical checkpoints). The phrase 'recorded counters are not live' implicitly contrasts it with get_live_summary/get_post, but it never names those siblings, so the differentiation is inferential rather than explicit.

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?

Opens with a clear when-to-use trigger ('Use when checking how a specific post's recorded engagement changed after publication') and adds when-not guidance via the caveat that counters are not live totals. It doesn't name the alternative tools (get_live_summary, get_post) an agent should weigh against it, which keeps it short of a 5.

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