An MCP server that finds a company contact page and extracts role emails, a phone number and a postal address. It wraps the Mamba Labs Company Contact Details Extractor actor on Apify and returns a Clay-ready flat JSON row to any MCP client.
Related MCP server: mcp-github-organization-signal-scanner
Give it a company domain and it finds that company's contact page, then returns the role email addresses published on it, a main phone number in E.164 where the country resolves, and a postal address. One flat row per company.
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 info@, support@, sales@ and privacy@ survive and 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.
All of the extraction runs on Apify. This package is a thin client that calls the actor and hands back the result unchanged.
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config:
{
"mcpServers": {
"mamba-company-contact-details-extractor": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-company-contact-details-extractor"],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Get your token at https://console.apify.com/account/integrations, paste it in, and restart Claude Desktop. The extract_company_contact_details tool will be available.
Node.js 18 or newer
An Apify account with an API token
"Find the contact details for stripe.com."
"Get the sales email for figma.com and skip the phone number."
"Pull contact details for this local plumbing company and allow free mailboxes."
"Extract the support address for notion.com, reading a second page if the contact page has nothing."
company_domain (optional): bare company domain, for example stripe.com. This is the lookup key and the join key for every other actor in the fleet.
company_name (optional): used in the row and in logging. This tool gates addresses on the email domain rather than on the company name, so supplying a name does not change which addresses are kept.
emailTypes (optional): which classes of role address to return. One of all, general, support, sales, privacy, general_support or sales_only. all is the default and 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.
includePhones (optional): when true (the default) the contact page is scanned for a main phone number. Set false to skip phone extraction entirely.
includeAddress (optional): when true (the default) a postal address is read from JSON-LD first and from the footer second. Set false to skip it.
allowFreeMailboxes (optional): when false (the 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.
crawlDepth (optional): how many pages to read after the homepage. 1 (the 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.
skipCache (optional): when false (the default) a successful lookup is cached for seven days and reused. Set true to force a fresh fetch.
The tool returns the actor's flat JSON row for the company, with 25 snake_case fields and no nested objects. emails_rejected_count and emails_rejected_reasons account for what was dropped, contact_page_method says how the contact page was found, and fetch_status says whether the read succeeded. See the Apify Store page for the full output schema.
{
"degraded": false,
"degradation_reason": null,
"company_domain": "stripe.com",
"company_name": "Stripe",
"contact_page_url": "https://stripe.com/contact/sales",
"contact_page_method": "footer_anchor",
"contact_page_confidence": 0.85,
"email_general": null,
"email_support": null,
"email_sales": "sales@stripe.com",
"email_privacy": null,
"emails_found_count": 7,
"emails_rejected_count": 6,
"emails_rejected_reasons": "foreign_domain=5, not_a_role_address=1",
"phone_main": null,
"phone_source": null,
"address_line": null,
"address_city": null,
"address_country": null,
"contact_form_url": null,
"pages_read": 2,
"coverage": 0.2,
"fetch_status": "ok",
"run_date": "2026-08-22T19:23:48.675Z"
}Role email addresses only, never a named individual
Main phone number and postal address when the company publishes them
Contact page URL, plus how that page was found
Rejection accounting in emails_rejected_reasons, so a thin read is visible
Coverage reported per row
25 flat snake_case fields, one row per company
This server is a thin client and holds no extraction logic. For the complete input and output reference, pricing, and run history, see the Apify Store page:
https://apify.com/mambalabs/company-contact-details-extractor
This server is one of the Mamba Labs GTM Suite MCP servers. Every actor in the suite takes a domain or a company and returns one flat row, so they stack in the same Clay table without reshaping anything. The actor behind this server is the Company Contact Details Extractor, immutable Apify actor ID 4mMncKaJykiq94grz.
Built by Mamba Labs | npm | Apify Store
MIT
Built by Mamba Labs. https://apify.com/mambalabs
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0extract_company_contact_detailsScored across 1 tool
There is only one tool on this server, so an agent cannot confuse it with anything else. Its purpose—extracting company contact details from a domain—is explicit and unique.
The single tool name follows a clear verb_noun pattern with snake_case: extract_company_contact_details. There are no mixed conventions or inconsistent verbs to create doubt.
One tool is below the typical 3-15 range, but this is a deliberate narrow extractor and the tool fully earns its place. The count is slightly under a fuller toolkit yet appropriate for the server's stated purpose.
The tool covers the full extraction workflow: finding the contact page, classifying role emails, normalizing the phone number, returning a postal address, and reporting rejected addresses. Because it is explicitly read-only, no CRUD lifecycle operations are expected, and there are no obvious dead ends.
Apify MCP — run web-scraping Actors and fetch their dataset results.
Clutch.co B2B agency directory, profiles, and reviews as JSON, via an Apify Actor, hosted MCP.
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
MCP server for Tomba email finder, verification, and contact enrichment API
