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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description still adds substantial context beyond them: an account prerequisite and paid tier for depth:"thorough", expected latency (15–60s, ~90s for thorough), hop semantics, gaps[] never invented, and citation resolvability guarantees. The main gap is that the highest-value operational fact — you must be signed in or the call fails — is buried in the opening parenthetical rather than framed as a precondition. The "NOT open-web search" line sits in tension with openWorldHint=true, though it reads as a clarification of data provenance rather than 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?

Front-loaded with the blocking prerequisite and the fallback, then purpose, then alternatives, then mechanics — a sensible order. It is dense rather than padded, but the ask_pipeworx routing advice appears twice (opening fallback and the "single lookup" sentence), and the latency figure is stranded at the end where an agent skimming the first line may miss it.

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 exists, so the description carries the full burden of describing returns — and it does: findings packet structure (verbatim evidence, confidence, source, fetched_at, pipeworx:// citation), hop field, gaps[], contradictions[]. For a 9-parameter, multi-hop tool with a tier gate, nothing essential to correct invocation is missing.

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 coverage is 100% and the depth enum is already documented in the schema, so baseline would be 3. The description earns an extra point by adding the paid-plan constraint on "thorough" and by explaining the iteration model (standard = gap recovery, thorough = lead chasing) in outcome terms rather than enum terms. The seven alias parameters receive no mention, but they are self-documenting as "Alias for question."

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?

Specific verb and resource with explicit scope: multi-source research across 1,853 structured sources, decomposed into facets routed to 7,044 tools in parallel. It also preempts the most likely misread ("this is NOT open-web search") and names the sibling it is not (ask_pipeworx). An agent can distinguish it from ask_pipeworx, bet_research, and research_row 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?

Gives explicit when-to-use (broad/multi-part questions over structured data, with two concrete example phrasings) and two explicit when-not cases with the named alternative: single lookup → ask_pipeworx, breaking/colloquial news → ask_pipeworx because deep_research returns empty gaps[]. It even states the failure mode that should redirect the agent.

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