Check a list of up to 50 email addresses in one call, with the same checks as validate_email. Returns one result per address in the same order plus a summary of verdicts. Uses 1 check per address; addresses whose DNS lookup fails come back with reason dns_error and are not billed. If the key lacks checks for the whole list, nothing is checked or billed.
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers uncommon specifics: billing (1 check per address), non-billing on dns_error, order preservation, and the all-or-nothing behavior when the key lacks sufficient checks. It does not cover auth/permission prerequisites or any rate limit beyond the billing model, which keeps it short of a 5.
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?
Four dense sentences with zero filler; the scale-and-batch fact is front-loaded, followed by return shape, then cost behavior. Every sentence carries information an agent would otherwise have to guess.
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?
No output schema and no annotations, yet the description explains the return shape (one result per address in input order plus a verdict summary), an error reason value (dns_error), and billing outcomes. It leaves the possible verdict values and the summary's structure unspecified, which is a real gap given there is no output schema to fall back on.
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% and there is a single parameter, but the name 'emails' plus the stated cap of 50 makes the shape self-evident, and the description reinforces the documented bounds. It adds the semantics of ordering and per-item results but never states the expected string format, so it stops at 4.
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?
States a specific verb (check) and resource (a list of up to 50 email addresses in one call) and explicitly anchors itself to the sibling validate_email by inheriting its checks. An agent can immediately tell this apart from validate_email (single) and validate_phone (different resource).
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 batch framing ("up to 50 email addresses in one call") gives a clear condition for choosing this over the single-address sibling, and the key-lacks-checks note signals a failure case. It stops short of an explicit "use validate_email when you have one address, use this for many" routing statement, so it is context rather than a full when/when-not rule.
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.