MisarReach MCP Server

verify_emails

DestructiveIdempotent

Check whether email addresses are deliverable before a send to protect sender reputation; validate one or up to 20 at a time and get a verdict per address.

Instructions

Check whether email addresses are deliverable, one or up to 20 at a time.

Run this before a send to protect sender reputation — bouncing a campaign off dead addresses is what gets a domain blocked. Pass either email for one or emails for a batch, not both.

CONSUMES VERIFICATION CREDITS per address checked, so a 20-address batch costs 20. Requires an API key. Returns a deliverability verdict per address; 'undeliverable' is a successful result, not an error. Nothing is sent to the addresses. Each verdict is saved onto any lead you hold with that address, replacing its previous verification status.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "verify_emails"
  }
}

Input Schema

Name	Required	Description	Default
`email`	No	Single email to verify (use this OR emails array)
`emails`	No	Batch of emails to verify (max 20)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Aug 4, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: credit consumption per address, an API key requirement, the fact that 'undeliverable' is a valid success outcome, that nothing is sent to the addresses, and that verdicts overwrite the previous verification status on stored leads. The overwrite disclosure is exactly the mutation side effect that destructiveHint=true implies, and it is consistent with the annotations.

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?

Front-loads purpose, then usage, then cost, then side effects and return semantics — a logical order with no filler. Every sentence carries a distinct, decision-relevant fact.

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?

Covers cost model, auth requirement, parameter exclusivity, return semantics ('deliverability verdict per address'), and the write side effect on stored leads, so the description stands in for the absent output schema. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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 the mutual-exclusivity rule ('Pass either email for one or emails for a batch, not both') and the 20-item batch ceiling that the schema only states on one property. That is genuine value beyond the structured fields.

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?

States a specific verb and resource ('Check whether email addresses are deliverable') and immediately scopes capacity ('one or up to 20 at a time'), which distinguishes it from the singular sibling verify_email. An agent can identify the operation without opening the schema.

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?

Gives an explicit when-to-use trigger ('Run this before a send to protect sender reputation') with the rationale for doing so. It does not name the sibling verify_email as the single-address alternative, leaving that routing inference to the agent, so it stops short of a 5.

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