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

The description adds context beyond the annotations: it discloses the batch size limit (100 domains), the credit cost model, and the add-on prerequisite ('Costs SEO add-on credits; top up → Add-ons'). This is meaningful operational context. It does not, however, reconcile or explain the destructiveHint=true / readOnlyHint=false annotation against what sounds like a read-only scoring call, leaving a mild gap.

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?

Five sentences, each carrying distinct information: what it does, threshold interpretation, use cases, batching benefit, and cost. Nothing is redundant; the most important details (score range, thresholds) are front-loaded.

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?

The context includes an output schema, so return structure need not be explained. The description covers purpose, timing, interpretation, batching behavior, and cost. It could be more complete by clarifying the refresh parameter and acknowledging the annotation semantics, but for a 2-param scoring tool it is substantially complete.

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%, so the description must compensate. It does document the domains parameter implicitly ('up to 100 domains in one call'), covering cardinality. The refresh boolean, however, is entirely undocumented in both schema and description, leaving half the parameters without meaning.

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 and resource ('Bulk spam score... Scores up to 100 domains in one call, 0 to 100, worst first'), clearly distinguishing it from single-domain lookups and from siblings like seo_backlinks or seo_referring_networks. The 'SEO Intelligence add-on' qualifier further scopes it.

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?

Explicit when-to-use guidance is given ('Built for the moment before you act: someone offers a guest post or a link package, or you are deciding which referring domains to disavow') plus threshold interpretation ('score above 30... above 60...'). It also contrasts the batching approach against one-lookup-per-domain alternatives.

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