SalesQL

View saved version →

---
name: find-leads
description: 'End-to-end lead prospecting with SalesQL. Research a business''s ideal customer profile (ICP), translate it into SalesQL search filters, find matching people, and reveal emails (with verification status) and phone numbers. Use this whenever the user wants to find leads, prospects, potential customers, or contacts for a business — even if they only give a company description, a website URL, or a vague ask like "who should I sell this to?". Also use it when the user mentions ICP research, building a lead list, or filling a pipeline.'
---

# Find Leads

Turn a business description or website URL into a list of qualified leads with contact data, using the SalesQL MCP tools.

The input is the user's request: either a description of their business ("we sell payroll software for restaurants in the US") or a URL to research. If the request names no business, product, or URL, ask what business or product they want to find leads for before doing anything else.

Explicit instructions from the user take priority over the defaults in this workflow. For example, a user who already gives exact titles, locations, and company sizes can skip the ICP draft, and a user who asks for a different output format gets that format. Consent to spend credits is the one thing never to assume: only call `enrich_person` or `enrich_person_bulk` for leads the user has approved. A request that names the specific people to reveal, or explicitly asks you to reveal results without showing a shortlist first, counts as that approval.

## Why this order matters

In this workflow, SalesQL charges credits only when revealing real contact data (`enrich_person` or `enrich_person_bulk`). Everything before that — resolving filters, searching, browsing obfuscated results — is free. So the workflow front-loads all the free research and iteration, and only spends credits at the very end, on leads the user has approved. Never invert this: enriching before the user confirms the list wastes their credits on contacts they may not want.

## Step 1 — Understand the business

If the request contains a URL and you can browse the web, open it (and, if needed, one or two obvious subpages like /pricing or /customers) to understand what the company sells, to whom, and at what price point. If you cannot browse, ask the user to describe the business in a sentence or two. If it's a description, work from that, supplementing with web research (when available) only when the description is too thin to infer a customer profile.

From this, draft an ideal customer profile (ICP):

- **Job titles** of the buyer and/or decision maker (include synonyms and seniority variants — "Head of Sales", "VP Sales", "Sales Director")
- **Industries** of the target companies
- **Geography**: where the target companies are based (countries, and states/cities if the business is regional) and, only if it also matters, where the people must live
- **Company size** (employee ranges) and, when relevant, **company type** (private, public, nonprofit…)

Present the ICP to the user in a short summary and ask them to confirm or adjust it before searching. This checkpoint is cheap and prevents an entire search built on a wrong assumption.

## Step 2 — Resolve filter values with `lookup`

`search_people` rejects guessed identifiers. Industry values are slugs, and country/region values are opaque UUIDs — they cannot be invented or translated. Resolve every non-free-text filter through `lookup` first:

| ICP dimension | `lookup` type | `search_people` field(s) |
| --- | --- | --- |
| Industry | `industry` | `industries`, `organization_industries` |
| Country | `country` | `countries`, `organization_countries` |
| State / city | `region` | `states_or_cities`, `organization_states_or_cities` |
| Company size | `company_size` | `organization_employee_ranges` |
| Company type | `company_type` | `organization_company_types` |

Pass the `q` parameter for the fuzzy-searched types (`industry`, `coun

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.