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

Goes well beyond the annotations: it discloses the free-then-one-paid-lookup flow, the monthly finder budget gate, one-site-at-a-time ~4-minute execution, 'not_started' for unreached sites, that nothing is sent, and the exact guarded approval flow including the {error:'approval_required', approval_token, summary} shape and the re-call requirement.

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?

Dense and front-loaded, with the core action stated first and guardrails after. Given the tool's complexity the length is largely justified, though the closing 'Every dashboard guardrail still applies... no more' restates earlier points and is mildly redundant.

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 no output schema, the description carries the burden and does so: it explains results (addresses and contact name saved on the site), partial-completion semantics (not_started), spend limits, and the approval handshake error payload. Nothing essential for correct invocation 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 coverage is 100%, so the baseline is 3, but the description adds real meaning about the approval_token round-trip and the site_ids skip/budget behavior that the schema alone doesn't convey. It doesn't add new detail on site_ids beyond the schema's 'up to 25'.

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 opens with a specific verb+resource+scope: 'Find a contact email for up to 25 sites,' and anchors it to a known UI action ('as the Websites Find email button does'). It is clearly distinguishable from siblings like set_website_contact (manual entry), reveal_contact, and list_websites.

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 strong context: when contacts already exist the site is skipped, the free chain runs before the paid lookup, and budget must have room. It stops short of naming sibling alternatives (e.g., reveal_contact or set_website_contact) for when the agent should prefer manual entry instead.

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