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

With no annotations, the description carries the full load and does well: it discloses the payment rail and cost (x402 on Base, $0.02/call), the request body format, and even a negative capability ('contrast not measured') that prevents false expectations. It stops short of stating wallet/auth prerequisites or response time for a multi-check operation.

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?

Front-loaded with the purpose, then the check inventory, then cost — a sensible order for an agent. The long enumeration in the first sentence is dense but every item is a distinct capability; nothing is padding.

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 complex multi-check tool with no output schema and no annotations, the description supplies output shape (section scores, overall 0-100, top 10 fixes), cost, and input format. Remaining gaps are latency, rate limits, and payment prerequisites, which matter but are secondary to correct invocation.

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 single 'url' parameter is already documented as accepting a URL or plain hostname, so the schema does the heavy lifting. The description's 'Body {"url":"https://..."}' restates the schema example without adding accepted hostname forms or validation behavior beyond it.

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 and resource ('One-call website report for a URL') and then enumerates exactly which checks the bundle covers: on-page SEO, accessibility items, security headers, TLS, email anti-spoofing, RDAP. The enumeration inherently separates it from the narrow siblings like domainaudit_seo or domainaudit_tls without needing to name them.

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 only implied: the phrase 'One-call website report' plus the price hint at when the bundle is preferable to single checks, but there is no explicit 'use this when you need everything; use domainaudit_headers for headers only' guidance. The $0.02 price is the only decision aid offered, and no sibling prices are referenced for comparison.

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