Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LeadEnrich MCP Server Find email for Jane Smith at acme.com"
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.
Waterfall lead enrichment for AI agents. Cascades through Apollo, Clearbit, and Hunter to build the most complete lead profile in a single call.
One-click install: Install on MCPize |
pip install leadenrich-mcp
LeadEnrich MCP exposes lead and company enrichment through the Model Context Protocol (MCP), so tools like Claude and Cursor can run enrichment workflows directly. Give it an email, domain, or name and it returns a merged profile with field attribution showing which provider contributed each data point.
pip install leadenrich-mcp
leadenrich-mcpThe server starts on http://localhost:8300/mcp by default.
Add to claude_desktop_config.json:
{
"mcpServers": {
"leadenrich": {
"url": "http://localhost:8300/mcp"
}
}
}claude mcp add leadenrich --transport http http://localhost:8300/mcpRelated MCP server: Prospeo MCP Server
Tool | Description |
| Full waterfall enrichment for a single lead (email, domain, or name+domain) |
| Discover an email from first name + last name + company domain |
| Company firmographic data by domain (industry, size, revenue, etc.) |
| Batch enrich up to 25 leads concurrently |
| Quota, cost tracking, and remaining lookups |
| Server status, configured providers, and cache stats |
LeadEnrich uses a waterfall strategy: each provider fills gaps left by the previous one. When email is known, all providers run concurrently for speed. When only name+domain is provided, Apollo discovers the email first, then Clearbit and Hunter run in parallel.
Input (email / domain / name+domain)
|
v
+-----------+ +-----------+ +----------+
| Apollo | --> | Clearbit | --> | Hunter |
+-----------+ +-----------+ +----------+
| Contact | | Company | | Email |
| Company | | Person | | Verify |
| LinkedIn | | Firmo | | Domain |
+-----------+ +-----------+ +----------+
| | |
v v v
+------------------------------------------+
| Merged Profile |
| 16+ fields with per-field attribution |
| Confidence score + lookup cost |
+------------------------------------------+Each field in the result includes attribution so you know exactly which provider it came from. No duplicate API calls thanks to built-in caching.
Tier | Cost | Details |
Free | $0.00 | 50 lookups/month |
1 provider hit | $0.05/lookup | Single provider returned data |
2 providers hit | $0.10/lookup | Two providers contributed fields |
3 providers hit | $0.15/lookup | Full waterfall, maximum coverage |
Python 3.11+
pip
git clone https://github.com/carsonlabs/leadenrich-mcp.git
cd leadenrich-mcp
pip install -r requirements.txt
python main.pyMCP endpoint:
http://localhost:8300/mcp
Variable | Description | Required |
| Apollo.io API key | No |
| Clearbit API key | No |
| Hunter.io API key | No |
| Client auth key for usage metering | No |
| Free tier limit (default: 50) | No |
| Server port (default: 8300) | No |
All provider keys are optional. The server uses whichever providers are configured and skips the rest.
Example:
export APOLLO_API_KEY="your-apollo-key"
export CLEARBIT_API_KEY="your-clearbit-key"
export HUNTER_API_KEY="your-hunter-key"
python main.pyRun directly:
python main.pyRun via FastMCP CLI:
fastmcp run main.py --transport streamable-http --port 8300enrich_leadInputs:
email (optional): Contact email address (best identifier)
domain (optional): Company domain (e.g. "stripe.com")
first_name / last_name (optional): Contact name (combine with domain)
providers (optional): Limit which providers to use
api_key (optional): Your LeadEnrich API key
Returns merged lead profile with field attribution, confidence score, and lookup cost.
find_emailInputs:
first_name (required): Contact's first name
last_name (required): Contact's last name
domain (required): Company domain
Returns discovered email with confidence score and verification status.
enrich_companyInput:
domain (required): Company domain
Returns company-level firmographic data: industry, size, revenue, description, location.
enrich_batchInputs:
leads (required): List of lead objects (max 25), each with optional email/domain/name
providers (optional): Limit which providers to use
api_key (optional): Your LeadEnrich API key
Returns list of enriched profiles with batch summary.
check_usageInput:
api_key (optional): Your LeadEnrich API key
Returns usage stats: lookup count, cost, tier, remaining quota, and cache stats.
health_checkNo input. Returns server status, configured providers, cache stats, and version info.
fastmcp list-tools main.py
fastmcp call-tool main.py health_check '{}'
fastmcp call-tool main.py enrich_lead '{"email":"jane@stripe.com"}'
fastmcp call-tool main.py find_email '{"first_name":"Jane","last_name":"Smith","domain":"stripe.com"}'
fastmcp call-tool main.py enrich_company '{"domain":"stripe.com"}'This repo includes smithery.yaml for Smithery deployment.
Push repository to GitHub
Create/add server in Smithery
Point Smithery to this repository
A Dockerfile is included for Railway, Fly.io, and other container hosts.
# Railway
railway up
# Fly.io
fly launch
fly deploySet your provider API keys in your host environment.
Agent (Claude, Cursor, etc.)
-> MCP
LeadEnrich MCP Server (this repo)
-> Apollo API (contact + company data)
-> Clearbit API (person + firmographic data)
-> Hunter API (email finding + verification)This server is a translation layer between MCP tool calls and multiple enrichment provider APIs, with built-in caching, usage metering, and waterfall merge logic.
Tool | Free | Pro ($29/mo) |
| Yes (Hunter only) | Yes (full waterfall: Apollo + Clearbit + Hunter) |
| Yes | Yes |
| Yes | Yes |
| - | Yes |
| - | Yes |
| - | Yes |
Free tier gives you single-provider lookups via Hunter. Pro unlocks the full 3-provider waterfall, email finder, company enrichment, and batch operations.
Upgrade to Pro on MCPize — $29/mo or $290/yr.
Built by Freedom Engineers
SelfHeal MCP — Self-healing proxy for MCP servers
SiteHealth MCP — Full website health audit
Check your current usage and remaining quota.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Your LeadEnrich API key. Uses server default if not provided. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it checks usage. No disclosure of behavior like rate limits, authentication needs beyond api_key, or potential side effects.
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?
The description is a single sentence with no extraneous words, achieving maximum conciseness while conveying the core purpose.
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?
Given the tool's simplicity and the presence of an output schema, the description is minimally adequate but lacks any context about quota types or usage limits.
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 coverage is 100% for the single optional api_key parameter. The description adds no extra meaning beyond the schema's own description.
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 clearly uses the verb 'check' and specifies the resource 'usage and remaining quota', making it distinct from sibling tools like enrich_lead or find_email.
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?
No guidance on when to use this tool versus alternatives like health_check. It only states the function without context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich multiple leads concurrently. Each lead cascades through all providers.
| Name | Required | Description | Default |
|---|---|---|---|
| leads | Yes | List of lead objects, each with optional keys: email, domain, first_name, last_name. | |
| providers | No | Optional list to limit which providers to use. | |
| api_key | No | Your LeadEnrich API key for usage tracking. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions concurrency and cascading through providers, but does not cover rate limits, error handling, or side effects. Additional transparency about concurrency limits or provider failures would improve this score.
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?
The description is a single, front-loaded sentence with no wasted words. It conveys the core function and a key behavioral detail efficiently.
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 is concise but covers the main purpose and concurrency behavior. It does not describe the output or error handling, but the presence of an output schema (noted in context) partially compensates. Given the simplicity of the tool, it is adequately complete.
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 coverage is 100%, so the baseline is 3. The description adds minimal semantic value beyond the schema (e.g., 'cascades through all providers' gives context for the 'providers' parameter). It does not elaborate on parameter usage or constraints.
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 uses a specific verb ('enrich') and resource ('multiple leads'), and distinguishes from the sibling 'enrich_lead' by emphasizing concurrency and batching. It also adds 'cascades through all providers' for further specificity.
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?
The description implies usage for batch enrichment (vs. single lead via 'enrich_lead'), but does not explicitly state when to prefer this tool over others, or when to use the optional 'providers' filter. It clearly states the behavior but lacks exclusion or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich a company by domain. Returns firmographic data without person-level details.
Best for account-level research: industry, size, revenue, description, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Company domain (e.g. "stripe.com"). | |
| api_key | No | Your LeadEnrich API key for usage tracking. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return type (firmographic, no person details) but lacks information on rate limits, auth requirements (api_key param not explained), and whether the operation is destructive. Adds value beyond schema but incomplete.
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?
Two short sentences, front-loaded with purpose. No unnecessary words. Efficiently conveys key information.
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?
Simple tool with output schema provided, so return details are covered. Description states type of data returned. Lacks explanation of api_key usage but overall adequate for a straightforward enrichment tool.
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 already covers both parameters with descriptions. The description only mentions domain implicitly and does not add semantic meaning beyond what schema provides. With 100% schema coverage, baseline 3 is appropriate.
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?
Clearly states the tool enriches a company by domain and returns firmographic data without person-level details. Distinguishes from sibling tools like enrich_lead (person-level) by specifying account-level research.
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?
Explicitly advises best for account-level research, implying use for companies. Contrasts with person-level data, hinting when not to use. However, does not explicitly name alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich a single lead by cascading through Apollo, Clearbit, and Hunter.
Provide at least one of: email, domain, or first_name + last_name + domain. When email is provided, all providers run concurrently for speed. When only domain/name is provided, Apollo runs first to discover the email, then Clearbit + Hunter run concurrently.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Contact email address (best identifier). | ||
| domain | No | Company domain (e.g. "stripe.com"). | |
| first_name | No | Contact's first name (combine with last_name + domain). | |
| last_name | No | Contact's last name. | |
| providers | No | Optional list to limit which providers to use. Default: all configured. | |
| api_key | No | Your LeadEnrich API key for usage tracking. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the cascade order: Apollo first for email discovery, then concurrent Clearbit+Hunter. It explains concurrency when email is provided. This is good behavioral detail. Missing: rate limits, error handling, or whether the operation is safe (read-only). Still, adequately transparent.
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?
Five sentences, well-structured, front-loaded with purpose. Each sentence adds specific information: input requirements, concurrency, cascade logic. No unnecessary words. Efficient and to the point.
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?
Given tool complexity (multiple providers, cascade) and that an output schema exists, the description is largely complete. It covers input constraints and provider behavior. Could mention what the enrichment response looks like (e.g., unified field) but output schema likely covers that. Adequate.
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 coverage is 100%, but the description adds significant meaning beyond the schema. It explains input combinations (email vs. domain+name) and how the cascade changes. This helps the agent understand which parameters to provide together and why. Truly adds value.
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 clearly states it enriches a single lead using Apollo, Clearbit, and Hunter. It distinguishes from siblings: find_email (likely just email lookup), enrich_company (company-level), enrich_batch (batch). The verb 'enrich' combined with resource 'lead' and provider names is specific and unambiguous.
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?
The description provides explicit guidance on required inputs: 'Provide at least one of: email, domain, or first_name + last_name + domain.' It explains provider behavior based on input type. However, it does not explicitly state when not to use this tool or mention alternatives, though the cascade logic helps. Clear usage context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find someone's email address given their name and company domain.
Uses Hunter email-finder first (purpose-built for this), then falls back to Apollo people-match if Hunter doesn't find it.
| Name | Required | Description | Default |
|---|---|---|---|
| first_name | Yes | Contact's first name. | |
| last_name | Yes | Contact's last name. | |
| domain | Yes | Company domain (e.g. "stripe.com"). | |
| api_key | No | Your LeadEnrich API key for usage tracking. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description notably discloses the fallback behavior (Hunter then Apollo). This adds transparency beyond basic functionality, though it omits details like rate limits or error handling.
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?
Two sentences with no wasted words. The key purpose and fallback logic are front-loaded.
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 is complete for a lookup tool: it explains the core function and fallback strategy. An output schema exists, so return values need not be detailed.
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 coverage is 100%, so the schema already documents each parameter. The description adds no new semantic detail beyond restating the purpose.
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 clearly states the tool's action: finding an email address given name and domain. It distinguishes from siblings like enrich_lead, which serve different purposes.
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?
The description indicates when to use: looking up an email by name and domain. It mentions the fallback strategy but does not explicitly state when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check server health and which enrichment providers are configured.
Returns server status, configured providers, cache stats, and connectivity info.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It explains what the tool checks and returns but does not disclose safety profile (e.g., read-only) or other behavioral traits like rate limits or authentication needs.
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?
The description is two efficient sentences, no wasted words. First sentence states action, second lists return items. Well-structured and front-loaded.
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?
For a no-parameter health check with an output schema, the description is largely complete. It could mention if authentication is required, but overall it provides sufficient context for an agent.
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?
There are zero parameters, so baseline is 4. The description adds value by explaining the tool's purpose and output, complementing the empty schema.
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 clearly states the tool checks server health and enrichment provider configuration, and lists specific return values (server status, providers, cache stats, connectivity info). It is distinctly different from sibling tools which focus on enrichment operations.
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?
While no explicit when-to-use vs alternatives is given, the purpose is self-evident: it is a diagnostic tool, contrasting with the enrichment-focused siblings. The context makes usage clear enough.
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.
v0.2.0check_usageenrich_batchenrich_companyenrich_leadfind_emailhealth_checkScored across 6 tools
Each tool serves a distinct purpose: usage checking, batch enrichment, company enrichment, lead enrichment, email finding, and health checking. There is no overlap or ambiguity between tools.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., enrich_lead, find_email, health_check), making them predictable and easy to understand.
With 6 tools, the server covers the essential operations of lead enrichment without unnecessary complexity. Each tool is justified and serves a distinct function.
The tool set provides comprehensive coverage for lead enrichment: single lead enrichment, company enrichment, batch processing, email discovery, along with usage and health monitoring. No obvious gaps in the domain.
Lead enrichment for AI agents: email finder, company enrichment, people data, firmographics.
Company enrichment for AI agents: firmographics, tech stack, headcount, funding, domain emails.
Paid business, people, company, lead, and web intelligence for autonomous AI agents.
B2B lead and company data for AI agents: free audience sizing, search, enrich, emails, phones.
