fairquery-contact-enricher

Official

by fairquery

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Enrich domains with public business contacts

enrich_domains

Read-onlyIdempotent

Crawl company domains to extract public business contact data—validated role emails, phone numbers, social profiles, and addresses—for lead or CRM enrichment.

Instructions

WHAT: For each company domain, crawl the homepage plus up to N contact/about/imprint pages (plain HTTP, robots.txt respected, polite per-site delay) and return one row with company_name, description, business/role emails (MX, disposable and typo validated), phones (E.164), social profiles (LinkedIn company, X, Facebook, Instagram, YouTube, GitHub...), postal address and mail-domain info. WHEN TO USE: enriching a lead/CRM list of company websites with public contact data; finding the official contact email or address of a business. WHEN NOT TO USE: to clean/dedupe a messy list first or preview what will be billed, call normalize_domains (free). Not for finding personal emails of individuals, LinkedIn people search, or JavaScript-only sites that need a browser. COST: paid. Runs Apify Actor fairquery/website-contact-company-enricher with your APIFY_TOKEN; pay-per-event "domain-enriched", once per domain that returns a result row. Unreachable, blocked or invalid domains are free. ~2-10 s per domain. RETURNS: {count, items}. type="domain" row per domain: input, domain, final_url, company_name, description, emails[], primary_email, phones[] (E.164), social_links, address, addresses, mail_domain (MX/provider, SPF/DMARC if requested), pages_crawled, pages_blocked_by_robots, email_scope, enriched_at; or type="error" rows (code, message, retryable). EXAMPLE: {"domains":["stripe.com","https://basecamp.com/about"],"maxPagesPerDomain":3} -> 2 domain rows.

Input Schema

TableJSON Schema

Name	Required	Description
`domains`	Yes	Required. Domains, website URLs or email addresses (the domain part is used); comma/semicolon lists are split. Example: ["apify.com","https://stripe.com","info@basecamp.com"].
`emailScope`	No	"role" (default, GDPR-friendly) = generic mailboxes only (info@, sales@, support@); "business" = also named addresses on the company's own domain; "all" = every address published on the pages.
`checkSpfDmarc`	No	Default false. Add SPF/DMARC presence and DMARC policy for the company mail domain.
`validateEmails`	No	Default true. DNS-over-HTTPS MX lookup plus disposable and typo checks on found emails (no SMTP probing).
`maxPagesPerDomain`	No	Pages fetched per domain, 1-15 (default 5): homepage plus the best contact/about/imprint pages linked from it.
`defaultPhoneCountry`	No	ISO 3166-1 alpha-2 code, e.g. "US", "DE". When set, national-format numbers in page text are also parsed; otherwise only tel: links, JSON-LD and +international numbers. No default.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`count`	Yes	Number of rows in items
`items`	Yes	Dataset rows: type=domain or type=error

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description layers on substantial extra context: pay-per-event billing (once per domain returning a row), free failures for unreachable/blocked/invalid domains, ~2-10 s per domain, robots.txt respect, per-site delay, and the APIFY_TOKEN requirement.

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?

Strongly front-loaded and labelled (WHAT/WHEN/COST/RETURNS/EXAMPLE), so an agent can scan it fast. It is on the long side, and the RETURNS block partially duplicates the output schema, which slightly dilutes conciseness.

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 an output schema and rich annotations, the description still covers cost, auth, failure modes, timing, and scope exclusions. Nothing an agent needs to decide or invoke correctly appears 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 already 100%, so baseline is 3. The description adds genuine meaning via maxPagesPerDomain ('homepage plus up to N contact/about/imprint pages') and the validation chain behind emails (MX, disposable, typo) and optional SPF/DMARC, though most parameter detail remains in the schema.

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?

Specific verb+resource: crawls a company domain's homepage and contact pages to return public business contact data, with the exact field set enumerated. It also implicitly distinguishes itself from normalize_domains by describing enrichment/paying-per-domain rather than list cleanup.

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?

Explicit WHEN TO USE (lead/CRM enrichment, finding official business contact info) and WHEN NOT TO USE (list cleaning, personal emails, LinkedIn people search, JS-only sites), plus a named alternative: normalize_domains, flagged as free.

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

Deploy Server