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

Annotations supply the safety profile (readOnlyHint=false, openWorldHint=true), but the description adds genuinely useful behavior: results come from a historical provider database rather than a live model run, and domain vs keyword targets are resolved against different data (cited sources vs answer text). It does not explain cost, latency, or what 'preserve nullable evidence' means operationally, and it sits oddly against readOnlyHint=false for what reads as a pure retrieval.

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?

Four short sentences, but the opening sentence is jargon-dense and back-loaded with its qualifier ('without summing overlapping groups'), making the core action hard to parse on first read. No sentence is wasted, yet none is front-loaded as a plain statement of purpose.

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 and four parameters at 0% description coverage, the description should explain what a comparison result looks like (per-group metrics, aggregate, evidence gaps). It covers provenance and filter semantics instead, leaving the agent without a clear picture of inputs or outputs.

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 0% at the top level, so the description must compensate; it does partially by explaining that DOMAIN targets are matched against cited sources and KEYWORD targets against answer text, which clarifies the two target kinds. However, it says nothing about the groups array structure, the two-group minimum, market/language being fixed to US/en, or the google vs chat_gpt platform choice.

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 phrasing 'Independent target group metrics and provider union aggregate without summing overlapping groups' gestures at a comparison/aggregation over target groups, but it never states a clean verb+resource such as 'compare AI-visibility metrics across two or more target groups'. Nothing distinguishes it from the closely named sibling nexscope_seo_ai_target_metrics, so an agent must infer the difference.

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?

There is no when-to-use guidance, no prerequisites, and no named alternative (e.g. target_metrics for a single group vs this tool for multi-group comparison). The only constraint-like sentence, 'Preserve nullable evidence and unsupported dimensions', is about output handling, not about when to select this tool.

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