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

Annotations already cover read-only, open-world, and idempotent hints, which the description complements rather than contradicts. The description adds substantial behavioral context: the tool decomposes questions into facets and routes them in parallel, returns explicit gaps[] for unanswered facets, never invents findings, does gap-recovery hops, detects contradictions, semantically excerpts rather than head-truncates large records, and has stated latency expectations (15-60s, ~90s for thorough). It also explains that citation_uri is present only when fetchable, preventing false expectations.

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 description is long and dense, but nearly every sentence earns its place: account requirements, alternatives, scope, internal mechanics, return format, semantics of depth levels, citation behavior, and latency. It is front-loaded with the gating constraint (ACCOUNT REQUIRED) before anything else. It loses one point for general density and unanswered logical structure: the parenthetical 'depth:"thorough" needs a paid plan' interrupts and becomes slightly tangled given the later full explanation of depth levels.

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, costly tool with two parameters, auth requirements, and no output schema, the description covers the essentials: what type of question it serves, what the results look like, what will be missing (gaps[]), how citations work, how long it takes, and how depth affects behavior. Nothing an agent needs to decide whether to call or select a depth value is missing; the absence of an output schema is compensated by the detailed findings-packet description.

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%, so the schema already documents both parameters in detail. The description adds value by explaining the behavioral meaning of depth values ('quick=3', 'standard=3 (default; adds gap-recovery hop...)', 'thorough=6 (paid; adds iterative hop...)') and reinforces that the question parameter accepts broad/multi-part natural language. Since the schema already covers the syntax and the description complements it with usage semantics, a 4 is appropriate; the only extra would be examples of multi-part question formatting.

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 states a specific verb ('research') and resource (1500 structured data sources via 5,743 tools), and distinguishes itself from open-web search and from ask_pipeworx. It clearly defines what the tool returns: a findings packet with verbatim evidence, confidence, source, citations, and gaps. The example question patterns make its purpose concrete and the 'NOT open-web search' warning sharpens its identity.

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 description explicitly says when to use it ('broad/multi-part questions over structured data'), when NOT to use it ('single lookup' — use ask_pipeworx; 'BREAKING/CURRENT-NEWS' topics — prefer ask_pipeworx), and accounts for auth tiers ('ACCOUNT REQUIRED... If you are not signed in, use ask_pipeworx'). It also explains depth-level selection and what to expect from each tier, so an agent gets clear routing guidance without opening the schema.

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