Generect Live API MCP Server

Official

by generect

Overview Schema Source Related Servers Discussions(1)Admin

TypeScript

Hybrid

Count matching leads (free)

count_leads

Read-onlyIdempotent

Estimate how many leads match your ideal customer profile and what pulling them would cost. Check audience size before running a paid lead search to avoid unexpected expenses.

Instructions

How many leads match an ICP, and what pulling them would cost. FREE — this call never spends credits. ALWAYS CALL THIS BEFORE search_leads: it is the only way to learn the size of an audience without paying per row, and it returns a cost estimate for the next step at this account's real rates. A realtime count is NOT free ($0.02 flat) — this tool refuses to run one unless you pass mode:"realtime" on purpose.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	No	Data mode. "database" = cached, sub-second, cheaper, free counts, core filters only. "realtime" = live LinkedIn lookup, 5–60s, pricier, supports every filter. "auto" (default) tries database first and only escalates to realtime if a filter you passed is unsupported there — an escalation is reported in the response. Pick "database" explicitly when you only need a size estimate and cost matters more than freshness.
`strict`	No	Fields to match strictly, e.g. ["company_locations"].
`keywords`	No	Free-text keywords across headline/summary/skills — realtime only: using it forces the pricier live mode.
`personas`	No	Advanced raw persona tuples [name, functions, seniorities, prohibits, priority?] — realtime only: using it forces the pricier live mode.
`functions`	No	Job functions, e.g. ["Sales","Marketing","Engineering"] — realtime only: using it forces the pricier live mode.
`job_title`	No	DEPRECATED alias for job_titles. Still honoured: it is merged into job_titles.
`locations`	No	Where the lead lives — matches cities, states and countries, e.g. ["United States","Berlin"].
`company_id`	No	Anchor to one company by LinkedIn numeric id.
`job_titles`	No	Target job titles, OR-matched (e.g. ["CEO","Founder","Owner"]). A lead needs to match only one.
`timeout_ms`	No	Request timeout in milliseconds.
`exclude_ids`	No	Skip 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.
`seniorities`	No	Seniority at the current employer, e.g. ["Owner","CXO","VP","Director","Manager"]. Current position only.
`changed_jobs`	No	Only leads who recently changed jobs — realtime only: using it forces the pricier live mode.
`company_link`	No	Anchor to one company by LinkedIn URL.
`company_name`	No	Anchor to one company by name (exclusive with company_link/company_id).
`company_types`	No	Employer types: "Public Company","Privately Held","Non Profit","Government Agency","Educational","Self Employed","Self Owned","Partnership".
`exclude_names`	No	Skip 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_leads`	No	DEPRECATED — accepted but ignored. Always on now: search responses include results_count without asking.
`company_filters`	No	Optional: count leads only at companies matching these company filters (a two-level ICP). Still free in database mode.
`lead_industries`	No	DEPRECATED — accepted but ignored. Removed: v1 filters on the employer's industry. Use company_industries.
`without_company`	No	DEPRECATED — accepted but ignored. No longer needed — v1 filter-only search is the default when no company anchor is set.
`years_in_company`	No	Time at current company, same buckets as years_in_position — realtime only: using it forces the pricier live mode.
`company_locations`	No	HQ location of the lead's current employer.
`exclude_locations`	No	Lead locations to exclude.
`filter_empty_vars`	No	Drop leads where these fields are empty, e.g. ["profile_photo","job_started_on"]. Useful to raise data quality before paying.
`years_in_position`	No	Time 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_headcounts`	No	Employer 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_industries`	No	Industry 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_names`	No	Companies the lead previously worked at (alumni targeting) — realtime only: using it forces the pricier live mode.
`posted_on_linkedin`	No	Only leads who recently posted on LinkedIn — realtime only: using it forces the pricier live mode.
`linkedin_filter_link`	No	A LinkedIn / Sales Navigator search URL to lift filters from — realtime only: using it forces the pricier live mode.
`allow_unlisted_values`	No	Escape 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_keywords`	No	DEPRECATED — accepted but ignored. No v1 equivalent. Narrow job_titles instead, or filter the returned rows yourself.
`exclude_company_locations`	No	Employer HQ locations to exclude.
`exclude_company_headcounts`	No	Employer size buckets to exclude.
`exclude_company_industries`	No	Employer industries to exclude.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`fix`	No
`why`	No
`cost`	No
`mode`	No
`advice`	No
`status`	No
`options`	No
`test_mode`	No
`results_count`	No
`needs_realtime`	No
`test_mode_notice`	No
`next_step_estimate`	No
`vocabulary_warnings`	No
`blocked_by_vocabulary`	No
`deprecated_params_ignored`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.9.0Sep 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and idempotentHint, but the description adds substantial behavioral context beyond those: the free cost guarantee, the cost estimate return, the realtime mode's refusal unless explicitly requested, and the known exclude_names bug in database mode (though that is in a parameter description, it signals the description cares about edge behavior). No contradictions with 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 front-loaded with the core purpose and cost statement, then expands into usage guidance. It is a few sentences long but every clause earns its place—no filler. The structure is effective for the tool's complexity, though it could be tightened slightly without losing information.

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 has an output schema (so return format is already specified) and a rich input schema, the description covers all the essential usage context: when to call, what it returns (count + cost estimate), the free/paid distinction, and the realtime caveat. For a 36-parameter tool, this is more than sufficient; an agent has everything needed to invoke it correctly.

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 the schema already documents every parameter in detail. The tool description does not add meaning to individual parameters beyond what the schema provides—its focus is on the tool-level cost and mode semantics. Per the rubric, high schema coverage yields a baseline of 3; the description adds no extra param-level insight to warrant higher.

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 clear verb-resource-scope statement ('How many leads match an ICP, and what pulling them would cost') and immediately distinguishes itself from the sibling search_leads by stating it is the only free way to learn audience size. The 'FREE — this call never spends credits' line leaves no ambiguity about what the tool does and how it differs from alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs when to use this tool ('ALWAYS CALL THIS BEFORE search_leads'), explains why (learn audience size without paying per row), and describes the alternative (search_leads). It also clarifies the conditional realtime mode and its non-free cost, giving the agent precise decision criteria.

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

Deploy Server