Lead File Import Checker MCP Server

Check a lead file before import

check_lead_file

Read-onlyIdempotent

Validate lead rows from a JSON array, public CSV, or Apify dataset before CRM or sequencer import. Returns per-row import, review, or reject verdicts with detected issues and check details.

Instructions

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.

Input Schema

Name	Required	Description
`rows`	No	Lead rows as objects with any column names, up to 50,000. Give rows, csv_url, or dataset_id, one of them.
`checks`	No	Which checks to run. Default all.
`csv_url`	No	A public link to a CSV file with a header row, up to 50 MB.
`max_rows`	No	Check at most this many rows. Default 5000, at most 50000.
`column_map`	No	Which 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_id`	No	An Apify dataset ID from one of your runs.
`stale_days`	No	With a date column in column_map, rows older than this many days get the stale issue.
`check_websites`	No	true (default) reads each company homepage once for the live, parked, and company name checks.
`max_charge_usd`	No	Optional. The run stops before a charge would pass this amount.
`required_fields`	No	Fields a row must have, or it is rejected. Default email.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 1, 2026

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.

Deploy Server

Other Tools

check_lead_fileA