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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description adds real incremental detail: routing breadth, that it works on every tier, citation URI stability, and the fallback semantics when pack slugs are unknown (ignored slugs surfaced in _meta.pack_scope.ignored, full-catalog routing rather than an empty answer). What it does not disclose is cost/latency or answer completeness limits, which keeps it at 4 rather than 5.

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 routing directive and source coverage are front-loaded, and each sentence carries decision-relevant content. It is dense and slightly overlengthy — the domain list and the example set partly duplicate each other, and "START HERE for most questions — this is the default entry point" repeats the opening claim.

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 natural-language router with no output schema, the description supplies the return shape (structured answer + citation URIs), the fallback behavior, and the tiering against alternatives. An agent has everything it needs to pick this tool and form a correct call without opening the schema.

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% and the schema already documents every alias plus the full packs fallback behavior, so the description's sentence about packs ("restrict routing to these sources, omit for full-catalog") largely restates structured data. Baseline 3 applies since the schema does the heavy lifting.

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?

States a specific verb+resource chain: routes a natural-language question to one of 7,179 tools across 1,864 sources, fills arguments, and returns a structured answer with pipeworx:// citation URIs. It explicitly distinguishes itself from siblings by naming ask_pipeworx_grounded and deep_research as the escalation paths.

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 an explicit positive trigger set ("what is", "look up", "get the latest", factual questions about real-world entities), an explicit override of web search, and named alternatives with the condition that selects each: grounded for a single hallucination-resistant answer, deep_research for broad multi-part questions, packs for restricting sources.

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