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

Annotations already provide openWorldHint and destructiveHint, but the description adds valuable behavioral context: same-document schema.org verification, no pattern guessing or SMTP probing, and a granular outcome/pricing structure (free for no-match, role mailbox, ambiguous, partial; paid only on published match). It does not mention side effects or return format, but given the annotations cover safety, this is acceptable. No contradiction with annotations.

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?

The description is concise and front-loaded with the core purpose. The first clause states the action, followed by verification method, exclusions, and pricing. Every sentence/clause earns its place, and there is no extraneous information. The pricing details are compact yet informative.

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?

The description covers the core behavior, verification method, exclusions, and pricing/outcome categories, which is comprehensive for a lookup tool. It does not describe the exact output structure, and since no output schema exists, this is a minor gap. However, the outcome categories (match, no-match, role mailbox, ambiguous, partial) imply what results may look like, making the description largely adequate.

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%, with each parameter (people, domain, fullName, inputRef, companyName, maxConcurrency, maxPagesPerPerson) fully documented. The description reinforces that emails must be published and schema.org-verified, but it does not add new parameter-specific details beyond what the schema already provides. Baseline 3 is appropriate when the schema carries the load.

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 clearly states the tool finds a named person's work email published on their own company website and verified by a same-document schema.org Person assertion. It explicitly excludes pattern guessing and SMTP probing, which sharply distinguishes it from alternative email-finding approaches. The verb 'find' and resource 'work email' are specific and unambiguous.

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?

The description provides strong usage context: it is for finding published, verified emails on a company website, and explicitly says it does not guess patterns or probe SMTP, so it should not be used when unverified or guessed emails are acceptable. The pricing model ('$0.01 only when a published match is found; no-match... are free') clarifies when the tool is cost-effective, effectively guiding usage decisions. However, it does not name any sibling tools as alternatives, so explicit alternatives are missing.

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