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

Annotations only say readOnlyHint=false and destructiveHint=false; the description adds substantial traits beyond that: payload is loaded server-side, internal receipt/route fields are stripped, ownership and parent bindings are revalidated at prepare time, and source end times are never auto-extended. This tells the agent this is a non-executing preparation step whose behavior is bounded and non-destructive.

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?

Five tight sentences, front-loaded with what the tool does and then layering eligibility, scheduling, and constraints. Every sentence adds an actionable fact and none restates the title or the 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?

With no output schema and only three annotation hints, the description carries the burden well: purpose, server-side processing, eligibility, and parameter usage are all covered. The remaining gap is lifecycle guidance — what state is produced, whether it expires, and the required call to campaigns_recreate_confirm/deny.

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% at the top level, so the description must compensate. It explains that task_ref is an opaque handle and that execution.start_time/end_time drive an explicit reschedule, but connection_context (mctx_v1 pattern) is never mentioned, leaving one of three parameters undocumented in both schema and description.

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+resource ('Prepare a recreation of ... a TikTok create/copy task') and scopes it to caller-owned, fully completed tasks identified by task_ref. It is clear what the tool does, but it never names its natural siblings campaigns_recreate_confirm / campaigns_recreate_deny, so the two-phase prepare/confirm pattern must be inferred.

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 real eligibility context: only fully completed, caller-owned tasks are recreatable, and failed/partial/uncertain/foreign tasks are explicitly excluded. It also tells the caller to use execution.start_time/end_time for a rescheduled launch, but it omits the follow-up step (confirm/deny), so no alternative is named.

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