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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: it names the engines queried by default, the return shape, and how to interpret engine_count. It does not discuss latency, rate limits, or cost of fanning out across engines, which would fully round it out.

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?

Three sentences, front-loaded with the core action and output shape, with the engine_count interpretation placed last as a useful reading aid. No filler sentences, though the trailing interpretation sentence slightly overlaps with output-schema territory.

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 read-only, idempotent fan-out tool with annotations covering safety, 100% schema coverage, and an output schema already present, the description is essentially complete. It even voluntarily explains return values despite the output schema existing, which covers the remaining ambiguity.

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 all three parameters (query, engines, max_results) are already documented in the schema with strong detail (enum list, maxItems, defaults, defaults-on-omission). The description adds nothing parameter-specific, so the baseline 3 for high coverage is correct.

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 action (fan a query out across multiple AI engines) and resource (per-URL cross-engine citation consensus), and goes further to name the exact outputs (per-URL engine lists, consensus_urls). This is specific enough to distinguish it from sibling tools like citations_evidence or citations_check that lack the multi-engine consensus angle.

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 is implied rather than stated: the description explains engine_count semantics (1 = engine-specific, high = strong signal), which hints at when the tool is valuable, but it never names an alternative or states an explicit when/when-not condition against siblings like citations_evidence. No exclusions or routing guidance.

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