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

Annotations already cover read-only/idempotent/open-world/destructive, and the description adds genuinely useful context beyond them: a single plain-HTTP fetch with no browser rendering, the $0.25 per-call cost, and that accessibility signals are 'static' only. It stops short of noting rate limits or what happens if the site is unreachable.

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?

Purpose and capabilities are front-loaded effectively, but the long 'Returns:' enumeration restates field-by-field output that the output schema already provides, consuming roughly half the text without earning its place. Trimming the return listing would sharpen it considerably.

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 3-param aggregate tool with a full output schema, the description tells the agent everything needed to invoke it correctly and what it aggregates. Return-value explanation is redundant given the output schema, so completeness is high though not perfect.

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 coverage is 100% and the schema itself explains url, language and business_name in detail. The description restates only url and optional business_name and omits the language parameter entirely, so it adds no meaning beyond the schema; baseline 3 applies.

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 (qualify a business website as a sales lead) and enumerates exactly what is produced: SEO, security, accessibility, tech/tags, email, company profile and a 0-100 opportunity score. The 'in one call' framing and single plain-HTTP fetch clearly distinguish it from the granular audit_seo / audit_security / audit_wcag 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?

The sales-lead-qualification context and 'one call, plain HTTP, no browser' hint at when to reach for it over the separate audit tools, but the description never explicitly says when to use this vs. the audit_* or hubvibe_company_enrich siblings, nor states any exclusions. Usage is implied rather than guided.

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