mcp-company-contact-details-extractor
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APIFY_TOKEN | Yes | Your Apify API token |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| extract_company_contact_detailsA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
With a single tool there is no possibility of misselection; its purpose (find a company's contact page from a domain and extract role emails, phone, and postal address) is stated unambiguously in both name and description.
The lone name, extract_company_contact_details, follows a clear verb_noun_object snake_case pattern and is descriptive of the action and resource. There are no other names to conflict with it.
The server is narrowly scoped and the single monolithic tool does address that scope end-to-end, but one tool is thin for a surface that handles discovery, extraction, validation, rejection reporting, and output formatting in one call.
For its stated purpose the tool covers the full pipeline (email roles, E.164 phone with country resolution, postal address) and even reports rejected addresses with reasons, avoiding false-thin results. Minor gaps exist, e.g. no bulk/multi-domain input or parameterization for selective extraction.