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

The description adds substantial context beyond the annotations: no provider call, no charge, and reuse semantics where an existing quote or its already-accepted child is returned. That is exactly the kind of cost/idempotency detail the annotations cannot express. What it leaves unexplained is the destructiveHint=true annotation — nothing in the text tells the agent what could be destroyed, which is a notable silence for a tool flagged 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?

Four short sentences, front-loaded with the core action and followed by safety constraints; nothing is padded. The final warning sentence is slightly overlapping with the reuse sentence but still earns its place as an explicit prohibition.

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 values need not be described, and the cost/no-provider-call behavior is covered. Still, a 6-parameter tool with nested objects and a destructive flag has undocumented required inputs (work_id, run_id, request_key) and no explanation of the destructive annotation, leaving real gaps for correct invocation.

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?

With only 50% schema description coverage, the description needs to compensate for work_id, arguments.run_id, and request_key, but it never references any parameter by name or explains the accepted run_id form. Phrases like 'saved source continuation' hint at server-side state rather than clarifying the required run_id or the idempotency purpose of request_key, so the description adds essentially no meaning beyond the schema.

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 names a specific action (quote the next page) against a specific resource (an observed completed ad-library run), and states the mechanism: saved source continuation plus original filters. The word 'next' implicitly distinguishes it from native.quote_social_research and native.start_social_research without naming either sibling outright.

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?

The closing sentence gives a real negative rule ('Never invent a cursor or restart an uncertain request'), which tells the agent when not to use it. However, it never names the alternative tools to use instead (initial quote vs. start vs. wait_for_social_research), so routing still has to be inferred from sibling names.

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