Hunter MCP

email_verifier

Read-only

Verify email deliverability and quality by checking SMTP/MX, accept-all, disposable, and webmail status, plus a risk score and source evidence.

Instructions

Verify one email address with Hunter v2 and return exact deliverability, score, SMTP/MX, accept-all, webmail, disposable, and source evidence.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "email": "<email>"
    },
    "name": "email_verifier"
  }
}

Input Schema

Name	Required	Description	Default
`email`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 8, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The annotations already communicate read-only behavior and an open-world result. The description adds value by disclosing the Hunter v2 backend and enumerating the exact evidence types returned, so the agent knows what kind of output to expect. No contradiction with the readOnlyHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The entire purpose and output contract are conveyed in a single front-loaded sentence with no filler. Every clause adds useful information for invoking the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter, read-only verification tool with no output schema, the description is complete: it states the input, the API, and the full list of verification dimensions returned. Nothing essential is missing for correct selection or invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only one required parameter and no description in the schema, the description's 'one email address' maps cleanly to the email parameter. However, it adds no additional semantics beyond the schema's format/pattern constraints; the schema is left to carry most of the parameter documentation burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Verify'), a precise resource ('one email address'), and names the exact API version and result fields (deliverability, score, SMTP/MX, accept-all, webmail, disposable, source evidence). This clearly separates it from sibling tools like email_finder, which find addresses rather than verify a known one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It establishes clear context: use this when you already have a single email address and need verification results. It does not explicitly enumerate when-not-to-use or name email_finder as an alternative, but the single-address scope makes the intended invocation obvious.

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

Deploy Server