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

Annotations already establish readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real value: robots-respecting, public hosts only, cost charged per page actually fetched with failed fetches free, and no URL logging. The only tension is that a tool that fetches arbitrary external URLs is labelled openWorldHint=false, which the description's 'GET the URL' quietly undercuts.

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, usage and cost are front-loaded and useful, but the long response enumeration (emails[], phones[], whatsapp[], social, addresses, organization, pages, summary, confidence, sources, version, warnings, disclaimer) is verbose and largely redundant when an output schema already exists — and it lists fields that don't obviously belong to a reachability check.

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 an output schema present the description needn't detail return values, and it covers the operational essentials an agent needs: cost model, robots/public-host constraints, and privacy. It omits error and failure semantics — what a non-200 or unreachable host looks like in the response.

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 carries the burden. It explains the url parameter only via an example and gestures at respect_robots through 'robots-respecting', but never states what setting respect_robots to false would do, or what happens on a robots disallow. Partial compensation, not full.

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 opening sentence names a specific verb (GET) and resource (the URL) and enumerates exactly what it returns: status, final URL after redirects, content type, title, languages, contact-page linkage. That is much sharper than the title alone. It never explicitly distinguishes itself from extract_contacts or find_social_profiles, and the later response block oddly lists emails/phones/whatsapp, which blurs whether this is also a contact extractor.

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?

"Use before a bulk job or to clean a URL list" gives concrete situations for calling it, and the example 'example.com' illustrates the input shape. It stops short of naming the alternative sibling tools or saying when NOT to call it (e.g. when you already have a URL list of failed fetches to re-run).

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