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

Adds substantial context beyond annotations: non-cancelling wait semantics, durable job reuse across polls, retry guidance after a timeout (same idempotency_key and prompt), sync/async sharing the job, and parent_job_id for follow-ups in the same session. The idempotentHint=false annotation sits slightly at odds with the retry-key advice, but the description explains the dedupe mechanism rather than contradicting it. Minor gap: wait_seconds timeout behavior is not discussed.

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?

The core behavior is front-loaded, which is good, but the body is a dense run-on of semicolon-chained workflow rules (~140 words) mixing routing, session setup, polling, and answer rendering. Most sentences carry operational value, yet the packing makes it hard to scan and would benefit from tighter grouping.

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 complex async job tool with an output schema (so return values need no explanation) and low schema coverage, the description covers the end-to-end lifecycle: session setup, submission, polling, retry, and mandatory follow-up rendering. Only wait_seconds behavior and two auxiliary parameters remain undocumented.

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 14%, so the description must carry the load. It explains session_id (reuse selected Hub session, create if absent), idempotency_key (stable retry key, reuse after timeout), prompt (reuse the same prompt), and parent_job_id (follow-up in same session). But wait_seconds, organization_id, and include_synthetic get nothing, so compensation is only partial.

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 opening sentence states a specific behavior: wait for a chat answer, and if still running return the same durable job without cancelling it. This distinguishes it from queue_research_chat (enqueue) and view_research_answer (render), though the actual verb/resource framing is buried under workflow instructions rather than stated crisply up front.

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?

Explicit routing is present: use it for 'study findings, feedback, comparisons and quotations', resolve ambiguous study names first, reuse the selected Hub session or create one with create_research_session, and always follow with view_research_answer. It also names negative behavior ('Do not resync unchanged sources or broaden the session silently') and gives the alternative polling tool (inspect_research_session view=job).

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