HeyLead

Overview Schema Source Related Servers Discussions Admin

import_prospects

Destructive

Import prospects from CSV or XLSX files into a campaign, deduplicating existing contacts and scoring each lead for outreach.

Instructions

Import prospects from a CSV/XLSX file into a campaign.

Point HeyLead at a .csv or .xlsx file (or paste CSV text) and it will parse
it, deduplicate against existing contacts and LinkedIn connections, score
each prospect, and add them to the campaign for outreach. Every row of the
file gets a disposition — imported, skipped:<reason>, or deduped-against a
specific earlier row — and the totals are reconciled against the file's row
count, so a partial import can never be reported as a success.

Supports CSV import, XLSX/spreadsheet import, bulk prospect upload, lead
list import, and contact list management for LinkedIn outreach campaigns.

Args:
    campaign_id: Campaign to import into. Leave empty for the most recent.
    csv_data: CSV text with headers. Only use for a handful of rows —
        prefer file_path, which has no size limit. Ignored if file_path
        is given.
    linkedin_enrich: If true, fetch full LinkedIn profiles for imported
        prospects (slower but better personalization). Default: false.
    file_path: Path to a .csv or .xlsx file on disk. Preferred over
        csv_data — a large lead list must never be pasted through this
        argument, since anything that does not fit is silently lost.
    sheet: Worksheet name for .xlsx files. Defaults to the first sheet.
    dry_run: If true, report the full per-row disposition without creating
        any contacts or outreaches and without fetching any LinkedIn
        profiles — linkedin_enrich is not run. Your own connection list is
        still read, so the preview matches the real import. Default: false.

Columns are auto-detected (case-insensitive): Name, Title, Company,
LinkedIn URL, Email, Location. Each row needs Name + at least one of
Title, Company, or LinkedIn URL.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`sheet`	No
`dry_run`	No
`csv_data`	No
`file_path`	No
`campaign_id`	No
`linkedin_enrich`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.10.375Sep 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Despite annotations marking destructiveHint=true, the description goes further: it discloses that every row gets a disposition, partial imports are never reported as success, csv_data silently loses data that doesn't fit, and dry_run skips LinkedIn enrichment while still reading the connection list. This adds significant context beyond the annotations and prepares the agent for 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is organized with a clear intro paragraph followed by a bulleted Args list. Every sentence serves a purpose: it explains the import pipeline, the disposition guarantees, and the parameter semantics. The structure front-loads the core purpose and then drills into specifics, with no redundant filler.

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?

The tool has an output schema (not shown here) that presumably covers return values, so the description doesn't need to detail them. For everything else an agent needs to call this correctly, the description covers: input formats, column requirements, deduplication behavior, dry-run semantics, and the trade-offs between csv_data and file_path. It is complete for a complex import operation.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the entire burden for parameter meaning. It does so thoroughly: each parameter (campaign_id, csv_data, linkedin_enrich, file_path, sheet, dry_run) gets a purpose, a default, and usage nuance. For instance, it clarifies that csv_data is ignored if file_path is given and that sheet defaults to the first worksheet. This fully compensates for the schema's lack of descriptions.

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 opens with a specific verb and resource: 'Import prospects from a CSV/XLSX file into a campaign.' It then explains the full pipeline (parse, dedupe, score, add) and distinguishes itself from siblings by focusing on bulk ingestion. This leaves no ambiguity about what the tool does.

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?

It gives clear guidance on parameter choices: 'prefer file_path' over csv_data, csv_data for 'a handful of rows', and dry_run for previewing without side effects. It does not explicitly name alternative tools for other use cases, but the context of campaign management makes the intended usage clear. The exclusion of large paste-through is explicit ('must never be pasted').

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