Which integrations are available for this server?

Decodes Cloudflare email-protection values, including data-cfemail attributes and /cdn-cgi/l/email-protection links, to recover published email addresses during lead extraction.

How do I use LeadDirect MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LeadDirect MCP Find 10 lowbed semi-trailer dealers in France and save them to CSV" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

LeadDirect MCP

by weblinkify

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

LeadDirect MCP

Live demo: https://lead-direct-mcp.vercel.app (mock mode, runs fully in the browser) · deploys automatically on every push to main

An MCP server for B2B prospecting from Claude Desktop, Cursor or any MCP client. Describe the companies you want ("lowbed semi-trailer dealers in France, skip the big brands") and LeadDirect searches the web, reads each company's own homepage, contact, about and imprint pages, and returns the contact details the company publishes: emails (including ones hidden by Cloudflare email protection), phone numbers, and LinkedIn / Facebook / Instagram / WhatsApp / X links. New leads go into a CSV, de-duplicated by domain.


MCP server	Python 3.10+ · FastMCP · httpx · BeautifulSoup · phonenumbers · ddgs
Web demo	React 18 · TypeScript · Tailwind CSS · Vite, deployed on Vercel

LeadDirect only collects what a company publishes on its own website. It does not guess personal addresses or probe mail servers.

Tools

Tool	What it does
`find_leads`	Web search → one result per company domain (directories, marketplaces and social networks skipped, plus your `exclude_domains`) → crawl up to 6 pages per site → save new leads to `leads.csv`.
`scrape_company`	The same crawl for one URL or domain.
`decode_cloudflare_email`	Decodes a `data-cfemail` value or `/cdn-cgi/l/email-protection#…` link.
`list_leads`	Shows the latest rows of `leads.csv`.

Each lead lists emails with named contacts first and shared inboxes (info@, sales@, satis@, kontakt@, …) after. Asset names (logo@2x.png), placeholders (you@example.com, firstname.lastname@) and no-reply addresses are filtered out. Phone numbers are parsed with Google's libphonenumber and printed in international format; pass region (e.g. FR) so national numbers parse.

Related MCP server: @bingeljell/lead-gen-mcp

Install

git clone https://github.com/weblinkify/lead-direct-mcp
cd lead-direct-mcp
python -m venv .venv && source .venv/bin/activate     # Windows: .venv\Scripts\activate
pip install -e .

MCP client config (claude_desktop_config.json, Cursor mcp.json, …):

{
  "mcpServers": {
    "leaddirect": {
      "command": "/ABSOLUTE/PATH/lead-direct-mcp/.venv/bin/leaddirect",
      "env": { "LEADDIRECT_OUTPUT_DIR": "~/Desktop" }
    }
  }
}

leads.csv is written to LEADDIRECT_OUTPUT_DIR, else your Desktop, else ~/LeadDirect.

Prompting tips

Target and geography: the niche plus the country or region.
Local-language keywords: semi-remorque surbaissée concessionnaire for France, ambalaj karton üretici for Türkiye, Landtechnik Händler for Germany.
Exclusions: pass large brands and portals in exclude_domains.
Qualification: ask the assistant to keep only companies that sell the product directly.

Find 10 dealers of lowbed semi-trailers in France. Search in French
("semi-remorque surbaissée concessionnaire"), region FR, and skip
schmitz-cargobull.com and krone-trailer.com. Put the results in a table with
named contacts first and their LinkedIn pages.

Web demo

cd frontend
npm install
npm run dev          # http://localhost:5173

The companies are fictional (.example domains), but the HTML extractor and the Cloudflare decoder in the demo are TypeScript ports of the server code and run for real. Paste any page's HTML to try them.

Vercel: import the repo and set Root Directory to frontend; frontend/vercel.json does the rest.

Development

pip install -r requirements-dev.txt
pytest -q
cd frontend && npm test && npm run build

Responsible use

Respect each website's terms and robots rules, and the email marketing law where you operate (GDPR / ePrivacy in the EU, CAN-SPAM in the US, KVKK in Türkiye). Published business contact details are not a licence to send bulk unsolicited email.

License

MIT

Available Tools

4 tools

decode_cloudflare_emailDecode Cloudflare EmailA

Decode a Cloudflare email-protection string (the data-cfemail value or the part after '#').

Name	Required	Description	Default
`encoded`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It implies a pure transformation, but does not state that it is read-only, what happens with malformed input, or any error behavior. The output schema covers the return shape, which reduces the gap.

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?

One sentence, front-loaded with the action and resource, with no wasted words. The parenthetical adds precise input guidance without bloat.

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?

For a single-parameter decoding utility with an output schema, the description gives enough context to invoke it correctly. Minor gaps around malformed-input handling remain, but the essential input semantics are covered.

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 description coverage is 0%, so the description must compensate for the lone parameter. It does so well by explaining exactly what 'encoded' should contain: the data-cfemail value or the substring after '#'.

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 states a specific verb ('Decode') and resource ('Cloudflare email-protection string'), and it clarifies the exact input forms (data-cfemail value or the part after '#'). This is sufficiently distinct from the sibling lead/scraping tools.

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?

Usage is implied by the input format: use this when you have a Cloudflare email-protection string. There are no explicit when-to-use/when-not-to-use instructions or named alternatives, but the siblings are unrelated enough that extensive routing guidance is less necessary.

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

find_leadsFind LeadsC

Find companies for a query and collect their published contact details.

Name	Required	Description
`save`	No	Append new leads to leads.csv (domains already in the file are skipped).
`query`	Yes	e.g. "lowbed semi-trailer dealer France" or "semi-remorque surbaissée concessionnaire".
`region`	No	ISO country code (e.g. "FR") so national phone numbers parse.
`target_leads`	No	How many new companies to return (1-30).
`exclude_domains`	No	Domains to skip, e.g. big brands or marketplaces.

Output Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden. 'Published contact details' is a useful hint that only publicly listed contact data is collected, but the description never mentions the significant default side effect (save=true appends to leads.csv), that results are deduplicated by domain, or anything about latency, external scraping calls, or failure modes.

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?

A single front-loaded sentence with no filler; the core action and its output are stated immediately. It is tight, though arguably under-sized for a tool with a persistence default and four optional filters.

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

Completeness3/5

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

An output schema exists and every parameter is documented, so return-shape and argument questions are answered elsewhere. The gap is behavioral: for a web-search/scrape tool that writes to a file by default, the description should say what the search actually does and what persistence means.

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% — query, region, target_leads, exclude_domains and save are all documented with examples and constraints. The description adds nothing beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb-plus-resource ('Find companies') and adds what is returned ('their published contact details'), which is more than a restatement of the name. It stops short of distinguishing the tool from siblings like scrape_company or list_leads, so an agent still has to infer that this is bulk discovery rather than single-page scraping or reading stored leads.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no mention of the sibling tools, and no exclusions. An agent must reason from the verb 'find' alone that this is the discovery step and not the stored-lead listing or single-company scraping step.

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

list_leadsList LeadsB

Show the most recent rows of leads.csv.

Name	Required	Description	Default
`limit`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior3/5

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

With no annotations provided, the description carries the behavioral disclosure burden. 'Show' implies a read-only operation and 'most recent rows' conveys ordering, but it does not clarify limit behavior, pagination, or other operational traits.

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?

The description is a single, front-loaded sentence with no wasted text. It is appropriately compact for a simple listing tool.

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

Completeness3/5

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

The tool is simple, and the output schema exists, so return-value explanation is not required. However, the description leaves the only parameter undocumented and does not distinguish the tool from find_leads, leaving meaningful gaps for an agent selecting and invoking it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is one parameter, limit, with 0% schema description coverage beyond its name and default. The description does not explain what limit controls or how it interacts with 'most recent rows,' so it fails to compensate for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (show rows) and resource (leads.csv), with scope clarified as the most recent rows. It is understandable on its own, but it does not explicitly distinguish itself from the sibling find_leads tool.

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

Usage Guidelines2/5

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

It says to show the most recent rows, which implies listing recent leads, but it gives no explicit when-to-use guidance, exclusions, or comparison with find_leads. The agent must infer whether to use this or the sibling search tool.

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

scrape_companyScrape CompanyB

Crawl one company website (homepage + contact/about/imprint pages) for published contacts.

Name	Required	Description	Default
`region`	No
`url_or_domain`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It usefully bounds the crawl to homepage plus contact/about/imprint pages and limits output to 'published contacts,' but it does not disclose operational traits such as crawling limits, failure behavior, rate limiting, or robots/policy handling.

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?

The definition is a single front-loaded sentence with no wasted text. It efficiently communicates the action, scope, and target output.

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

Completeness3/5

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

The presence of an output schema reduces the need to explain return values, and the description adequately covers the primary crawl scope. However, it leaves the optional region parameter completely undocumented and lacks operational context for a tool that crawls external websites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description should explain parameters, but it only indirectly implies the required website input through 'one company website.' The optional 'region' parameter is not mentioned at all, leaving its meaning and effect unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (Crawl), a specific resource (one company website), and the exact page scope (homepage + contact/about/imprint), plus the output target (published contacts). It is clear what the tool does, though it does not explicitly differentiate itself from siblings such as find_leads.

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?

The phrase 'one company website' implies this tool is for a known company URL/domain rather than broad discovery, which gives some usage context. However, it provides no explicit when-to-use rules, exclusions, or comparison to alternatives like find_leads.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Oct 26, 2026
- First observeddecode_cloudflare_email
- First observedfind_leads
- First observedlist_leads
- First observedscrape_company

Deploy Server

Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

TDQS

B3.4/5.0

Scored 2026-10-26 13:50 across 4 tools

Disambiguation4/5

Each tool has a mostly distinct role: find_leads is a query-level search, scrape_company targets a single known site, decode_cloudflare_email is a narrow utility, and list_leads reads cached results. The main risk is overlap between find_leads and scrape_company, since both 'collect published contact details', but the descriptions make the bulk-vs-single distinction clear enough.

Naming Consistency5/5

All four tools follow a consistent snake_case verb_noun pattern (find_leads, scrape_company, decode_cloudflare_email, list_leads). No mixing of conventions or vague verbs.

Tool Count4/5

Four tools cover the core lead-generation pipeline (search, scrape, decode, list) without redundancy. It is on the lean side — a couple more operations would round it out — but nothing feels extraneous.

Completeness3/5

The create/scrape/read path exists, but there is no way to search or filter saved leads beyond 'most recent rows', no update/delete of entries, and no export or dedupe operation. These are workable gaps but real ones for a lead-management workflow.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

RecruitMCP B
com.recruitmcp
Search people and companies, enrich profiles, and find email and phone over MCP.
Search CRM Customer Data Platforms
111
https://mcp.recruitmcp.com/mcp
Website Email Extractor, Phone & Contact Finder (CSV, Sheet)OAuth
io.github.Nero-Engine
Published emails, phones and social profiles for every website in a list, CSV or Google Sheet.
Web Scraping Browser Automation
1
https://mcp.apify.com/?tools=nerolabs/website-contact-finder
Contact Details ScraperOAuth
io.github.saulius876-lgtm
Emails, phones and social links from any list of websites. Pay only for sites with a contact.
Web Scraping Browser Automation
1
https://mcp.apify.com/?tools=sauliusautomatesit/contact-details-scraper-api
SalesQLOAuth
com.salesql
Find verified B2B emails and phone numbers; search and enrich people and companies for prospecting.
CRM Search
1
https://mcp.salesql.com/mcp

Related MCP Servers

fetchcraft-mcp
Web Scraping Search Research & Data
emily397
F
license
Not graded
quality
C
maintenance
Enables B2B research by finding verified work emails, extracting contacts, detecting tech stacks, and profiling DNS and SaaS, all through a suite of MCP tools.
Updated 4 months ago (2026-06-18 05:14 UTC)
-
@bingeljell/lead-gen-mcp
CRM Marketing
Bingeljell
A
license
B
quality
D
maintenance
Enables AI-assisted B2B lead generation by discovering, extracting, scoring, and exporting company leads from any MCP-compatible agent.
Updated 7 months ago (2026-03-29 18:14 UTC)
3
2 npm
MIT
LeadDirect-MCP
Web Scraping Browser Automation Email
netizen4-bit
A
license
Not graded
quality
B
maintenance
Enables autonomous B2B lead generation by discovering companies, scraping websites for contacts, decoding obfuscated emails, generating email permutations, and verifying email deliverability via MX and SMTP checks.
Updated 4 days ago (2026-10-23 10:37 UTC)
2
MIT
Getlead MCP serverofficial
Email CRM
Adgrowofficial
A
license
Not graded
quality
D
maintenance
Enables finding B2B leads with verified work emails, finding and verifying email addresses, and running cold email outreach from any MCP client.
Updated a month ago (2026-09-26 12:29 UTC)
MIT

LeadDirect MCP

Tools

Install

Prompting tips

Web demo

Development

Responsible use

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Getlead MCP serverofficial