mcp-company-contact-details-extractor

Extract Company Contact Details

extract_company_contact_details

Read-onlyIdempotent

Find a company's contact page from its domain and extract role-based email addresses, main phone, and postal address, rejecting personal contacts and reporting what was filtered.

Instructions

Find a company's contact page from its domain and extract classified ROLE email addresses (general, support, sales, privacy), a main phone number in E.164 where the country resolves, and a postal address. Returns one flat Clay ready row. Named individuals are NEVER returned: an address is kept only when its domain belongs to the company and its local part is in the role vocabulary, so a person's address is dropped by an allow list rather than by a name detector. The row reports how many addresses were found and how many were rejected and why, so a thin result is never mistaken for a site that publishes nothing. Read only; requires an APIFY_TOKEN and consumes Apify credits per call.

Input Schema

TableJSON Schema

Name	Required	Description
`skipCache`	No	When "false" (default) a successful lookup is cached for seven days and reused, which costs you nothing on a repeated run. Set "true" to force a fresh fetch. Sent as a string for Clay compatibility.
`crawlDepth`	No	How many pages to read after the homepage. "1" (default) reads the contact page. "2" also reads a support or legal page when the contact page yielded nothing. This is a cost and thoroughness dial, not a change of answer. Sent as a string for Clay compatibility.
`emailTypes`	No	Which classes of role address to return. "all" (default) returns general, support, sales and privacy. The narrower settings return only what they name and leave the other columns null, which is a different answer from not finding one. Sent as a string for Clay compatibility.
`company_name`	No	Optional. Used in the row and in logging. This actor gates addresses on the email DOMAIN rather than on the company name, so supplying a name does not change which addresses are kept.
`includePhones`	No	When "true" (default) the contact page is scanned for a main phone number. Set "false" to skip phone extraction entirely, which leaves the phone columns null. Sent as a string for Clay compatibility.
`company_domain`	No	Bare company domain, for example stripe.com. This is the only required input and it is the join key for every other actor in the fleet.
`includeAddress`	No	When "true" (default) a postal address is read from JSON-LD first and from the footer second. Set "false" to skip it. Sent as a string for Clay compatibility.
`allowFreeMailboxes`	No	When "false" (default) an address at gmail, outlook or another free provider is rejected, because it cannot be checked against the company domain. Set "true" for small business and local company lists, where a free mailbox on the contact page is often the real contact point. Sent as a string for Clay compatibility.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 8, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The annotations already signal read-only and idempotent behavior, and the description adds meaningful detail beyond them: APIFY_TOKEN requirement, credit consumption, role-vocabulary allow-listing rather than name detection, and rejection reporting so thin results are not misinterpreted. It also clarifies phone formatting and when address extraction is attempted.

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?

Every sentence in the description earns its place: the main function, the output shape, the critical never-return-individuals rule, the rejection-reporting behavior, and the operational requirements. The most important distinguishing behavior is front-loaded, and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core purpose, output shape, key edge-case behavior, and operational constraints well, and the annotations plus detailed parameter schemas complete the operational picture. The only gap is that, with no output schema present, the exact output column names are not explicitly enumerated; however, the parameter descriptions and 'flat Clay ready row' phrasing make the return shape largely inferable.

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 description coverage is 100%, and each parameter already has rich, Clay-specific semantics including defaults, string casting, and domain-gating behavior. The tool description contributes some global context like the role vocabulary and rejection logic, but it does not need to restate parameter details; the schema carries the parameter burden.

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 description opens with a specific verb and resource: finding a company's contact page from its domain and extracting classified ROLE emails, a phone number in E.164, and a postal address. It states the deliverable (one flat Clay ready row) and explicitly differentiates itself by declaring that named individuals are NEVER returned.

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?

There are no sibling tools to contrast with, but the description gives clear context: it is a read-only, token-required, credit-consuming enrichment tool for company-level contact data. It also provides an implicit exclusion by stating that individual addresses are never returned, which helps an agent avoid using it for person-level lookups.

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

extract_company_contact_detailsA