webdata-tools-mcp

Find emails, phones and social profiles on websites

find_website_contacts

Read-onlyIdempotent

Find business emails, phone numbers, addresses, and social profiles on any list of websites by visiting contact and about pages. Use for lawful business outreach.

Instructions

Finds business emails, phone numbers, addresses and social profiles (LinkedIn, X, Facebook, Instagram, YouTube) on any list of websites; it visits the contact and about pages itself. Use only for lawful business outreach (GDPR / CAN-SPAM). Runs the Apify Actor tacps126/contact-details on your Apify account (about $0.002 per website with contacts found; nothing found, no charge; spend per call is capped at $0.5).

Input Schema

TableJSON Schema

Name	Required	Description
`websites`	Yes	Website addresses or domains, e.g. "apify.com".
`max_items`	No	Maximum results to return (default 50, max 1000). Cost scales with this.
`extra_input`	No	Advanced: extra Actor input fields, merged over the defaults.
`require_email`	No	Drop sites where no email was found.
`max_pages_per_site`	No	Pages read per website; contact, imprint and about pages are picked first.

Output Schema

TableJSON Schema

Name	Required	Description
`tool`	Yes	Name of the tool that produced the result.
`count`	Yes	Number of records the Actor returned.
`items`	Yes	The records. Long text fields are shortened to 600 characters.
`shown`	Yes	Number of records included in `items` (can be lower than count when the result is long).
`truncated`	Yes	True when records were left out to keep the result short; ask for fewer items.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.1Oct 17, 2026

addedInput schema / properties / max_pages_per_site / description

Added value: +"Pages read per website; contact, imprint and about pages are picked first."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "count": {
+      "description": "Number of records the Actor returned.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "items": {
+      "description": "The records. Long text fields are shortened to 600 characters.",
+      "items": {
+        "additionalProperties": {},
+        "propertyNames": {
+          "type": "string"
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "shown": {
+      "description": "Number of records included in `items` (can be lower than count when the result is long).",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "tool": {
+      "description": "Name of the tool that produced the result.",
+      "type": "string"
+    },
+    "truncated": {
+      "description": "True when records were left out to keep the result short; ask for fewer items.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "tool",
+    "count",
+    "shown",
+    "truncated",
+    "items"
+  ],
+  "type": "object"
+}

First observedv0.1.0Oct 17, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so safety is covered. The description goes further with genuinely useful operational detail: the backing Apify Actor, per-site pricing with no charge when nothing is found, and a $0.5 per-call spend cap. It still omits what a partial/failed crawl looks like, but the cost and execution model are well disclosed.

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?

Two dense sentences that lead with what is found and where, then follow with legality and execution economics. Every clause carries information, though the second sentence packs legality, Actor identity, unit pricing, free-miss policy and a cap into one run-on that could be split.

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?

With an output schema present, return values need no explanation, and annotations cover the safety profile. The description supplies the remaining agent-relevant context (legal use, crawl behavior, cost model), leaving only minor gaps around error/partial-result handling.

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%, with websites, max_items, max_pages_per_site, require_email and extra_input all self-documented, including defaults, ranges and the cost-scaling note on max_items. The description adds no parameter-level meaning beyond this, so the baseline 3 applies.

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 (Finds) plus the exact resources (business emails, phone numbers, addresses, social profiles on named platforms) and mechanism (visits contact and about pages itself). This makes it trivially distinguishable from siblings like search_google_news or get_company_jobs, which are single-source retrieval tools rather than website contact scrapers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a usage constraint ('Use only for lawful business outreach (GDPR / CAN-SPAM)') and cost framing, which implies the appropriate context. However, it never names an alternative or states when a different sibling tool would be the better choice for a related need, so selection guidance is only implied.

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

Deploy Server