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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the description is free to add what annotations cannot: cost model, privacy ("URLs are not logged"), and the confidence/warnings/disclaimer envelope in the response. The pricing sentence appears copied from a fetching sibling and arguably contradicts the tool's own no-fetch premise, which blunts an otherwise strong disclosure.

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 well with the key differentiator, and the input example and cost note earn their place. However, the long comma-spliced enumeration of every response field (result, emails[], phones[], whatsapp[], social{}, addresses[], organization{}, pages[], summary{}, data_confidence, estimated_items[], sources[], data_version, warnings[], disclaimer) duplicates the output schema and makes for a wall of text.

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-parameter, well-annotated tool with an output schema, the description covers purpose, input caveat, cost and privacy adequately. The only real gap is the internally inconsistent per-page charging language, which could lead an agent to avoid a free operation on cost grounds.

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%, so html, region and base_url are already fully documented with defaults and examples; baseline is 3. The description never mentions region (phone-number interpretation) or base_url (relative-link resolution), so it adds nothing over the schema.

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?

"Same parser, no fetching" plus an explicit enumeration of extracted data types (emails incl. obfuscated forms, phones, WhatsApp, social, addresses, schema.org org data, contact-page links) makes the verb and resource unambiguous. It implicitly contrasts with the fetching siblings (extract_contacts, check_url), so an agent can tell it doesn't touch the network without opening the schema.

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?

"No fetching" and "You already have" (title) clearly establish the precondition for choosing this over extract_contacts. It lacks an explicit "use extract_contacts when you have a URL instead" routing sentence, and the later line "Charged per page actually fetched; failed fetches are free" muddies the when-to-use story for a tool that fetches nothing.

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