The @deliveriq/mcp server provides 12 tools for email deliverability verification and domain intelligence via the DeliverIQ API.
Verification Tools:
Verify a single email: Check deliverability with reachability status, 0–100 score, syntax/MX/SMTP/disposable/role-based checks, and optional HIBP breach detection
Submit batch verification: Asynchronously verify up to 10,000 emails with optional webhook callbacks
Check batch job status: Poll progress of a running batch verification job
Download batch results: Retrieve completed results as CSV, with optional filtering by category (safe/risky/invalid/unknown)
List verification jobs: Browse and filter past batch jobs with pagination
Intelligence Tools:
Find business email: Discover a person's work email by name and company domain using pattern generation and SMTP probing
DNSBL blacklist check: Check a domain's IP against 50 DNS-based blackhole list zones
Email infrastructure check: Analyze SPF, DKIM, DMARC, MTA-STS, BIMI, and TLS-RPT records with an infrastructure score
Spam trap analysis: Evaluate an email address for spam trap risk using 13 signals (domain age, entropy, disposability, etc.)
Domain intelligence: Get a full domain trust report covering MX records, DNSBL status, infrastructure, domain age, and ISP profile
Organization intelligence: Query email patterns, verified contact counts, and company info for a domain (free)
Account Tool:
Check credits: View remaining credit balance, plan tier, billing period, and usage breakdown by category (free)
Official MCP (Model Context Protocol) server for the DeliverIQ email verification API by MiN8T. Provides 12 tools for AI agents in Claude Desktop, Claude Code, Cursor, and any other MCP-compatible client.
No separate install step needed — npx -y @deliveriq/mcp will fetch and run
the server on demand.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json
(macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"deliveriq": {
"command": "npx",
"args": ["-y", "@deliveriq/mcp"],
"env": {
"DELIVERIQ_API_KEY": "lc_your_api_key"
}
}
}
}Restart Claude Desktop. You should see the 12 DeliverIQ tools available.
claude mcp add deliveriq npx -y @deliveriq/mcp \
-e DELIVERIQ_API_KEY=lc_your_api_keyAdd to .cursor/mcp.json:
{
"mcpServers": {
"deliveriq": {
"command": "npx",
"args": ["-y", "@deliveriq/mcp"],
"env": {
"DELIVERIQ_API_KEY": "lc_your_api_key"
}
}
}
}Sign up at min8t.com/deliveriq and grab a
key from your dashboard. The free tier covers the demo flow plus ongoing
low-volume use. Keys are issued in the format lc_prefix_secret.
Related MCP server: Mailchimp MCP
Variable | Required | Description |
| Yes | API key (format: |
| No | Override API URL (default: |
Tool | Description | Credits |
| Verify a single email for deliverability | 1 |
| Submit batch of emails for async verification | 1/email |
| Check batch job status and progress | Free |
| Download completed batch results as CSV | Free |
| List verification jobs with pagination | Free |
Tool | Description | Credits |
| Find business email by name + domain | 2 |
| Check domain against 50 DNSBL zones | 1 |
| Analyze SPF/DKIM/DMARC/MTA-STS/BIMI | 1 |
| Evaluate spam trap risk (13 signals) | 1 |
| Comprehensive domain trust report | 1 |
| Query organization email patterns | Free |
Tool | Description | Credits |
| Check credit balance and usage stats | Free |
Email deliverability is one of those problems where the right answer needs 6–8 API calls (verify → reputation → DMARC → blocklist → infrastructure → ...). Letting Claude orchestrate these as tools is ~10× more useful than shipping another dashboard — the model can plan, branch on results, and explain the verdict in plain English.
# Clone the monorepo
git clone https://github.com/Davison-Francis/min8t-sdks.git
cd min8t-sdks/deliveriq-mcp
# Install + build
npm install
npm run build
# Watch mode
npm run dev
# Run directly against the published API
DELIVERIQ_API_KEY=lc_your_key node dist/index.js
# Or against a local DeliverIQ service
DELIVERIQ_API_KEY=lc_test \
DELIVERIQ_BASE_URL=http://localhost:3019/api/v1 \
node dist/index.jsNode.js 18+
DeliverIQ API key
See ../ROADMAP.md for upcoming work, or open an issue to
propose a tool.
MIT — see LICENSE.
Download the results of a completed batch verification job as CSV.
Args:
job_id (string): The completed job ID
category (string, optional): Filter to "safe", "risky", "invalid", or "unknown" only
Returns: CSV text with verification results. Large results may be truncated.
Examples:
"Download results for job abc123" -> { job_id: "abc123" }
"Get only safe emails from job abc123" -> { job_id: "abc123", category: "safe" }
Credit cost: Free
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Batch job ID to download results for | |
| category | No | Filter results to a specific category (omit to get full CSV) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent, non-destructive, read-only. Description adds credit cost and truncation warning for large results, which are valuable beyond 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?
Front-loaded with purpose, then structured sections (Args, Returns, Examples, Credit cost). No unnecessary words. Efficient and scannable.
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?
Covers purpose, parameters, return value (CSV), truncation behavior, examples, and cost. No output schema, so description adequately fills gaps.
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 coverage is 100%, so baseline is 3. Description examples clarify usage but mostly restate schema info (e.g., enum values). Adds no new syntax or format details.
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?
Clearly states the verb ('download') and resource ('batch verification job results as CSV'). The title 'Download Batch Results' reinforces this. Distinguishes from siblings like 'deliveriq_batch_status' and 'deliveriq_batch_verify'.
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?
Implies job must be completed before downloading. Provides filter options. However, does not explicitly state when not to use (e.g., if job is incomplete) or compare to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status and progress of a batch verification job.
Args:
job_id (string): The job ID from deliveriq_batch_verify
Returns: Job status, progress percentage, and summary when complete.
Examples:
"Check job abc123" -> { job_id: "abc123" }
Credit cost: Free
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Batch job ID returned by deliveriq_batch_verify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, non-destructive, idempotent, and open world. The description adds details about returning progress and summary when complete, which is consistent and slightly extends beyond 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 well-structured with separate sections for args, returns, and examples. While slightly verbose, every part serves a purpose and is front-loaded.
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?
For a simple status-check tool with 1 parameter and no output schema, the description covers all essential aspects: purpose, input, output, and cost. It is fully 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 coverage is 100%, and the description adds value by explaining the parameter's origin (from deliveriq_batch_verify) and providing an example usage, which aids understanding.
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 it checks the status of a batch verification job, using a specific verb ('Check') and resource ('batch job status'). It is distinct from siblings like deliveriq_batch_verify and deliveriq_batch_download.
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 specifies that the job ID comes from deliveriq_batch_verify, implying a clear usage context. It does not explicitly mention when not to use it, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a batch of email addresses for asynchronous verification. Returns a job ID for tracking.
Use deliveriq_batch_status to poll progress, and deliveriq_batch_download to get results when complete.
Args:
emails (string[]): Array of 1-10,000 email addresses
skip_smtp (boolean): Skip SMTP verification (default: false)
callback_url (string, optional): Webhook URL for batch.completed/batch.failed events
Returns: Job ID, status, estimated completion time, and status polling URL.
Examples:
"Verify these 3 emails" -> { emails: ["a@ex.com", "b@ex.com", "c@ex.com"] }
"Batch verify with webhook" -> { emails: [...], callback_url: "https://my-app.com/webhook" }
Credit cost: 1 credit per email
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | Array of email addresses to verify (1-10,000) | |
| skip_smtp | No | Skip SMTP verification for all emails | |
| callback_url | No | Webhook URL to receive batch.completed or batch.failed event |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses async behavior, job ID return, polling URL, and webhook events (batch.completed/batch.failed). Annotations indicate non-readonly, non-destructive, non-idempotent, open world; description aligns and adds valuable context beyond 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?
Well-structured with clear sections (purpose, usage, args, returns, examples, cost). Each sentence is informative without redundancy. Concise yet comprehensive.
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?
For a 3-param tool with no output schema, description covers return fields (Job ID, status, etc.), credit cost, async flow, and webhook integration. Contextually complete for an agent to select and invoke 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?
With 100% schema coverage, baseline is 3, but description adds: email array range (1-10,000), skip_smtp default false, callback_url webhook events, and illustrative examples. This adds significant meaning beyond the schema.
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 action (submit), resource (batch of email addresses), and purpose (asynchronous verification) with the verb 'Submit'. It distinguishes from sibling tools by mentioning tracking via job ID and referencing polling and download tools.
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?
Explicitly instructs to use deliveriq_batch_status for polling and deliveriq_batch_download for results, providing clear when-to-use guidance. Also mentions credit cost per email for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a domain's IP against 50 DNSBL (DNS-based Blackhole List) zones across 6 categories: spam, proxy, dynamic, domain reputation, backscatter, and general.
Args:
domain (string): Domain to check (e.g. "example.com")
Returns: Listed/clean status, number of hits, and details per zone.
Examples:
"Is example.com blacklisted?" -> { domain: "example.com" }
Credit cost: 1 credit
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to check against 50 DNSBL zones (e.g. "example.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing the output (listed/clean status, number of hits, per-zone details) and credit cost. Annotations include idempotentHint=true, which aligns with a read-heavy check. No contradictions; however, it could disclose that results vary over time (openWorldHint is true but not explained).
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, well-structured with Args/Returns/Examples/Credit cost sections, and uses minimal sentences. Every sentence adds value, and the information is front-loaded.
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 tool's simplicity (1 parameter, no output schema), the description covers essential aspects: purpose, parameters, return format, and cost. It is complete for typical usage, though it could mention that results are based on current DNSBL statuses and may change.
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?
The input schema has 100% coverage for the single 'domain' parameter, including a clear description. The description adds an example but does not provide additional semantic context beyond what the schema already offers. Baseline score of 3 is appropriate.
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 it checks a domain's IP against 50 DNSBL zones across 6 categories, using a specific verb and resource. The tool name and title are reinforced, and it distinguishes itself from sibling tools like deliveriq_domain_intel by focusing solely on blacklist status.
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 clear context and an example, but does not explicitly state when not to use this tool or mention alternatives. For instance, it could contrast with deliveriq_infrastructure_check for broader IP reputation checks. However, the purpose is evident, and the example helps guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check current credit balance, usage breakdown, and plan information. Use this before performing credit-consuming operations to verify sufficient balance.
Returns: Remaining credits, plan tier, billing period, and usage breakdown by category (single, batch, ESP sync).
Examples:
"How many credits do I have left?" -> {}
"What's my usage this month?" -> {}
Credit cost: Free
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, and open-world behavior. The description adds value with 'Credit cost: Free' and details about return fields (remaining credits, plan tier, billing period, usage breakdown). No contradictions.
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?
Description is concise but slightly unstructured, mixing usage hint, return info, and examples in a paragraph. Could be more organized, but no wasted sentences.
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?
Despite having no output schema, the description covers purpose, usage context, return contents, examples, and cost. For a simple read-only tool, this is fully complete.
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?
Input schema has zero parameters, and schema description coverage is 100%. Baseline is 3 per guidelines. Description does not add parameter semantics since none exist.
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 checks credit balance, usage breakdown, and plan information. It distinguishes itself from sibling tools by focusing on credits, with no overlap in functionality.
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?
Explicitly states 'Use this before performing credit-consuming operations to verify sufficient balance.' Provides clear context, though no exclusions or alternatives are mentioned since no sibling tool offers credit info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive intelligence report for a domain including MX records, DNSBL status, email infrastructure (SPF/DKIM/DMARC), domain age, ISP profile, and trust score.
This is a combined report — if you only need one aspect, use the more specific tools (deliveriq_blacklist_check, deliveriq_infrastructure_check) instead.
Args:
domain (string): Domain to analyze (e.g. "example.com")
Returns: Complete domain intelligence report with trust score.
Examples:
"Full report on example.com" -> { domain: "example.com" }
Credit cost: 1 credit (heavy rate limit: 10 req/min)
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain for comprehensive intelligence report (e.g. "example.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint and openWorldHint. The description adds valuable behavioral info: credit cost (1 credit) and rate limit (10 req/min), which are not in annotations. It does not contradict 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 well-structured and concise: purpose statement, usage guidance, args/returns/examples, and cost/rate limit. Every sentence adds value with no fluff.
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 no output schema, the description adequately lists the return components (MX, DNSBL, etc.) and trust score. It also includes credit cost and rate limit. Minor missing specifics about trust score format, but overall complete for its complexity.
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 coverage is 100%, and the description repeats the parameter 'domain' without adding new semantic meaning beyond the schema. Baseline 3 is appropriate.
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 provides a comprehensive intelligence report for a domain and lists specific components (MX, DNSBL, SPF, DKIM, DMARC, etc.). It distinguishes itself from sibling tools by noting it is a combined report and directs users to more specific tools if needed.
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?
Explicitly states when to use this tool (for a combined report) and when to use alternatives (specific tools like deliveriq_blacklist_check or deliveriq_infrastructure_check for single aspects). This provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a person's business email address by name and company domain. Uses pattern generation, SMTP probing, corroboration from public sources, and org intelligence.
Args:
first_name (string): Person's first name
last_name (string): Person's last name
domain (string, optional): Company domain (e.g. "acme.com"). Required if company_name is not set
middle_name (string, optional): Middle name for disambiguation
company_name (string, optional): Company name, used to resolve domain if domain is not provided
Returns: Found email address, confidence score and label, verification method, and domain context.
Examples:
"Find John Doe at acme.com" -> { first_name: "John", last_name: "Doe", domain: "acme.com" }
"Find Jane Smith at Globex Corp" -> { first_name: "Jane", last_name: "Smith", company_name: "Globex Corp" }
Credit cost: 2 credits per lookup
| Name | Required | Description | Default |
|---|---|---|---|
| first_name | Yes | First name of the person (e.g. "John") | |
| last_name | Yes | Last name of the person (e.g. "Doe") | |
| domain | No | Company domain (e.g. "acme.com"). Required if company_name is not provided | |
| middle_name | No | Middle name (improves accuracy for common names) | |
| company_name | No | Company name (e.g. "Acme Corp"). Used if domain is not provided |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations, such as credit cost and the use of methods like pattern generation and SMTP probing. However, it does not fully disclose side effects or rate limits, and annotations indicate it is not read-only (readOnlyHint=false) which aligns with credit consumption. The description is adequate but could be more thorough.
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 well-structured with clear sections for arguments, returns, examples, and credit cost. It is concise but not overly terse. Each part serves a purpose, though some minor redundancy exists (e.g., repeating parameter details already in schema).
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 tool's simplicity and the absence of an output schema, the description fully explains what the tool returns (email, confidence score, verification method, domain context) and covers credit cost. There are no apparent gaps in information needed to use the tool 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 description coverage is 100%, so parameters are already documented in the schema. The description adds value by explaining the mutual exclusivity of domain and company_name, and provides usage examples that clarify how to use the parameters. This goes beyond a baseline of 3.
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's purpose: 'Find a person's business email address by name and company domain.' It uses a specific verb-resource combination and distinguishes from siblings like deliveriq_verify_email (which verifies an existing email) by focusing on discovery. The purpose is 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 clear usage guidance through examples and by explaining the two ways to specify the target (domain or company_name). It implicitly distinguishes from the sibling verification tool, but does not explicitly state when not to use or provide alternative tools. This is good but not perfect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a domain's email infrastructure: SPF, DKIM, DMARC, MTA-STS, BIMI, TLS-RPT records and MX configuration.
Args:
domain (string): Domain to analyze (e.g. "example.com")
Returns: Infrastructure score (0-100) and detailed analysis of each protocol.
Examples:
"Check example.com email setup" -> { domain: "example.com" }
Credit cost: 1 credit
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to analyze for SPF, DKIM, DMARC, MTA-STS, BIMI, and TLS-RPT (e.g. "example.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (idempotentHint=true, destructiveHint=false) indicate safety, and the description adds that it returns a score and detailed analysis. No contradictions; the credit cost is also mentioned. However, the readOnlyHint=false is somewhat inconsistent with the read-only nature of analysis.
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 three short, well-structured lines: purpose line, Args, Returns with example and credit cost. Every sentence adds value, with no redundancy.
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 single parameter, clear return description (score and detailed analysis), and no output schema, the description is complete enough for an agent to understand what the tool does and what it returns.
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 coverage is 100% with a detailed description for the 'domain' parameter. The tool description repeats this with an example, adding no new meaning beyond the schema.
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 explicitly states the action as 'Analyze a domain's email infrastructure' and lists specific protocols (SPF, DKIM, DMARC, etc.), clearly distinguishing it from sibling tools like deliveriq_verify_email and deliveriq_blacklist_check.
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 examples but does not explicitly state when to use this tool versus siblings or give exclusion criteria. Usage context is implied through the analysis focus, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List batch verification jobs with pagination and optional status filter.
Args:
page (number): Page number (default: 1)
limit (number): Results per page (default: 20, max: 100)
status (string, optional): Filter by "pending", "processing", "completed", "failed", or "cancelled"
Returns: Table of jobs with ID, status, email count, and dates.
Credit cost: Free
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| limit | No | Results per page (default: 20, max: 100) | |
| status | No | Filter by job status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and not destructive. The description adds that it returns a table with specific fields and states the credit cost is free, providing useful behavioral context beyond 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 well-structured: main purpose first, then parameter details in Args format, and return statement. No extraneous information.
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 no output schema, the description explains the return format (fields included). It covers pagination, filter options, and credit cost, making it complete for the tool's complexity.
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 coverage is 100% with all parameters documented, but the description adds meaning by specifying the return format and that page defaults to 1, limit defaults to 20 with max 100, which reinforces the schema.
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 it lists batch verification jobs with pagination and status filter, distinguishing it from sibling tools like deliveriq_batch_download and deliveriq_check_credits.
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?
It explains when to use the tool (listing jobs with pagination and status filter) but does not explicitly mention when not to use it or alternative tools. However, the context of sibling tools makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the organization intelligence database for a domain. Returns email patterns, verified contact count, and company name. Free — no credits charged.
This data is populated by the enrichment system. If no data exists, use deliveriq_find_email to trigger enrichment for the domain.
Args:
domain (string): Company domain (e.g. "acme.com")
Returns: Primary email pattern, confidence, verified contact count, and all observed patterns.
Examples:
"What email patterns does acme.com use?" -> { domain: "acme.com" }
Credit cost: Free
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to query organization intelligence (e.g. "acme.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), description adds cost info, data source ('populated by enrichment system'), and return fields. No contradictions.
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?
Concise and well-structured: purpose, returns, cost, data source, args, returns, examples. No unnecessary words.
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?
With no output schema, description lists returned fields and provides usage guidance. Relationship with sibling tool explained. Sufficient for a simple tool.
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 has 100% coverage with one parameter. Description adds example and clarifies format with 'e.g. "acme.com"', which is helpful beyond schema.
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?
Clear verb 'Query' with specific resource 'organization intelligence database'. Distinguishes from siblings by stating when to use deliveriq_find_email instead.
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?
Explicitly states when to use this tool and when to use an alternative (deliveriq_find_email for enrichment). Also notes free usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze an email address for spam trap risk using 13 signals including domain age, DNSBL listing, disposability, role-based detection, entropy, and email pattern trust.
Args:
email (string): Email address to analyze
Returns: Risk level (low/medium/high), trap type (pristine/recycled/typo/none), confidence score, and all 13 signals.
Examples:
"Is user@example.com a spam trap?" -> { email: "user@example.com" }
Credit cost: 1 credit
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to analyze for spam trap risk (e.g. "user@example.com") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and other safe operation hints. The description adds behavioral context: credit cost per call, and outlines the return structure (risk level, trap type, confidence score, 13 signals). This clarifies the output beyond schema, but does not delve into error handling or rate limits.
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 well-structured with clear sections: Args, Returns, Examples, Credit cost. It is front-loaded with the main purpose, and every sentence adds value. No extraneous information.
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 tool (single parameter, detailed schema, good annotations, no output schema), the description is complete. It explains the return values (risk level, trap type, confidence, all 13 signals) and provides an example, making it easy for an agent to use 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?
The input schema has 100% description coverage for the single parameter 'email', including format and example. The description repeats this and adds a usage example. With complete schema coverage, the description does not add significant new semantic meaning beyond the schema.
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's purpose: 'Analyze an email address for spam trap risk using 13 signals'. It specifies the resource (email address) and action (analyze for spam trap risk), with examples and a list of signal types. This distinguishes it from sibling tools like deliveriq_verify_email or deliveriq_blacklist_check, which have different focuses.
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 implies usage for analyzing spam trap risk and provides an example, but does not explicitly state when to use this tool vs alternatives (e.g., when not to use, or which sibling to choose for other email checks). It includes a credit cost note but lacks exclusions or alternative tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a single email address for deliverability. Returns reachability status (safe/risky/invalid/unknown), a 0-100 score, and detailed checks (syntax, MX, SMTP, disposable, role-based, etc.).
Args:
email (string): Email address to verify
skip_smtp (boolean): Skip SMTP check (faster, default: false)
check_gravatar (boolean): Check for Gravatar profile (default: false)
check_hibp (boolean): Check Have I Been Pwned breaches (default: false)
include_intelligence (boolean): Include DNSBL, spam trap, domain age, infrastructure analysis (default: false)
Returns: Markdown report with reachability, score, and check details.
Examples:
"Is john@acme.com a valid email?" -> { email: "john@acme.com" }
"Deep check on user@example.com" -> { email: "user@example.com", include_intelligence: true, check_hibp: true }
Credit cost: 1 credit (0 if syntax is invalid)
Error Handling:
Returns "Authentication failed..." if API key is invalid
Returns "Insufficient credits..." if balance is 0
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to verify (e.g. "user@example.com") | ||
| skip_smtp | No | Skip SMTP verification step (faster but less accurate) | |
| check_gravatar | No | Check if email has a Gravatar profile | |
| check_hibp | No | Check if email appears in Have I Been Pwned breach data | |
| include_intelligence | No | Include deep intelligence (DNSBL, spam trap, domain age, infrastructure) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, but the description adds valuable behavioral details: credit cost (1 credit, 0 if invalid), error handling (auth failure, insufficient credits), and return format (Markdown report). These go beyond annotations. Minor missing info about rate limits, but overall good.
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 well-structured: purpose sentence, Args list, Returns, Examples, Credit cost, Error Handling. Every sentence earns its place. Front-loaded with the core action. No redundant text. Appropriate length for a tool with 5 params.
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 5 parameters, no output schema, and diverse siblings, the description covers essential aspects: action, parameters, return format, credit cost, error conditions. It lacks contrast with siblings and does not detail the 0-100 score scale, but these are minor gaps. Overall sufficient for an agent to invoke 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?
Input schema has 100% description coverage, so the baseline is 3. The description restates parameter purposes and adds examples, but does not significantly extend the meaning beyond the schema. Credit cost info is somewhat param-related but not semantic. No new constraints or formatting details.
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 starts with a specific verb+resource: 'Verify a single email address for deliverability'. It clearly distinguishes from siblings like deliveriq_batch_verify (bulk) and deliveriq_find_email (search). The examples reinforce the one-off verification use case.
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 implies usage for single email verification and provides example queries, but does not explicitly state when to use this tool versus alternatives like batch verification or domain intelligence. No when-not or exclusion criteria are given, so the agent must infer context from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation (batch download, status, verify, blacklist check, credits, domain intel, find email, infrastructure, list jobs, org intel, spam trap, verify email). No overlaps, even domain_intel suggests using specific tools for granular needs.
All tools follow a consistent deliveriq_verb_noun pattern (e.g., batch_verify, blacklist_check, find_email, org_intel). The prefix is uniform, and verbs clearly indicate actions.
12 tools are well-scoped for an email verification service, covering batch operations, single verification, intelligence, infrastructure, and account management. Neither too many nor too few.
The tool set covers the full verification lifecycle: single and batch verify, status polling, result download, intelligence, blacklist, infrastructure, spam trap, and account credits. Minor gap: no explicit cancel/delete for batch jobs, though batch_status provides monitoring.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Email for AI agents — send, receive as a webhook, manage domains, templates, routing.
Email for AI agents: send mail, manage contacts, automations & webhooks. Zero-DNS first send.
Email verification for AI agents — verify, clean & validate emails; self-onboard + crypto pay
Authenticated email gateway for AI agents — per-agent inboxes, HITL approval, SPF/DKIM verified.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Davison-Francis/min8t-sdks'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
