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

Annotations already declare a non-read-only, non-destructive mutation, and the description adds real context beyond them: the move never approves content and nothing goes live, a repeat/edge case returns vendor_booked, and the call needs `review` or `publish` scope on an agency plan. It does not describe what happens to review state or history after the move, which keeps it short of a 5.

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?

Scope, side-effect guarantee, error routing, permissions and plan gating are front-loaded before the parenthetical endpoint. Every sentence carries distinct operational information with no restatement of the title or schema.

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 two-parameter mutation with full schema coverage and an output-schema-free interface, the description supplies everything an agent needs: what it mutates, what it explicitly does not do, the failure branch, and the access requirements.

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 nested `to` object already documents the exactly-one-of forms, so the baseline is 3. The description earns credit above baseline by translating those forms into user-level phrasing ("move to Tuesday 10:00", "+1 day"), which helps an agent map intent to the right union branch.

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 (moves posts held for review) plus its scope boundary: one or many posts, moved to another time. It is clearly distinguishable from siblings like update_scheduled_post, move_approvals and decide_review because it explicitly says moving never approves and nothing goes live.

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 use context (posts held for review) and names the alternative for a specific case: a post already booked at the platform answers vendor_booked, so use update_scheduled_post. It does not spell out when to prefer move_approvals or how this differs from plain rescheduling in the general case, but the guidance that exists is concrete and actionable.

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