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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond that: it specifies what the tool checks (DNS, SSL, SPF/DMARC), what it finds (cannot receive email, spoofable, expiring certs), and introduces a cost element ($0.01/call, x402/USDC) not visible in annotations or schema. This is more transparency than the baseline but stops short of discussing response format or potential external dependencies.

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 description is two sentences and front-loads the action: 'Bulk-audit domains' followed by specifics. Every clause carries information: checks performed, outcome use case, and cost. No fluff, no repetition of schema or title. It is concise and well-structured.

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?

Given the tool's moderate complexity and absence of an output schema, the description sufficiently conveys the primary use cases and expected findings (email reception, spoofing risk, certificate expiry). It also includes cost, which is relevant for an agent deciding to invoke it. It does not describe the exact output structure, but the core context is complete enough for an agent to select the tool correctly. Slightly more detail about result format would be needed for a 5.

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%, with both parameters ('domains' and 'maxConcurrency') already well-documented. The description does not add extra parameter syntax, format details, or examples beyond what the schema provides. It only loosely reinforces the 'domains' parameter by saying 'Bulk-audit domains.' Thus, the description adds no additional semantic value beyond the schema, meeting the baseline of 3.

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 uses the specific verb 'bulk-audit' and names the resource (domains) with concrete checks (DNS records, SSL expiry, SPF/DMARC). It clearly distinguishes itself from sibling tools by explaining its unique value proposition: finding domains that cannot receive email, are easy to spoof, or have expiring certificates. This is far beyond a vague purpose.

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 description implies when to use this tool: when auditing domains for email deliverability, spoofing risk, or certificate expiry, especially in a client-facing context ('before your clients do'). It does not explicitly mention alternatives or state 'when not to use,' but the use case is clear and distinct from the sibling context (e.g., Shopify monitoring, URL extraction). This is strong implied guidance but lacks explicit exclusion.

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