Skip to main content
Glama

Fairquery Agent Trust & Data Safety

by com.getfairquery
OverviewDiscussionsAdmin

Validate email deliverability: MX, SPF, DMARC (paid)

email_validate_deliverability
Read-onlyIdempotent

WHAT: Runs the Fairquery Apify Actor email-validator-mx-disposable: syntax, domain existence, MX/null-MX, disposable, role, free provider, typo suggestion, SPF/DMARC policy, mail provider; final verdict valid | risky | invalid | unknown. WHEN: Only when MX/DNS matters (can the domain receive mail?), e.g. cleaning lists before a send or verifying a lead's domain; pre-filter with email_check_syntax to avoid paying for obviously bad rows. WHEN NOT: Offline format, typo, disposable or role checks (free email_check_syntax). Leads that also need sanctions screening: trust_screen_lead (one merged decision). It does not SMTP-probe mailboxes. COST: Paid, billed to YOUR Apify account via your APIFY_TOKEN: $0.79 per 1,000 emails (+ $0.05 per 1,000 runs). 100 emails ~ $0.08. RETURNS: Paged "email" rows (verdict valid | risky | invalid | unknown with reasons[]) or "error" rows. Tool errors: APIFY_TOKEN_MISSING, APIFY_TOKEN_INVALID, APIFY_PAYMENT_REQUIRED, APIFY_ACTOR_RUN_FAILED, APIFY_TIMEOUT. BEHAVIOR: No email is sent; results change only with live DNS. Called from this Fairquery-hosted Worker, which forwards your input and Apify token to Apify and waits 20 s (APIFY_TIMEOUT if the run has not finished). This Worker's code is designed not to store them. The Actor in your account does the DNS/MX lookups. PARAMETERS: emails: elements may also hold comma/semicolon/newline-separated lists or "Name " forms; the Actor splits them, trims, and skips case-insensitive duplicates, so you pay once per unique address. The allow* flags only decide whether a condition downgrades the verdict to "risky": the matching reason code (ROLE_ACCOUNT, DISPOSABLE_DOMAIN, FREE_PROVIDER) is reported in reasons[] either way, and they can never turn an "invalid" address (bad syntax, no domain, null MX, no mail server) into "valid". POSSIBLE_TYPO and IMPLICIT_MX_ONLY always make it "risky" regardless of flags. Typical presets: B2B lead list = allowFreeProviders false + allowRoleAccounts false; consumer signups = defaults. checkSpfDmarc only adds has_spf / has_dmarc / dmarc_policy fields; it never changes the verdict or the price. limit/offset only page the returned rows: every call validates and bills the whole list again (also when only offset changes), so set limit (max 1000) to cover all rows instead of paging. EXAMPLE: {"emails":["john@stripe.com"]} -> verdict "valid", has_mx true, mail_provider "Google Workspace / Gmail".

Input Schema

NameRequiredDescriptionDefault
limitNoOptional page size: items to return, integer 1-1000 (default 100). Example: 50
emailsYesRequired. 1-10000 strings, 1-320 chars each, one address per element; bare "jane@acme.com", "Jane <jane@acme.com>" and "mailto:jane@acme.com" forms accepted. Example: ["jane@acme.com","bob@gmial.com"]
offsetNoOptional zero-based number of items to skip, integer 0-1000000 (default 0); pass nextOffset from the previous response, e.g. 100
checkSpfDmarcNoOptional boolean, default true. true adds has_spf, has_dmarc and dmarc_policy (none|quarantine|reject) per domain; false skips those DNS lookups. Verdict and price are unaffected
allowDisposableNoOptional boolean, default false = disposable/temporary-inbox domains (mailinator.com, ...) get verdict "risky"; true stops penalising them
allowRoleAccountsNoOptional boolean, default true. false downgrades role mailboxes (info@, sales@, support@, ...) to verdict "risky"
allowFreeProvidersNoOptional boolean, default true. false downgrades free webmail (gmail.com, outlook.com, yahoo.com, ...) to "risky"; recommended for B2B lead lists

Output Schema

NameRequiredDescriptionDefault
metaNoTool-specific context (summary counts, cost notes, ...)
countYesNumber of items in this page
itemsYesResult rows for this page
totalYesTotal items before paging
offsetYesOffset of the first item in this page
hasMoreYesTrue if more items exist after this page
nextOffsetYesOffset to pass for the next page, or null

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations declare read-only/open-world/idempotent, but the description adds the traits that actually change agent behavior: paid with exact per-1,000 pricing billed to the caller's Apify account, a 20-second wait, an enumerated set of APIFY_* error codes, and the fact that no SMTP probe or email send occurs. It also discloses the Worker-to-Apify forwarding path and that results vary only with live DNS.

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-loaded with a WHAT/WHEN/WHEN NOT/COST/RETURNS/BEHAVIOR/PARAMETERS/EXAMPLE skeleton, so an agent can stop reading at any level of detail. Length is justified by 7 parameters, live billing, and timeout semantics; the only mild redundancy is the pricing restated as an arithmetic example, which still aids cost estimation.

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 everything needed to invoke correctly: cost model, timeout ceiling, error taxonomy, output row shapes, and the billing trap around paging. Even though an output schema exists, the description of "email" vs "error" rows and the reasons[] field is a useful complement rather than padding.

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

Parameters5/5

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

Schema coverage is 100% (baseline 3), but the description adds semantics the schema cannot express: input splitting/dedup so you pay once per unique address, the rule that allow* flags can only downgrade to "risky" and never upgrade an invalid address, that POSSIBLE_TYPO and IMPLICIT_MX_ONLY are unconditional, and that offset re-bills the whole list. These are genuinely decision-changing details absent from the property descriptions.

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+resource (deliverability validation via a named Actor) and enumerates the exact checks performed and the four possible verdicts. It explicitly separates itself from email_check_syntax (offline checks) and trust_screen_lead (merged decision), so an agent can route without opening either schema.

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?

Has explicit WHEN and WHEN NOT sections naming the alternative tools and the deciding condition ("only when MX/DNS matters", "pre-filter with email_check_syntax"). It also gives concrete preset configurations (B2B list vs consumer signups), which removes most remaining inference.

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

All Fairquery Agent Trust & Data Safety toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources