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

With destructiveHint=true and openWorldHint=true already declared, the description still adds real value: it discloses the external URL fetch, the external analysis model, two distinct polling surfaces depending on client capability, and the idempotency_key retry contract after an uncertain response. It does not say what existing study state the queued turn may overwrite, which is the main gap given destructiveHint=true. The idempotency_key guidance sits in tension with idempotentHint=false but is consistent in spirit (safety only via the key), so it is not a contradiction.

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 short sentences, no filler, and the core async nature is front-loaded ahead of client-routing and follow-up instructions. Density is high but each sentence carries an actionable fact; slightly more signposting of the routing branch would help scanning.

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 shape needn't be explained, and the description does cover round-trip mechanics, retry, and sibling routing. However, for a 7-parameter destructive asynchronous mutation it omits what decisions and execution_policy actually control and what gets modified in the saved plan — gaps an agent would need before committing.

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 only 43%, and the description never explains message, study_id, decisions (human vs agent), or execution_policy (review_before_fieldwork vs draft_only) — arguably the two most behavior-shaping parameters. Its only parameter-adjacent content, the concept_image note and the idempotency_key retry note, duplicates what the schema already states. Little compensation for the coverage gap.

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 first sentence names a specific verb and resource ('Queue one research-design turn') and immediately characterizes the operation as asynchronous, may-fetch-URL, external-model-backed. It also names the synchronous sibling customize_study and the exact condition that selects it (native concept images), so an agent can distinguish the two without opening either 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?

It gives concrete call sequencing: poll tasks/get if the client is a 2026 Tasks client, otherwise poll get_customize_study_job, then call get_study and surface the plan for human review. It also names the exclusion (native concept images go to customize_study). It stops short of stating outright when to prefer this async path over the synchronous one for ordinary requests, leaving that to inference from 'Queue'.

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