Validate and verify email addresses for deliverability, format compliance, and mailbox existence. Returns pass/fail status per email, syntax errors, domain validity, and SMTP verification result. Use before sending bulk emails to prevent bounces and protect sender reputation.
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | Array of email addresses to validate for syntax, domain, and deliverability |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds behavioral detail about return values (pass/fail status, syntax errors, domain validity, SMTP result) and the checks performed (deliverability, mailbox existence), which goes beyond annotations. No contradictions 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?
Two sentences: first defines actions and outputs, second gives usage guidance. No redundant content, front-loaded with the verb 'Validate and verify'. Highly concise and well-structured.
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?
Given the simple single-parameter schema, clear annotations, and no output schema, the description adequately explains the tool's behavior, return values, and intended use case. Nothing essential is missing for an agent to select and invoke it correctly.
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 covers the single 'emails' parameter thoroughly with type, format examples, and description (100% coverage). The tool description reinforces the parameter purpose but adds no additional semantic detail beyond the schema, so baseline 3 applies.
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 identifies the tool as validating and verifying email addresses, with specific outcomes like syntax errors, domain validity, and SMTP verification. This distinguishes it from sibling tools (generate_leads and search_local_businesses) which serve different purposes.
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 explicit usage context: 'Use before sending bulk emails to prevent bounces and protect sender reputation.' This clearly indicates when to use, though it does not mention exclusions or alternative tools, so it lacks the full when/when-not structure for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct purpose: lead generation, local search, and email validation. However, the inclusion of email validation alongside Google Maps tools may cause confusion about the server's core domain, but the tools themselves are easily distinguishable.
All tool names follow a consistent verb_noun pattern (generate_leads, search_local_businesses, validate_emails), using underscores and clear action-object pairs.
With only 3 tools, the server feels thin for a domain as broad as Google Maps and local business. The count is borderline but not extreme, especially given the inclusion of an unrelated email validation tool.
The server provides only two local business tools (search and lead generation), missing essential operations like getting detailed business info, directions, reviews, or location queries. The email validation tool is out of scope and does not fill any obvious gap in the local business domain.