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

With no annotations at all, the description carries the full burden and does it well: it discloses the exact output surface, HTTP/HTTPS behavior, that private/internal targets return 400, and — unusually — the cost and payment rail ($0.009 USDC on Base or Solana via x402). Cost, payment mechanism and error semantics are exactly the behavioral traits an agent needs before calling a paid endpoint, and none of it is derivable from the schema.

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?

One dense paragraph, but it is deliberately ordered: trigger, input, output, example, price. The output enumeration is long yet every item earns its place because the agent needs to know this single call replaces several. The trailing price sentence is arguably its own concern but is front-adjacent enough to remain useful.

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 a one-parameter schema, no output schema and no annotations, the description must supply everything, and it effectively does: the agent knows the trigger, the accepted input form, the failure mode, the full response shape and the cost. Nothing required to decide whether and how to call it is missing.

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% for the single parameter, and the description's 'url or bare domain' plus the example '?url=stripe.com' largely restate what the schema already documents, including the https:// assumption. No added semantics such as length limits, encoding requirements or IDN handling, so this sits at the mandated 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 states a specific verb-and-resource pair ('vet or research a website in one call') and enumerates the resource surface precisely: page metadata, HTTP status, HTTPS/redirect, security headers, robots.txt/llms.txt, DNS, mail auth, RDAP. That is far more specific than a title restatement. However it never names or differentiates from the obvious siblings web_metadata and domain_lookup, so the agent has to infer the overlap boundary itself.

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?

It gives concrete when-to-use triggers ('lead research, security or SEO check, is this site legit'), which is stronger than implied usage. It stops short of a full 5 because there are no exclusions or alternatives named, despite two sibling tools who would be candidates for a narrower version of the same task.

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