Skip to main content
Glama
generect

Generect Live API MCP Server

Official
by generect

Preview leads (cheapest paid look)

preview_leads
Read-only

Preview leads at minimal cost to evaluate fit and select prospects for enrichment, avoiding full search expenses on unqualified candidates.

Instructions

Cheap look at the actual people behind a count, before committing to a full search. BILLABLE — about $0.002 per returned row (Tier 0 list price; your account may pay a different rate — call get_balance for your real prices, and read cost.amount_charged in every response for what was actually spent). Preview rows carry a Generect id, so the intended flow is: preview many → pick the few that fit → enrich_lead / generate_email only on those. Per the API contract preview rows are masked (no LinkedIn URL, domain, email or phone); if your account returns more than that, treat it as a bonus and not something to rely on.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoAlias for limit_by.
strictNoFields to match strictly, e.g. ["company_locations"].
compactNoDefault true: return a small per-lead summary (including the Generect `id`, which every later step accepts). Set false for the full raw record (~80 fields) — only worth it when you specifically need skills, education or other deep fields.
keywordsNoFree-text keywords across headline/summary/skills — realtime only: using it forces the pricier live mode.
limit_byNoRows to return this call (1–100, default 25). You are billed per returned row, so this number IS the price of the call.
personasNoAdvanced raw persona tuples [name, functions, seniorities, prohibits, priority?] — realtime only: using it forces the pricier live mode.
functionsNoJob functions, e.g. ["Sales","Marketing","Engineering"] — realtime only: using it forces the pricier live mode.
job_titleNoDEPRECATED alias for job_titles. Still honoured: it is merged into job_titles.
locationsNoWhere the lead lives — matches cities, states and countries, e.g. ["United States","Berlin"].
offset_byNoRows to skip (pagination).
company_idNoAnchor to one company by LinkedIn numeric id.
count_onlyNoReturn just how many leads the preview index holds for these filters and spend nothing. Free. This is a second opinion on count_leads: preview and cached search are different indexes and can disagree.
job_titlesNoTarget job titles, OR-matched (e.g. ["CEO","Founder","Owner"]). A lead needs to match only one.
timeout_msNoRequest timeout in milliseconds.
exclude_idsNoSkip leads by Generect/Sales-Navigator id. Pass the ids you already received to paginate without duplicates — ordering is not stable, so this is more reliable than offset.
senioritiesNoSeniority at the current employer, e.g. ["Owner","CXO","VP","Director","Manager"]. Current position only.
changed_jobsNoOnly leads who recently changed jobs — realtime only: using it forces the pricier live mode.
company_linkNoAnchor to one company by LinkedIn URL.
company_nameNoAnchor to one company by name (exclusive with company_link/company_id).
company_typesNoEmployer types: "Public Company","Privately Held","Non Profit","Government Agency","Educational","Self Employed","Self Owned","Partnership".
exclude_namesNoSkip leads by full name. KNOWN ISSUE: in database mode any non-empty value collapses the result set to 0 (verified 2026-08-09); it behaves correctly in realtime mode. Prefer exclude_ids, or filter names out yourself after the search.
get_max_leadsNoDEPRECATED — accepted but ignored. Always on now: search responses include results_count without asking.
company_filtersNoOptional company-level filters for a two-level ICP.
lead_industriesNoDEPRECATED — accepted but ignored. Removed: v1 filters on the employer's industry. Use company_industries.
without_companyNoDEPRECATED — accepted but ignored. No longer needed — v1 filter-only search is the default when no company anchor is set.
years_in_companyNoTime at current company, same buckets as years_in_position — realtime only: using it forces the pricier live mode.
company_locationsNoHQ location of the lead's current employer.
confirm_spend_usdNoExplicit approval for an unusually large charge. Calls whose worst case exceeds $5 are refused unless this is set to at least the amount the tool reports. Only set it after the user has agreed to that number.
exclude_locationsNoLead locations to exclude.
filter_empty_varsNoDrop leads where these fields are empty, e.g. ["profile_photo","job_started_on"]. Useful to raise data quality before paying.
years_in_positionNoTime in current role: 1=<1y, 2=1-2y, 3=3-5y, 4=6-10y, 5=10y+ — realtime only: using it forces the pricier live mode.
company_headcountsNoEmployer size buckets. Allowed ONLY: "1-10","11-50","51-200","201-500","501-1000","1001-5000","5001-10000","10 000+" (note the space in "10 000+").
company_industriesNoIndustry of the current employer. Must match Generect industry names exactly (e.g. "Software Development", "Financial Services"); names are hierarchical and unknown names are rejected with HTTP 400 naming the field.
past_company_namesNoCompanies the lead previously worked at (alumni targeting) — realtime only: using it forces the pricier live mode.
posted_on_linkedinNoOnly leads who recently posted on LinkedIn — realtime only: using it forces the pricier live mode.
linkedin_filter_linkNoA LinkedIn / Sales Navigator search URL to lift filters from — realtime only: using it forces the pricier live mode.
allow_unlisted_valuesNoEscape hatch. This server checks industry / seniority / headcount / company-type values against the LinkedIn vocabularies before sending, because the API silently returns 0 results for an unknown industry or seniority instead of rejecting it. Set true only when you are sure a value is valid and this server is out of date.
exclude_title_keywordsNoDEPRECATED — accepted but ignored. No v1 equivalent. Narrow job_titles instead, or filter the returned rows yourself.
exclude_company_locationsNoEmployer HQ locations to exclude.
exclude_company_headcountsNoEmployer size buckets to exclude.
exclude_company_industriesNoEmployer industries to exclude.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
fixNo
costNo
modeNo
noteNo
leadsNo
statusNo
returnedNo
companiesNo
test_modeNo
spend_guardNo
results_countNo
next_page_argsNo
requested_rowsNo
escalation_noteNo
test_mode_noticeNo
vocabulary_warningsNo
blocked_by_vocabularyNo
deprecated_params_ignoredNo
escalated_to_realtime_becauseNo
api_returned_more_than_requestedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description correctly aligns. Beyond that, it discloses key behaviors: it is billable (~$0.002 per row), rows are masked per API contract, certain parameters force a pricier realtime mode, the preview index may disagree with the cached search index, and there is a known bug with exclude_names in database mode. This is substantial transparency that goes well beyond the annotations.

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?

The description is two paragraphs and moderately long, but every sentence adds meaningful context (cost, masking, intended flow, known issue). It front-loads the core purpose and cost model. It is not bloated given the tool's complexity (41 params, multiple modes). The only minor deduction is that it could be tightened, but the density of information justifies the length.

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?

Given the tool's complexity, the description covers the essential context: cost model, data masking, intended workflow, realtime vs database mode, and a known bug. It also clarifies the relationship to count_leads and mentions the free count_only option. The output schema exists, so return details are not required. Nothing an agent needs to call this correctly is missing.

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?

The schema description coverage is 100%, so the schema already documents all 41 parameters. The tool description does not add parameter-specific semantics; it focuses on the overall flow, cost, and masking. Since the baseline for 100% coverage is 3, and the description does not attempt to compensate or add extra parameter context, a 3 is appropriate.

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 states a specific verb ('preview') and resource ('leads'), and immediately contrasts it with a count ('the actual people behind a count') and with a full search ('before committing to a full search'). It clearly differentiates from siblings like count_leads and search_leads, and even names the intended follow-up tools (enrich_lead, generate_email). This is unambiguous.

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?

The description gives strong usage context: use it as a cheap pre-filter before committing to a full search, and specifically to decide which leads to enrich. It also warns about masked rows and suggests treating extra fields as a bonus, which guides expectations. It does not explicitly name alternatives like search_leads or say 'use search_leads when you need full contact details,' but the intended flow is clear. It also mentions count_only as a free second opinion on count_leads, which is a useful distinction.

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