Skip to main content
Glama
fairquery

Email Validator for Agents

by fairquery
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Validate email addresses (syntax, MX, disposable, typo)

validate_emails
Read-onlyIdempotent

Screen email lists before outreach or import: check syntax, domain MX records, disposable domains, role accounts, typos, and SPF/DMARC, returning valid/risky/invalid verdicts per address.

Instructions

WHAT: Validate email addresses for deliverability risk: RFC-style syntax, domain existence and MX records (DNS-over-HTTPS), null MX, disposable/temporary inbox domains, role accounts (info@, sales@), free webmail providers, common domain typos with a "did you mean" suggestion, and optional SPF/DMARC presence and policy. WHEN TO USE: cleaning signup or lead lists, checking an address before sending, flagging throwaway or typo signups. WHEN NOT TO USE: for a quick offline format check or parsing "Name " strings use check_email_syntax (free). Does NOT send email or do SMTP mailbox probing, so it cannot confirm that a specific mailbox exists. BEHAVIOR: read-only; runs the Fairquery Apify Actor fairquery/email-validator-mx-disposable via the Apify API (DNS lookups via Cloudflare DoH). Requires APIFY_TOKEN. Duplicates (case-insensitive) are skipped. Typical run 3-30 s. COST: paid (billed to your Apify account, pay-per-event): $0.00005 per run + $0.002 per email row with a verdict; error rows are free. 100 emails ~ $0.20. RETURNS: {count, items}. email rows: input, email, domain, verdict (valid | risky | invalid | unknown), reasons[] (INVALID_SYNTAX, DOMAIN_NOT_FOUND, NULL_MX, NO_MAIL_SERVER -> invalid; DISPOSABLE_DOMAIN, ROLE_ACCOUNT, FREE_PROVIDER, POSSIBLE_TYPO, IMPLICIT_MX_ONLY -> risky depending on allow* flags; DNS_NOT_CHECKED -> unknown), syntax_valid, is_disposable, is_role_account, is_free_provider, did_you_mean, domain_exists, has_mx, mx_records, mail_provider, has_spf, has_dmarc, dmarc_policy, source_url, checked_at. error rows: code (INPUT_EMPTY, MAX_EMAILS_EXCEEDED, DNS_LOOKUP_FAILED), message, retryable. EXAMPLE: {"emails":["someone@gmial.com"]} -> verdict "risky", reasons ["POSSIBLE_TYPO"], did_you_mean "someone@gmail.com".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailsYesRequired. 1-10000 email addresses to validate. Entries may also be comma/semicolon/newline-separated lists or "Name <addr>" forms. Example: ["john.doe@gmail.com","someone@gmial.com"]
checkDnsNoLook up MX/A records to confirm the domain can receive mail (default true). false = syntax/list checks only, verdict may be "unknown".
maxEmailsNoSafety cap on unique emails per run (1-100000, default 10000); extras produce a MAX_EMAILS_EXCEEDED error row
checkSpfDmarcNoAlso report SPF and DMARC presence and DMARC policy per domain (default true)
allowDisposableNoDefault false (disposable domains are "risky"). Set true to not penalize disposable domains.
allowRoleAccountsNoDefault true. If false, role addresses (info@, sales@, support@...) get verdict "risky".
allowFreeProvidersNoDefault true. If false, free webmail (gmail.com, outlook.com...) gets "risky" - useful for B2B lead lists.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesNumber of rows returned
itemsYesResult rows; each has a "type" field (data rows or machine-readable "error" rows)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv1.0.1
    • changedInput schema / properties / allowDisposable / description
      Previous value: -"If true, disposable domains are not risky"New value: +"Default false (disposable domains are \"risky\"). Set true to not penalize disposable domains."
    • changedInput schema / properties / allowFreeProviders / description
      Previous value: -"If false, free webmail becomes risky"New value: +"Default true. If false, free webmail (gmail.com, outlook.com...) gets \"risky\" - useful for B2B lead lists."
    • changedInput schema / properties / allowRoleAccounts / description
      Previous value: -"If false, info@/sales@ etc. become risky"New value: +"Default true. If false, role addresses (info@, sales@, support@...) get verdict \"risky\"."
    • changedInput schema / properties / checkDns / description
      Previous value: -"MX/A lookups (default true)"New value: +"Look up MX/A records to confirm the domain can receive mail (default true). false = syntax/list checks only, verdict may be \"unknown\"."
    • changedInput schema / properties / checkSpfDmarc / description
      Previous value: -"Report SPF/DMARC (default true)"New value: +"Also report SPF and DMARC presence and DMARC policy per domain (default true)"
    • changedInput schema / properties / emails / description
      Previous value: -"Email addresses to validate"New value: +"Required. 1-10000 email addresses to validate. Entries may also be comma/semicolon/newline-separated lists or \"Name <addr>\" forms. Example: [\"john.doe@gmail.com\",\"someone@gmial.com\"]"
    • addedInput schema / properties / emails / maxItems
      Added value: +10000
    • addedInput schema / properties / maxEmails / description
      Added value: +"Safety cap on unique emails per run (1-100000, default 10000); extras produce a MAX_EMAILS_EXCEEDED error row"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "count": {
+      "description": "Number of rows returned",
+      "type": "integer"
+    },
+    "items": {
+      "description": "Result rows; each has a \"type\" field (data rows or machine-readable \"error\" rows)",
+      "items": {
+        "additionalProperties": {},
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "items"
+  ],
+  "type": "object"
+}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, open-world. The description adds significant context beyond annotations: it explains the Apify Actor dependency, the APIFY_TOKEN requirement, duplicate skipping, typical run time (3-30s), and crucially the full cost model ($0.00005/run + $0.002/row). The only gap is not detailing the exact error row semantics, though these are partially listed.

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

Conciseness4/5

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

The description is front-loaded with the WHAT, WHEN TO USE, and BEHAVIOR sections, making it easy to parse. However, the RETURNS section is quite verbose, listing all possible fields and their values, which duplicates information likely available in the output schema.

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?

Given the tool's complexity (external API, cost, multiple verdicts, error handling), the description provides a complete picture. It covers purpose, usage, behavior, cost, return values, and an example, leaving no major gaps for an agent to call it correctly. With an output schema present, the RETURNS detail is somewhat redundant but not harmful.

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?

Schema coverage is 100%, so the schema already documents all seven parameters in detail. The description provides minimal additional parameter meaning beyond what the schema already specifies, particularly for the allow* flags. Baseline 3 is appropriate when the schema does the heavy lifting.

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 WHAT line states a specific verb (validate) and resource (email addresses) and enumerates the exact dimensions checked (syntax, MX, disposable, typo, role accounts, SPF/DMARC). It explicitly names the sibling check_email_syntax and distinguishes itself via the 'WHEN NOT TO USE' line.

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

Usage Guidelines5/5

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

The description provides explicit WHEN TO USE scenarios (cleaning lists, checking before sending, flagging signups) and an explicit WHEN NOT TO USE with the named alternative check_email_syntax. It also clarifies what it cannot do (no SMTP mailbox probing).

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

Deploy Server

Other Tools