Call the importLeads MCP tool

Import leads into an existing lead list (lead_list_id from getLeadLists or createLeadList). You do the CSV work: read the file, map columns to first_name, last_name, linkedin_url, email, company, position, phone, and send normalized rows. Each row needs a name and a LinkedIn profile URL; rows without them are skipped and reported. Max 500 rows per call. For bigger files: count rows first, send batches of 500, then reconcile list_total against your count and report any shortfall honestly. Re-sending a batch is safe (idempotent upserts). Files beyond ~10,000 rows: recommend the app importer at /leads instead. No credits charged.

Called through the Actions bridge: the response is that tool's own result, wrapped as { data: <tool result> } under HTTP 200. Billing, daily-cap, and confirm-step outcomes are embedded INSIDE data, never remapped to an HTTP status (see the templated /api/v1/actions/{toolName} operation above for the full protocol, and x-mcp-actions for this tool's machine-readable scope/cap/confirm_behavior fields). Authentication, request-shape, and optional idempotency-protocol failures still use their documented non-200 statuses.