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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, and the description adds substantial behavioral detail beyond those: account/paid-tier requirements, parallel decomposition, explicit gaps[] rather than invented answers, contradictions[] behavior, citation_uri resolvability conditions, semantic excerpting, and expected latency. No contradiction with annotations is present.

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 dense but mostly earns its length given the tool's complexity and the lack of an output schema. There is minor redundancy around citations and findings packet details, but the key decision-relevant facts are front-loaded and clearly organized.

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?

With no output schema, the description carries the burden of explaining the return value, and it does so thoroughly: findings packet contents, confidence/source/fetched_at, citations, gaps[], contradictions[], hop field, and timing. It also covers account prerequisites, depth semantics, and fallback routing, making the tool fully usable by an agent.

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 100%, so the schema already fully documents both parameters. The description reinforces the depth meanings and adds timing and hop behavior, but it does not introduce parameter syntax or format details that the schema lacks. Baseline 3 is appropriate.

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 the resource ('structured data sources'), the action ('multi-source research', 'decomposes', 'routes in parallel'), and explicitly distinguishes itself from open-web search and from ask_pipeworx. It also gives concrete examples of the questions it is best for, so an agent can clearly tell this tool apart from siblings.

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?

Usage guidance is explicit: broad/multi-part structured-data questions are preferred, single lookups should use ask_pipeworx, and unsigned-in users should use ask_pipeworx. It also tells the agent when not to expect good results, such as current-news topics outside the structured catalog, and explains the depth tiers' strategic differences.

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