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

Goes well beyond the annotations: discloses credit consumption ('SPENDS CREDITS'), scope of side effects ('sends nothing'), latency and return semantics ('takes several minutes; this returns as soon as it starts'), where results surface (get_status), and a hard precondition that blocks invocation. The annotations only give generic mutation/open-world hints; the description supplies the operational detail that actually governs correct use.

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?

Front-loads the core action, then layers cost, side-effect scope, async behavior, and the blocking precondition in dense, non-redundant sentences. Every sentence changes how an agent would call the tool; nothing is 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?

No output schema, yet the description compensates by telling the agent the call returns immediately and that get_status is where drafts appear. Combined with the cost and refusal preconditions, an agent has everything needed to invoke this correctly and interpret the empty-looking immediate return.

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?

Single required parameter with 100% schema description coverage, so the schema already carries the workspaceId semantics ('Which site to act on... call get_status to list them'). The description's 'for one site' adds framing but no new parameter-level detail. Baseline 3 for high coverage.

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 ('Starts a discovery and drafting run for one site') and immediately distinguishes it from the scheduled equivalent ('instead of waiting for the next scheduled one'). An agent can tell this apart from sibling tools like approve_batch or plan_campaign_change without opening any 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?

Explicitly frames when to use it (immediate run vs. waiting for the schedule) and when it will fail ('Refused while a batch is already waiting for approval, so deal with those first'). It stops short of naming the specific sibling to invoke for that pending batch, leaving the agent to infer approve_batch/skip_batch/list_pending_drafts.

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