Skip to main content
Glama
Sign In
Lead File Import Checker MCP Server

Lead File Import Checker MCP Server

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Lead File Import Checker MCP Server

npm version license

An MCP server for the Mamba Labs Lead File Import Checker actor on Apify. Give it lead rows, a CSV link, or an Apify dataset. Every row comes back with an import, review, or reject verdict and the issues behind it, so only clean rows reach your CRM or sequencer.

What's Inside

Related MCP server: dvq

What it does

Checks per row: email syntax, duplicates (the way inboxes see them, so Jane+x@Stripe.com matches jane@stripe.com), free mail, role inboxes, disposable domains, DNS and MX for the email domain, one homepage read per company domain for live, parked, and company name checks, missing required fields, and stale dates. It does not verify mailboxes and never contacts a mail server. All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.

Quick start

You need Node.js 18 or newer and an Apify account with an API token.

Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:

{
  "mcpServers": {
    "mamba-lead-file-import-checker": {
      "command": "npx",
      "args": [
        "-y",
        "@mambalabsdev/mcp-lead-file-import-checker"
      ],
      "env": {
        "APIFY_TOKEN": "your-apify-token"
      }
    }
  }
}

Restart the client. The check_lead_file tool appears.

Prerequisites

Example prompts

  • "Check this lead CSV and give me only the rows marked import."

  • "How many duplicates and role addresses are in this list?"

  • "Which of these companies have a parked or dead website?"

Tool

check_lead_file. One tool. Example arguments:

{
  "rows": [
    { "Email": "jane@stripe.com", "Company": "Stripe" },
    { "Email": "info@gong.io", "Company": "Gong" }
  ]
}

Inputs

Every buyer facing input of the actor, unchanged. Omitted inputs take the actor's own defaults. Numbers and yes or no options are sent as strings.

Input

Type

Description

rows

array

Lead rows as objects, up to 50,000

csv_url

string

A public CSV link, up to 50 MB

dataset_id

string

An Apify dataset ID

column_map

object

Which column holds each field

required_fields

array

Fields a row must have. Default email

checks

array

Which checks to run. Default all

check_websites

string

true (default) or false

stale_days

string

Days before a dated row is stale

max_rows

string

Default 5000, at most 50000

max_charge_usd

string

Optional cost cap for the run

Pricing

Pay per event on Apify, billed to your Apify account. Prices in USD.

Event

Free plan

Bronze

Silver

Gold

row-checked, per row of your file checked

$0.002

$0.0019

$0.0018

$0.0017

apify-actor-start, per run start

$0.001

$0.001

$0.001

$0.001

Blank rows, rows over max_rows, and the one row a refused input writes are free.

Your keys

The actor needs no key and holds none. It reads DNS and the companies' own homepages. Mamba Labs pays the platform costs of the run.

Full actor documentation

apify.com/mambalabs/lead-file-import-checker

License

MIT. See LICENSE.

Available Tools

1 tool
check_lead_fileCheck a lead file before importA
Read-onlyIdempotent

Check a lead list before a CRM or sequencer import. Give one source: rows (a JSON array of objects), csv_url (a public CSV link), or dataset_id (an Apify dataset). Every row comes back with an import_verdict (import, review, or reject), the issues found (invalid email syntax, duplicate, free mail, role address, disposable address, email domain not found or with no MX, parked or unreachable website, company name mismatch, missing required field, stale), and the checks behind them, plus the original row. No mailbox is contacted, so a mailbox can still bounce. Input with nothing to check returns one free row saying why. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN; Apify charges per row checked.

NameRequiredDescriptionDefault
rowsNoLead rows as objects with any column names, up to 50,000. Give rows, csv_url, or dataset_id, one of them.
checksNoWhich checks to run. Default all.
csv_urlNoA public link to a CSV file with a header row, up to 50 MB.
max_rowsNoCheck at most this many rows. Default 5000, at most 50000.
column_mapNoWhich of your columns holds email, domain, company, first_name, last_name, and date, for example {"email": "Work Email"}. Without it common header names are read.
dataset_idNoAn Apify dataset ID from one of your runs.
stale_daysNoWith a date column in column_map, rows older than this many days get the stale issue.
check_websitesNotrue (default) reads each company homepage once for the live, parked, and company name checks.
max_charge_usdNoOptional. The run stops before a charge would pass this amount.
required_fieldsNoFields a row must have, or it is rejected. Default email.

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already flag readOnly/idempotent/non-destructive, and the description layers on genuinely non-obvious behavior: no mailbox is contacted so a bounced address can still pass, empty input returns a free explanatory row, failed runs come back as errors with a run ID, an APIFY_TOKEN is required, and Apify charges per row. That is exactly the context annotations cannot carry.

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?

Front-loaded with purpose and input rule, then return shape, then caveats. The long middle sentence enumerating issue types is dense but each clause is informative; nothing is decorative.

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

Completeness5/5

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

For a 10-parameter, nested-input, no-output-schema tool, the description covers input exclusivity, return payload shape, error behavior, auth, and cost. An agent could call this correctly and interpret the result without further information.

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%, so every parameter is already documented, including the one-source rule and column_map examples. The description mostly restates that at a higher level and adds the vocabulary of issue types, but contributes no syntax or format detail the schema lacks; 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?

States a specific verb and resource ('Check a lead list') and frames it in its real context ('before a CRM or sequencer import'). The description then enumerates what a check produces (import_verdict, issues, underlying checks), so an agent knows exactly what capability is on offer.

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

Usage Guidelines4/5

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

Gives concrete invocation context: supply exactly one of rows, csv_url, or dataset_id, and notes the empty-input behavior. There are no sibling tools to disambiguate against, so the only gap is that it doesn't discuss when a caller should skip this tool.

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.

  1. 1 tool updatev1.0.0
    • First observedcheck_lead_file
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.5/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusing it with another tool. Its purpose—checking a lead file before import—is clearly stated and distinct.

Naming Consistency5/5

The single tool name check_lead_file follows a clear verb_noun snake_case convention. There are no conflicting naming styles to create inconsistency.

Tool Count4/5

A single comprehensive tool is reasonable for this narrow, read-only checking purpose, since it bundles all input sources and outputs. However, the surface is thin compared with typical multi-tool servers, which slightly limits composability.

Completeness5/5

The tool covers the full checking workflow: multiple input sources, per-row verdicts, detailed issue categories, original-row return, and error handling. No obvious operation is missing for a pre-import lead checker.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • B2B Lead Quality Scorer MCP

    FoundryNet
    A
    license
    Not graded
    quality
    F
    maintenance
    Validates email deliverability, assesses domain credibility, and scores B2B leads from A-F to help prioritize outreach, with batch processing and a free tier.
    MIT

  • dvq

    contentforge-press
    A
    license
    Not graded
    quality
    A
    maintenance
    Exposes data validation as tools so an AI agent can check whether data is actually correct before using it, scoring CSV files with per-row problem details, catching impossible dates, inferring schemas, and generating readable reports.
    41 npm
    MIT

  • Lead Cleanup MCP Lite

    digitalsolutionsmagic
    A
    license
    A
    quality
    C
    maintenance
    Enables users to clean and de-duplicate sales lead lists locally without API keys or network calls. It normalizes names, emails, phone numbers, and website domains, drops invalid emails, removes duplicate leads by email, and validates email formatting.
    2
    MIT

  • Email Verifier MCP Server

    mambalabsdev
    A
    license
    A
    quality
    B
    maintenance
    Enables verification of email address lists through a chosen third-party service (ZeroBounce, NeverBounce, MillionVerifier, BounceBan, or Reoon), returning one normalized row per address with verdict and role, free, and disposable flags. It protects credits by skipping malformed or duplicate addresses and stopping runs on invalid keys or exhausted balances.
    1
    274 npm
    MIT