generect-mcp
Server Details
B2B lead and company data for AI agents: free audience sizing, search, enrich, emails, phones.
- Status
- Healthy
- Uptime
- 55.5% over 41 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- Repository
- generect/generect_mcp
- GitHub Stars
- 1
- Server Listing
- Generect Live API MCP Server
TDQS
Scored across 17 tools
The entity-specific pairs (companies vs leads) and action verbs make most tools clearly distinct. The main overlap is get_lead_by_url, which is explicitly documented as an alias for enrich_lead, and preview_leads vs search_leads could be confused but their descriptions clearly separate cost and purpose.
Nearly every tool follows a snake_case verb_noun pattern (count_companies, enrich_lead, generate_email, start_bulk_job). The exceptions are health, which is a plain noun, and get_lead_by_url, which is slightly more verbose than the standard pattern.
17 tools is slightly above the ideal 3-15 range, but the surface covers companies, leads, contact discovery, validation, bulk processing, webhooks, and billing. It feels only marginally heavy, and the redundant get_lead_by_url alias is the main reason it is not a 5.
The set covers the full lead-generation lifecycle: count, search, preview, enrich, email/phone discovery, validation, bulk jobs, and webhook management, plus balance and health checks. There are no obvious dead ends or missing operations for the domain.
Available Tools
17 toolscount_companiesCount matching companies (free)ARead-onlyIdempotentInspect
How many companies match an ICP, and what pulling them would cost. FREE — this call never spends credits. Call this before search_companies. As with count_leads, a realtime count costs $0.02 and is never run implicitly.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| keywords | No | Free-text keywords across name/description/specialties — realtime only: using it forces the pricier live mode. | |
| locations | No | HQ locations — cities, states or countries. | |
| headcounts | No | Size buckets. Allowed ONLY: "1-10","11-50","51-200","201-500","501-1000","1001-5000","5001-10000","10 000+". | |
| industries | No | Company industries. Must match Generect industry names exactly (e.g. "Software Development"); unknown names are rejected with HTTP 400. | |
| timeout_ms | No | Request timeout in milliseconds. | |
| exclude_ids | No | Exclude companies by LinkedIn id/URN. | |
| technologies | No | Technologies the company uses — realtime only: using it forces the pricier live mode. | |
| company_names | No | Restrict to specific company names — realtime only: using it forces the pricier live mode. | |
| company_types | No | Company types: "Public Company","Privately Held","Non Profit","Government Agency","Educational", … | |
| revenues_range | No | Annual revenue range, single object {min,max} — realtime only: using it forces the pricier live mode. | |
| sub_industries | No | Expand each selected industry to its sub-industries as well (broadens the match). | |
| exclude_domains | No | Exclude companies by domain (e.g. existing customers). | |
| linkedins_links | No | Specific LinkedIn company URLs — realtime only: using it forces the pricier live mode. | |
| headcount_growth | No | Headcount growth in percent — realtime only: using it forces the pricier live mode. | |
| num_of_followers | No | LinkedIn follower buckets: "1-50","51-100","101-1000","1001-5000","5001+" — realtime only: using it forces the pricier live mode. | |
| exclude_locations | No | HQ locations to exclude. | |
| get_max_companies | No | DEPRECATED — accepted but ignored. Always on now: search responses include results_count without asking. | |
| exclude_industries | No | Industries to exclude. | |
| hiring_on_linkedin | No | Only companies actively hiring — realtime only: using it forces the pricier live mode. | |
| fallback_from_leads | No | DEPRECATED — accepted but ignored. Removed. It fabricated lead-derived name aggregates and cost an extra billable query. | |
| department_headcount | No | Department size, e.g. {"name":"engineering","min":10,"max":100} — realtime only: using it forces the pricier live mode. | |
| allow_unlisted_values | No | Escape hatch for the local vocabulary check — see the lead-side field of the same name. |
Output Schema
| Name | Required | Description |
|---|---|---|
| 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 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the bar for adding behavioral context is lower. The description adds valuable cost transparency beyond annotations: 'FREE — this call never spends credits' and 'a realtime count costs $0.02 and is never run implicitly'. This is useful, non-obvious behavior that helps the agent make cost-aware decisions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The first sentence front-loads the core purpose and cost, the second adds the free guarantee, and the third gives the ordering guidance. Every clause earns its place; no redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the input schema is fully documented, the description needs only to cover the non-schema context. It covers the critical decision factors: cost (free vs $0.02), the recommended call order, and the fact that realtime is never implicit. This is complete for an agent to correctly choose and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all 23 parameters with rich detail (including which ones force realtime mode). The description itself adds no parameter-level semantics beyond the schema, so the baseline of 3 is appropriate. No additional parameter meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'How many companies match an ICP', clearly distinguishing it from search_companies (which would return records) and count_leads (which counts leads). The first sentence also adds the unique value of 'what pulling them would cost', making the tool's role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives the primary use case: 'Call this before search_companies', which is clear and actionable. It also references count_leads as a sibling for cost behavior, but does not explicitly state when to prefer count_leads over this tool or vice versa. The ordering guidance is strong, and cost implications are mentioned, so this is above average but not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
count_leadsCount matching leads (free)ARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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
| Name | Required | Description |
|---|---|---|
| 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 |
TDQS
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.
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.
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.
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.
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.
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.
enrich_companyEnrich one companyARead-onlyInspect
Full profile for ONE known company, by Generect id, LinkedIn URL, domain, or name. BILLABLE — about $0.0067 per record found (not-found is refunded) (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). Not found costs nothing. Domain is the most reliable identifier after id; name matching is fuzzy.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Generect company id. | |
| 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 a recent cached record is good enough and cost matters more than freshness. | |
| name | No | Company name (fuzzy match). | |
| domain | No | Company domain without protocol, e.g. "stripe.com". | |
| compact | No | Default true: return a small per-company 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. | |
| timeout_ms | No | Request timeout in milliseconds. | |
| linkedin_url | No | LinkedIn company page URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | No | |
| lead | No | |
| mode | No | |
| found | No | |
| company | No | |
| test_mode | No | |
| test_mode_notice | No | |
| vocabulary_warnings | No | |
| deprecated_params_ignored | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint/openWorldHint annotations, the description discloses billability, approximate per-record cost, refund behavior for not-found records, the existence of different account rates, and the pointer to get_balance for real pricing. It also surfaces the database-vs-realtime mode behavior and cost differences via parameter context, adding substantial behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense, purposeful sentences: the first front-loads the core purpose and inputs, the second packs billing and reliability guidance without filler. Every clause carries decision-relevant information for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The rich schema, annotations, and output schema cover parameter details and return structure. The description completes the picture with purpose, billing, and identifier reliability. A minor gap is that it never explicitly states that at least one identifier must be provided, though that is strongly implied by the phrasing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% parameter description coverage, so the baseline is 3. The description adds extra semantic value by ranking identifier reliability (domain after id), noting that name matching is fuzzy, and explaining cost implications per lookup. This goes beyond simply restating schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Full profile for ONE known company', naming the exact verb, resource, and accepted identifiers (Generect id, LinkedIn URL, domain, or name). This clearly distinguishes it from sibling list/search tools like search_companies or count_companies by emphasizing a single known company rather than discovery or aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool is for enriching one already-known company, and it offers identifier reliability guidance ('Domain is the most reliable identifier after id; name matching is fuzzy'). It doesn't explicitly name alternative tools or state when not to use this tool, but the single-record enrichment context is strong enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
enrich_leadEnrich one leadARead-onlyInspect
Full profile for ONE known person, by Generect id, LinkedIn URL, or work email (reverse lookup). BILLABLE — about $0.0067 per record found (not-found is refunded) (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). Not found costs nothing. Prefer the id from a search/preview result — it is the most accurate identifier. For many people at once use start_bulk_job.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Generect lead id from search/preview. | |
| 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 a record from the last 12 months is good enough and cost matters more than freshness. | |
| No | Work email, for reverse lookup. | ||
| compact | No | Default 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. | |
| timeout_ms | No | Request timeout in milliseconds. | |
| linkedin_url | No | LinkedIn profile URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | No | |
| lead | No | |
| mode | No | |
| found | No | |
| company | No | |
| test_mode | No | |
| test_mode_notice | No | |
| vocabulary_warnings | No | |
| deprecated_params_ignored | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, covering safety and external data scope. The description adds valuable behavioral context: billing details ($0.0067 per found record, not-found refunded), cost guidance (call get_balance, read cost.amount_charged), and the 'prefer id' accuracy note. It does not disclose potential latency for realtime mode (that's in the schema) or failure behavior, but the cost disclosure goes beyond annotations and meaningfully informs the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, then cost, then guidance. It is efficient with no filler—every sentence adds functional information. It is slightly longer than necessary due to the billing detail, but that detail is decision-relevant. Structure is logical: purpose → cost → identifier preference → bulk alternative. A 5 would require even tighter phrasing without losing the cost nuance, but this is well above average.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, an output schema, and rich annotations, the description covers the essential context: single-person scope, identifier options, cost behavior, and the bulk alternative. It does not describe the response format, but the presence of an output schema covers that. It also does not explicitly mention the mode escalation behavior (only in the schema), but that is adequately captured in parameter descriptions. For an agent to call this correctly, the description plus schema provides sufficient guidance, with minor gaps in distinguishing from closely related tools like resolve_profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each of the six parameters is already documented (id, mode, email, compact, timeout_ms, linkedin_url). The description adds the 'prefer id' recommendation and clarifies email is for reverse lookup, but these are marginal additions over the schema. The baseline of 3 is appropriate because the schema carries the primary semantic weight and the description does not need to compensate for missing parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('enrich') and resource ('one known person') with three precise identifier types (Generect id, LinkedIn URL, work email). It explicitly differentiates from bulk operations by naming start_bulk_job as the alternative for many people, and its phrasing 'Full profile for ONE known person' contrasts with search/preview tools. Purpose is unmistakable and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: for a single known person, and when not to use it ('For many people at once use start_bulk_job'). It also advises preferring the id from search/preview for accuracy. It does not enumerate every sibling alternative (e.g., get_lead_by_url, resolve_profile) but the context of 'known person' and the named bulk fallback provide solid direction. A minor gap: it does not explain when to choose this over resolve_profile or get_lead_by_url, but the identifier focus covers most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_phoneFind a phone number (most expensive)ARead-onlyInspect
Find a phone number for one person. BILLABLE — about $0.4 per phone found (a miss is free) (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). THE MOST EXPENSIVE OPERATION HERE — roughly 20x an email lookup. Do not call it speculatively or across a list; confirm with the user first, and only for people they have already qualified. Use start_bulk_job for an approved list.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Company domain without protocol, e.g. "stripe.com" (name+domain mode). | |
| company | No | Company name or domain (name+company mode). | |
| lead_id | No | Generect lead id from search / preview / enrich results — the cheapest and most accurate identifier. | |
| last_name | No | Last name (name+domain mode). | |
| first_name | No | First name (name+domain mode). | |
| timeout_ms | No | Request timeout in milliseconds. | |
| linkedin_url | No | LinkedIn profile URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | No | |
| result | No | |
| test_mode | No | |
| test_mode_notice | No | |
| vocabulary_warnings | No | |
| deprecated_params_ignored | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses critical behavioral traits: it is billable with specific cost ($0.4 per phone found), a miss is free, it is roughly 20x an email lookup, and it is not to be used speculatively. It also instructs reading cost.amount_charged in every response, adding operational detail not covered by annotations. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured and front-loaded: it starts with the core purpose, then the cost and usage warnings, and finally the alternative. Every sentence provides actionable information—cost, comparison, and constraints—with zero fluff. It is appropriately sized for a tool with significant cost and misuse risk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (mentioned in signals) and complete parameter documentation, the description is thorough. It covers purpose, cost, when to use, and when not to use, and directs to get_balance for pricing and to start_bulk_job for approved lists. The only potential gap—return format—is covered by the output schema. Nothing essential is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 7 parameters with full descriptions (100% coverage), so the baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides; it only mentions high-level usage context. It does not, for example, explain which parameter combinations are preferred, though the schema descriptions already cover that. Thus, the description adds marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find a phone number for one person.' It uses a specific verb ('Find') and resource ('phone number'), and distinguishes itself from siblings by explicitly noting it is the 'MOST EXPENSIVE OPERATION HERE' and comparing cost to email lookup. This makes it unambiguous 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance: 'Do not call it speculatively or across a list; confirm with the user first, and only for people they have already qualified. Use start_bulk_job for an approved list.' It also directs users to call get_balance for real pricing and to check cost.amount_charged, giving clear decision criteria for selecting this tool versus bulk alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_emailFind a verified work emailARead-onlyInspect
Find and verify a work email. BILLABLE — about $0.02 per VALID email found (a miss is free) (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). Identify the person by lead_id (best), LinkedIn URL, or first+last+domain. candidates resolves several people in one call; more than 10 is routed to an async bulk job instead, which returns a job_id for get_bulk_job.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Company domain without protocol, e.g. "stripe.com" (name+domain mode). | |
| lead_id | No | Generect lead id from search / preview / enrich results — the cheapest and most accurate identifier. | |
| last_name | No | Last name (name+domain mode). | |
| candidates | No | Batch mode. Each entry uses the same identifier rules as the single-person form. | |
| first_name | No | First name (name+domain mode). | |
| timeout_ms | No | Request timeout in milliseconds. | |
| middle_name | No | Middle name (optional, improves pattern matching). | |
| linkedin_url | No | LinkedIn profile URL. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job | No | |
| cost | No | |
| mode | No | |
| dropped | No | |
| results | No | |
| next_step | No | |
| requested | No | |
| submitted | No | |
| test_mode | No | |
| test_mode_notice | No | |
| vocabulary_warnings | No | |
| deprecated_params_ignored | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and openWorldHint=true already provided, the description adds significant behavioral context: the billing model ('about $0.02 per VALID email found (a miss is free)'), price variance by account, the presence of cost.amount_charged in responses, and the async routing for >10 candidates. These details go beyond annotations and help an agent anticipate costs and asynchronous behavior. It does not describe error cases or rate limits, but the annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then covers cost, identification modes, and batch behavior in a logical order. Each sentence serves a distinct purpose; the cost information is detailed but relevant for a billable tool. It is slightly longer than strictly necessary, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential operational aspects: cost, identifier modes, batch behavior, and async fallback. Since an output schema exists, it doesn't need to explain return values, and it does mention cost.amount_charged as a response field. It could add prerequisites or error handling, but for a read-only lookup tool with annotations and an output schema, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explicitly listing the allowed identifier modes ('lead_id (best), LinkedIn URL, or first+last+domain') and explaining that candidates entries follow the same rules. It also promotes lead_id as the preferred identifier, which is a semantic nuance not present in the schema. This raises it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Find and verify a work email.' It then clarifies the identifier options (lead_id, LinkedIn URL, first+last+domain) and the batch mode, making the tool's scope distinct from siblings like find_phone (which finds phones) and validate_email (which only validates an existing email). The title and description align, and the behavior is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers clear context: it says lead_id is 'best' (cheapest and most accurate), explains the single vs. candidates modes, and routes >10 candidates to an async job via get_bulk_job. It also directs users to call get_balance for real prices and to read cost.amount_charged. However, it does not explicitly state when not to use this tool vs. alternatives (e.g., 'use validate_email if you already have an email'), so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_balanceBalance, usage and your prices (free)ARead-onlyIdempotentInspect
Account balance, month-to-date usage and THIS account's real per-operation prices. FREE — this call never spends credits. Call it before a batch of paid work (so you can tell the user what they can afford) and after (so you can report exactly what was spent). The prices it returns beat any number in a tool description — those are list prices.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout_ms | No | Request timeout in milliseconds. | |
| include_usage | No | Also return the month-to-date credit usage broken down by operation type. Free. | |
| include_prices | No | Include this account's per-operation prices. Default true. | |
| include_transactions | No | Also return the N most recent transactions (each shows the operation type and dollar amount). | |
| include_token_analytics | No | Also return per-API-token request counts for the last 30 days (by endpoint and status). Free. Useful for answering "which integration is making these calls?". |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | No | |
| No | ||
| usage | No | |
| test_mode | No | |
| balance_usd | No | |
| preview_tier | No | |
| prices_source | No | |
| token_analytics | No | |
| your_prices_usd | No | |
| test_mode_notice | No | |
| recent_transactions | No | |
| used_this_month_usd | No | |
| vocabulary_warnings | No | |
| deprecated_params_ignored | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations carry readOnlyHint, openWorldHint, and idempotentHint, but the description adds a critical behavioral disclosure those fields do not cover: 'FREE — this call never spends credits.' This cost/credit trait is exactly the kind of context that structured annotations fail to convey, and it materially affects whether an agent should call the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each carrying a distinct and necessary piece of information: what it returns, that it costs no credits, when to call it (before/after paid batches), and why its price data is authoritative. The content is front-loaded with the result set, and there is no filler — only a minor, acceptable echo of the title's 'free'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no description-level explanation. All five parameters are optional and fully documented in the schema, annotations cover the read-only/idempotent safety profile, and the description covers purpose, cost behavior, and usage timing. Nothing an agent needs to invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description reinforces the tool's domain (balance, usage, real prices) but does not add per-parameter meaning beyond what the input schema already documents; each parameter already has a thorough description in the schema, including the 'Free' note on include_usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise statement of what the tool returns — account balance, month-to-date usage, and the account's real per-operation prices — using a specific verb-plus-resource pairing that is unambiguous. It clearly distinguishes itself from all 16 sibling tools, which are company/lead data operations, and the 'THIS account's real per-operation prices' phrase adds differentiation from generic list prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-call guidance: call it before a batch of paid work to tell the user what they can afford, and after to report exactly what was spent. The closing note that returned prices beat any tool-description list prices also routes the agent to prefer this tool's data over static price figures. For a tool with no true sibling alternative, this fully answers the when/why-to-use question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bulk_jobPoll a bulk job (free)ARead-onlyIdempotentInspect
Status and results of a bulk job. FREE — this call never spends credits. Polling is free — the work was already billed at submit time. Poll every few seconds, not in a tight loop.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | job_id returned by start_bulk_job. | |
| job_type | Yes | Same job_type used at submit. | |
| timeout_ms | No | Request timeout in milliseconds. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job | No | |
| cost | No | |
| job_id | No | |
| results | No | |
| job_type | No | |
| test_mode | No | |
| test_mode_notice | No | |
| vocabulary_warnings | No | |
| deprecated_params_ignored | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint; the description adds valuable non-obvious cost behavior ('FREE — this call never spends credits', 'already billed at submit time') and polling guidance. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, each earning its place: purpose, cost behavior, billing rationale, and polling cadence. Front-loaded status/result statement followed by actionable guidance with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema covers return values, annotations cover safety/idempotence, and the description fills the cost and polling-cadence gap. It could explicitly mention in-progress job states, but the polling advice strongly implies them, so only a minor gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema, but it does not need to compensate given full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Status and results of a bulk job' with a specific verb and resource. It distinguishes itself from start_bulk_job in the sibling list through the polling/free framing, making intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit cadence guidance ('Poll every few seconds, not in a tight loop') and implies post-submit usage ('the work was already billed at submit time'). It does not explicitly name alternatives or exclusions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_lead_by_urlEnrich a lead by LinkedIn URL (alias)ARead-onlyInspect
Alias of enrich_lead for a LinkedIn profile URL, kept for backwards compatibility. BILLABLE — about $0.0067 per record found (not-found is refunded) (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). Prefer enrich_lead — it also accepts a Generect id (cheaper to get right) or an email for reverse lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | LinkedIn profile URL (e.g. https://www.linkedin.com/in/username/). | |
| 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 a recent cached record is good enough and cost matters more than freshness. | |
| posts | No | DEPRECATED — accepted but ignored. Removed: v1 enrich returns the full profile without per-section toggles. | |
| compact | No | Default 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. | |
| comments | No | DEPRECATED — accepted but ignored. Removed: v1 enrich returns the full profile without per-section toggles. | |
| timeout_ms | No | Request timeout in milliseconds. | |
| inexact_company | No | DEPRECATED — accepted but ignored. Removed: v1 enrich matches on the identifier you pass. | |
| people_also_viewed | No | DEPRECATED — accepted but ignored. Removed: v1 enrich returns the full profile without per-section toggles. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | No | |
| lead | No | |
| mode | No | |
| found | No | |
| company | No | |
| test_mode | No | |
| test_mode_notice | No | |
| vocabulary_warnings | No | |
| deprecated_params_ignored | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses billing behavior, approximate cost, refund policy for not-found records, and where to find actual spend in the response. It also clarifies that the tool is an alias, which transparently signals that behavior mirrors enrich_lead.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: alias and purpose come first, followed by cost, then the routing guidance. It is only a few sentences and every clause earns its place, including the pricing note and the pointer to get_balance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, an output schema, and rich annotations, this description is complete. It covers what the tool is, what it costs, how failures are billed, and which sibling to prefer. No critical operational guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 thoroughly. The description adds no per-parameter semantics; it focuses on cost and alias behavior. Per the calibration baseline, this is adequate but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens by stating it is an alias of enrich_lead specifically for a LinkedIn profile URL, kept for backwards compatibility. This clearly identifies the resource (a lead), the action (enrich), the input shape (LinkedIn URL), and how it relates to its sibling enrich_lead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes agents to the preferred sibling: 'Prefer enrich_lead — it also accepts a Generect id (cheaper to get right) or an email for reverse lookup.' This gives a concrete when-to-use vs. when-not-to-use rule and names the alternative, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
healthServer and credential health (free)ARead-onlyIdempotentInspect
Liveness check. FREE — this call never spends credits. Confirms the MCP server is up, reports its version, and (unless you disable it) verifies the credential against a free account endpoint. It never touches a paid data endpoint, so it is safe to call from a monitor.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout_ms | No | Request timeout in milliseconds. | |
| check_credential | No | Also verify the API token against the free /accounts/me endpoint. Default true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ms | No | |
| ok | No | |
| cost | No | |
| server | No | |
| account | No | |
| version | No | |
| api_base | No | |
| test_mode | No | |
| balance_usd | No | |
| has_credential | No | |
| credential_error | No | |
| credential_valid | No | |
| test_mode_notice | No | |
| vocabulary_warnings | No | |
| deprecated_params_ignored | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly, idempotent, and openWorld, but the description adds valuable behavioral context: it never spends credits, only hits a free account endpoint, reports server version, and makes credential verification optional. This goes beyond the structured hints and helps an agent understand side effects and cost impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three short sentences with the core purpose and cost warning front-loaded. Every sentence adds useful information, and there is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters, a provided output schema, and strong annotations covering safety, this description is complete. It explains cost behavior, credential checking, endpoint usage, and monitor suitability—everything an agent needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with clear descriptions, including the default for check_credential. The description adds only the paraphrased idea 'unless you disable it,' which does not significantly expand on the schema. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete noun phrase, 'Liveness check,' and specifies exactly what the call does: confirm the server is up, report its version, and optionally verify the credential against a free endpoint. This makes it easy for an agent to distinguish from data-returning sibling tools like search_companies or enrich_lead, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use context: it is free, never spends credits, never touches a paid data endpoint, and is safe to call from a monitor. It does not explicitly name sibling alternatives or state when not to use it, but the free/safety framing is strong guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
manage_webhooksManage webhook endpointsADestructiveInspect
List, create, update, delete or test webhook endpoints for bulk-job completion. FREE — this call never spends credits. Use this instead of long polling in scheduled/unattended workflows: register once, then let the completion event wake your job up.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Webhook id (required for update, delete, test). | |
| url | No | HTTPS endpoint that receives events (create/update). | |
| action | Yes | What to do. | |
| events | No | Events to subscribe to (create/update). | |
| secret | No | Shared secret for HMAC signature verification. | |
| timeout_ms | No | Request timeout in milliseconds. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | No | |
| action | No | |
| webhooks | No | |
| test_mode | No | |
| test_mode_notice | No | |
| vocabulary_warnings | No | |
| deprecated_params_ignored | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and read-write behavior, so the description need not repeat that. It adds valuable extras: the call 'never spends credits' and the event-driven wake-up behavior. This goes beyond the structured fields without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry the full payload: operations, credit cost, and usage context. No filler, no repetition of schema details, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich schema descriptions, an output schema, and annotations covering destructiveness, the description is complete. It adds the missing contextual piece—when and why to use webhooks—without leaving an agent guessing about how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all parameters meaningfully. The description adds little parameter-level detail beyond framing the events as 'bulk-job completion' events. Baseline 3 is appropriate because the description does not degrade or confuse parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb set ('list, create, update, delete or test') and a specific resource ('webhook endpoints for bulk-job completion'). It fully distinguishes this tool from all siblings, none of which manage webhooks, so an agent can immediately identify its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to use it: in scheduled/unattended workflows instead of long polling, with the rationale 'register once, then let the completion event wake your job up.' This is concrete usage guidance that names an alternative pattern and the condition favoring this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preview_leadsPreview leads (cheapest paid look)ARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Alias for limit_by. | |
| strict | No | Fields to match strictly, e.g. ["company_locations"]. | |
| compact | No | Default 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. | |
| keywords | No | Free-text keywords across headline/summary/skills — realtime only: using it forces the pricier live mode. | |
| limit_by | No | Rows to return this call (1–100, default 25). You are billed per returned row, so this number IS the price of the call. | |
| 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"]. | |
| offset_by | No | Rows to skip (pagination). | |
| company_id | No | Anchor to one company by LinkedIn numeric id. | |
| count_only | No | Return 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_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 company-level filters for a two-level ICP. | |
| 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. | |
| confirm_spend_usd | No | Explicit 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_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
| Name | Required | Description |
|---|---|---|
| fix | No | |
| cost | No | |
| mode | No | |
| note | No | |
| leads | No | |
| status | No | |
| returned | No | |
| companies | No | |
| test_mode | No | |
| spend_guard | No | |
| results_count | No | |
| next_page_args | No | |
| requested_rows | No | |
| escalation_note | No | |
| test_mode_notice | No | |
| vocabulary_warnings | No | |
| blocked_by_vocabulary | No | |
| deprecated_params_ignored | No | |
| escalated_to_realtime_because | No | |
| api_returned_more_than_requested | No |
TDQS
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.
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.
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.
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.
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.
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.
resolve_profileResolve an anonymous LinkedIn linkARead-onlyInspect
Reveal who is behind an anonymous LinkedIn profile link. BILLABLE — about $0.0005 per RESOLVED profile (an unresolvable reference is free) — duplicates in one batch are billed per row, so deduplicate first (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). Takes the obfuscated links that Sales Navigator leaves in exports, CRMs and ad platforms — linkedin.com/in/ACwAA… — plus Sales Navigator lead URLs, bare profile ids and urns, and returns the real profile URL and identity. Pass profiles (up to 50) to do a batch in one call. The id it returns is the same identifier enrich_lead, generate_email and find_phone accept, so this is the cheap first step before spending on a full record. Returns identity only — no location, company or work history; use enrich_lead for those. The numeric member id is NOT accepted as input (LinkedIn answers 403 to it); it comes back as linkedin_id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Alias for `url` — same accepted values. Use whichever reads better. | |
| url | No | A single LinkedIn person reference: profile URL of any flavour (including /in/ACwAA… and /sales/lead/…), a public identifier, an obfuscated id (ACwAA… or ACoAA…) or an urn. Matched case-insensitively. | |
| compact | No | Default true: return a small per-profile 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. | |
| profiles | No | Batch mode: 1–50 references, mixed freely. One row per input, in input order, each either a resolved profile or {input, error}. Duplicates are billed per row — deduplicate first. | |
| timeout_ms | No | Request timeout in milliseconds. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | No | |
| profiles | No | |
| resolved | No | |
| test_mode | No | |
| test_mode_notice | No | |
| vocabulary_warnings | No | |
| deprecated_params_ignored | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint, but the description adds substantial behavioral context: billable per resolved profile, free unresolvable references, duplicate billing per row, 403 on numeric member ids, batch row ordering, and output id compatibility. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but non-redundant. Front-loads the core purpose, then proceeds through billing, input types, batch mode, and output limitations in a logical order. Longer than typical but every sentence carries actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers billing behavior, accepted and rejected inputs, batch semantics, and output limitations. With an output schema present, it correctly avoids detailing return fields. The timeout parameter is delegated to the schema, which is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters, so baseline is 3. The description adds extra semantics for `profiles` (batch size, billing per row, deduplication) and clarifies accepted input formats plus the rejected numeric member id. This enriches understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific action (reveal who is behind anonymous LinkedIn profile links) and the resource (anonymous LinkedIn links). It clearly distinguishes from siblings like enrich_lead by explicitly noting it returns identity only, and specifies accepted input types and output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly positions the tool as the cheap first step before enrich_lead, generate_email, and find_phone, and directs users to enrich_lead for location/company/work history. It also warns against using numeric member ids as input and instructs to call get_balance for real pricing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_companiesSearch companies (billed per row)ARead-onlyInspect
Return companies matching an ICP. BILLABLE — about $0.0067 per returned row (0 rows costs $0) (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). Run count_companies first. Note that headcount_range is a snapshot taken when the record was indexed and can lag the company's current size; the filter itself is applied at query time.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 freshness is not critical and cost matters more than freshness. | |
| limit | No | Alias for limit_by. | |
| offset | No | Alias for offset_by. | |
| compact | No | Default true: return a small per-company 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. | |
| keywords | No | Free-text keywords across name/description/specialties — realtime only: using it forces the pricier live mode. | |
| limit_by | No | Rows to return this call (1–100, default 25). You are billed per returned row, so this number IS the price of the call. | |
| locations | No | HQ locations — cities, states or countries. | |
| offset_by | No | Rows to skip (pagination). | |
| headcounts | No | Size buckets. Allowed ONLY: "1-10","11-50","51-200","201-500","501-1000","1001-5000","5001-10000","10 000+". | |
| industries | No | Company industries. Must match Generect industry names exactly (e.g. "Software Development"); unknown names are rejected with HTTP 400. | |
| timeout_ms | No | Request timeout in milliseconds. | |
| exclude_ids | No | Exclude companies by LinkedIn id/URN. | |
| technologies | No | Technologies the company uses — realtime only: using it forces the pricier live mode. | |
| company_names | No | Restrict to specific company names — realtime only: using it forces the pricier live mode. | |
| company_types | No | Company types: "Public Company","Privately Held","Non Profit","Government Agency","Educational", … | |
| revenues_range | No | Annual revenue range, single object {min,max} — realtime only: using it forces the pricier live mode. | |
| sub_industries | No | Expand each selected industry to its sub-industries as well (broadens the match). | |
| exclude_domains | No | Exclude companies by domain (e.g. existing customers). | |
| linkedins_links | No | Specific LinkedIn company URLs — realtime only: using it forces the pricier live mode. | |
| headcount_growth | No | Headcount growth in percent — realtime only: using it forces the pricier live mode. | |
| num_of_followers | No | LinkedIn follower buckets: "1-50","51-100","101-1000","1001-5000","5001+" — realtime only: using it forces the pricier live mode. | |
| confirm_spend_usd | No | Explicit 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_locations | No | HQ locations to exclude. | |
| get_max_companies | No | DEPRECATED — accepted but ignored. Always on now: search responses include results_count without asking. | |
| exclude_industries | No | Industries to exclude. | |
| hiring_on_linkedin | No | Only companies actively hiring — realtime only: using it forces the pricier live mode. | |
| fallback_from_leads | No | DEPRECATED — accepted but ignored. Removed. It fabricated lead-derived name aggregates and cost an extra billable query. | |
| department_headcount | No | Department size, e.g. {"name":"engineering","min":10,"max":100} — realtime only: using it forces the pricier live mode. | |
| allow_unlisted_values | No | Escape hatch for the local vocabulary check — see the lead-side field of the same name. |
Output Schema
| Name | Required | Description |
|---|---|---|
| fix | No | |
| cost | No | |
| mode | No | |
| note | No | |
| leads | No | |
| status | No | |
| returned | No | |
| companies | No | |
| test_mode | No | |
| spend_guard | No | |
| results_count | No | |
| next_page_args | No | |
| requested_rows | No | |
| escalation_note | No | |
| test_mode_notice | No | |
| vocabulary_warnings | No | |
| blocked_by_vocabulary | No | |
| deprecated_params_ignored | No | |
| escalated_to_realtime_because | No | |
| api_returned_more_than_requested | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses billing per returned row, zero-cost for zero rows, the cost-reading mechanism, snapshot lag for headcount data, and referential guidance to get_balance. The schema adds escalation behavior for auto mode, realtime-only constraints, and HTTP 400 rejections. This goes far beyond the readOnlyHint/openWorldHint annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loads the core operation, and every sentence carries operational value: what it returns, what it costs, what to run first, and a data-freshness caveat. No filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 29-parameter, billable, output-schema-bearing tool, the description plus schema covers cost, prerequisites, mode behavior, data freshness, error conditions, pagination, and deprecations. The output schema handles return-value documentation, so nothing critical is missing for an agent to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, including realtime-only behavior and cost implications. The tool-level description adds only a small extra note about headcount snapshot lag, which is useful but not essential given the rich parameter descriptions already present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Return companies matching an ICP,' so an agent immediately knows this is a search/list tool for companies. It does not explicitly name a sibling it is not (e.g. count_companies), but 'Return companies' plus the sibling name makes the distinction clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs the agent to 'Run count_companies first,' providing a concrete sibling-workflow rule. The schema further adds strong mode-selection guidance ('Pick database explicitly when freshness is not critical and cost matters more than freshness') and flags filters that force realtime, which is exactly the kind of when-to-use-vs-alternative guidance this dimension rewards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_leadsSearch leads (billed per row)ARead-onlyInspect
Return leads (people) matching an ICP. BILLABLE — about $0.0067 per returned row (0 rows costs $0) (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). Run count_leads first — it is free and tells you both the audience size and what this call will cost. Returns profile data only: no email or phone. Use generate_email / find_phone on the ids you actually want. Ordering is not stable, so paginate by passing ids you already have in exclude_ids rather than by offset.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 freshness is not critical and cost matters more than freshness. | |
| limit | No | Alias for limit_by. | |
| offset | No | Alias for offset_by. | |
| strict | No | Fields to match strictly, e.g. ["company_locations"]. | |
| compact | No | Default 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. | |
| keywords | No | Free-text keywords across headline/summary/skills — realtime only: using it forces the pricier live mode. | |
| limit_by | No | Rows to return this call (1–100, default 25). You are billed per returned row, so this number IS the price of the call. | |
| 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"]. | |
| offset_by | No | Rows to skip (pagination). | |
| 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: only return leads at companies matching these filters (two-level ICP). | |
| 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. | |
| confirm_spend_usd | No | Explicit 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_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
| Name | Required | Description |
|---|---|---|
| fix | No | |
| cost | No | |
| mode | No | |
| note | No | |
| leads | No | |
| status | No | |
| returned | No | |
| companies | No | |
| test_mode | No | |
| spend_guard | No | |
| results_count | No | |
| next_page_args | No | |
| requested_rows | No | |
| escalation_note | No | |
| test_mode_notice | No | |
| vocabulary_warnings | No | |
| blocked_by_vocabulary | No | |
| deprecated_params_ignored | No | |
| escalated_to_realtime_because | No | |
| api_returned_more_than_requested | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint, so the description carries the behavioral burden and meets it richly: per-row billing with a price, a 0-rows-costs-$0 guarantee, cost.amount_charged in responses, profile-data-only return scope (no email/phone), unstable ordering, and the known exclude_names-in-database-mode defect. All consistent with readOnlyHint, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense paragraph with the most decision-critical facts front-loaded: billable, price per row, then the free preflight (count_leads), then return scope, then follow-up tools, then pagination. Every sentence earns its place; nothing is fluff. Appropriate density for a 42-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value description is unnecessary, and the schema fully covers all 42 parameter semantics. The description completes the picture for what the schema cannot convey: cost awareness, free-alternative routing, data scope, and reliable pagination. The database/realtime tradeoff lives in the schema's mode parameter where it belongs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all 42 parameters and sets a baseline of 3. The description adds genuine connecting value on top: it ties limit_by to 'the price of the call,' explains compact's id-acceptance guarantee, and frames exclude_ids as the reliable pagination mechanism. This is additive beyond the schema rather than redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource — 'Return leads (people) matching an ICP' — and is clearly distinct from count_leads (which returns a count, not rows) and the enrichment siblings (generate_email/find_phone, which operate on returned ids). An agent can tell it apart from every sibling without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Run count_leads first — it is free' to size the audience and cost before spending, and routes follow-up work to 'generate_email / find_phone on the ids you actually want.' It also advises pagination by exclude_ids over offset due to unstable ordering. When-to-use and when-to-use-an-alternative are both concrete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_bulk_jobSubmit a bulk jobARead-onlyInspect
Submit up to 50 records for asynchronous processing and get a job_id back. BILLABLE at the same per-record rate as the single-record tool — and the whole cost is RESERVED at submit time, so a submitted job keeps running (and keeps charging) even if you stop polling. Only submit a list the user has approved. Poll with get_bulk_job, or register a webhook to be told when it finishes.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Enrich jobs only: cached (cheaper) or live. Default "database". | |
| items | Yes | Max 50. email_find/phone_find: {lead_id} | {linkedin_url} | {first_name,last_name,domain|company}. enrich_leads: {id} | {linkedin_url} | {email}. enrich_companies: {id} | {linkedin_url} | {domain} | {name}. | |
| job_type | Yes | What to do with the items. phone_find is by far the most expensive per record. | |
| timeout_ms | No | Request timeout in milliseconds. | |
| confirm_spend_usd | No | Explicit 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| job | No | |
| cost | No | |
| mode | No | |
| dropped | No | |
| job_type | No | |
| next_step | No | |
| submitted | No | |
| test_mode | No | |
| reservation_note | No | |
| test_mode_notice | No | |
| vocabulary_warnings | No | |
| reserved_worst_case_usd | No | |
| deprecated_params_ignored | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool is BILLABLE and reserves cost, indicating a side effect (charging). This directly contradicts the annotation readOnlyHint: true, which implies the tool does not modify state or cause side effects. Per the rubric, a contradiction yields a score of 1 and flags annotation_contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each purposeful: core function, cost/billing, and usage guidance. It is front-loaded with the primary action and avoids fluff. The all-caps emphasis on BILLABLE and RESERVED is intentional to highlight critical side effects, though slightly noisy, it does not detract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function, cost implications, approval requirement, and follow-up actions (polling/webhook). An output schema exists, so return details are not needed. However, the contradiction with readOnlyHint is a notable gap that could confuse an agent about side effects. Despite that, the description itself is fairly complete for a bulk job submission tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the schema. The description adds some context (billing, approval) but does not clarify parameter syntax or usage beyond what the schema provides. The mention of 'up to 50' mirrors the schema's max on items. Baseline 3 is appropriate since the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Submit up to 50 records for asynchronous processing and get a job_id back.' It names the resource (records), the operation (submit), and the outcome (job_id), distinguishing it from single-record tools like enrich_lead and from get_bulk_job which polls. The scope ('up to 50') and async nature differentiate it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit conditions: 'Only submit a list the user has approved' and describes follow-up actions ('Poll with get_bulk_job, or register a webhook'). It implies this is for batch processing vs single-record tools, but does not explicitly state 'use for multiple records' or 'avoid for single records'. However, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_emailValidate email deliverabilityARead-onlyInspect
Check deliverability of emails you already have. BILLABLE — about $0.005 per email submitted — every address is billed, whatever the verdict (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). This is the one operation where EVERY submitted address is billed — the verdict is the deliverable. Never validate an address that generate_email just returned as valid; it is already verified.
| Name | Required | Description | Default |
|---|---|---|---|
| emails | Yes | Email addresses to validate. Each one is billed. | |
| timeout_ms | No | Request timeout in milliseconds. |
Output Schema
| Name | Required | Description |
|---|---|---|
| cost | No | |
| results | No | |
| submitted | No | |
| test_mode | No | |
| test_mode_notice | No | |
| vocabulary_warnings | No | |
| deprecated_params_ignored | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses critical billing behavior: every address is billed regardless of result, with specific cost and how to find actual charges. It also notes that the verdict itself is the deliverable. This adds significant context beyond structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: it starts with the purpose, immediately warns about billing, provides pricing specifics and how to read costs, and includes an exclusion. It's well-structured and front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a billable operation, the description covers the action, cost implications, billing exceptions, and how to retrieve real charges. With an output schema also present, the agent has everything needed to call and interpret results correctly without missing details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters with 100% coverage ('Email addresses to validate. Each one is billed.' and 'Request timeout in milliseconds.'). The description adds pricing context but does not elaborate on the meaning of individual parameters beyond what the schema provides, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check deliverability of emails you already have') and the resource ('emails you already have'), distinguishing it from generate_email which creates emails. It's specific and unambiguous, with no tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when NOT to use the tool: 'Never validate an address that generate_email just returned as valid; it is already verified.' It also references get_balance for pricing, guiding the agent on alternative actions. This is clear usage differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
17 tool updates
- Changed
count_companies2 fields changed- added
Input schema / properties / allow_unlisted_valuesAdded value: +{ + "description": "Escape hatch for the local vocabulary check — see the lead-side field of the same name.", + "type": "boolean" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "advice": { + "type": "string" + }, + "blocked_by_vocabulary": { + "$ref": "#/properties/vocabulary_warnings" + }, + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "fix": { + "type": "string" + }, + "mode": { + "type": "string" + }, + "needs_realtime": { + "items": { + "type": "string" + }, + "type": "array" + }, + "next_step_estimate": {}, + "options": { + "items": { + "type": "string" + }, + "type": "array" + }, + "results_count": { + "type": [ + "number", + "null" + ] + }, + "status": { + "type": "string" + }, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + }, + "why": { + "type": "string" + } + }, + "type": "object" +}
- Changed
count_leads3 fields changed- added
Input schema / properties / allow_unlisted_valuesAdded value: +{ + "description": "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.", + "type": "boolean" +} - added
Input schema / properties / company_filters / properties / allow_unlisted_valuesAdded value: +{ + "description": "Escape hatch for the local vocabulary check — see the lead-side field of the same name.", + "type": "boolean" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "advice": { + "type": "string" + }, + "blocked_by_vocabulary": { + "$ref": "#/properties/vocabulary_warnings" + }, + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "fix": { + "type": "string" + }, + "mode": { + "type": "string" + }, + "needs_realtime": { + "items": { + "type": "string" + }, + "type": "array" + }, + "next_step_estimate": {}, + "options": { + "items": { + "type": "string" + }, + "type": "array" + }, + "results_count": { + "type": [ + "number", + "null" + ] + }, + "status": { + "type": "string" + }, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + }, + "why": { + "type": "string" + } + }, + "type": "object" +}
- Changed
enrich_company1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "company": {}, + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "found": { + "type": "boolean" + }, + "lead": {}, + "mode": { + "type": "string" + }, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + } + }, + "type": "object" +}
- Changed
enrich_lead1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "company": {}, + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "found": { + "type": "boolean" + }, + "lead": {}, + "mode": { + "type": "string" + }, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + } + }, + "type": "object" +}
- Changed
find_phone1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "result": {}, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + } + }, + "type": "object" +}
- Changed
generate_email1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "dropped": { + "type": "number" + }, + "job": {}, + "mode": { + "type": "string" + }, + "next_step": { + "type": "string" + }, + "requested": { + "type": "number" + }, + "results": { + "type": "array" + }, + "submitted": { + "type": "number" + }, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + } + }, + "type": "object" +}
- Changed
get_balance3 fields changed- added
Input schema / properties / include_token_analyticsAdded value: +{ + "description": "Also return per-API-token request counts for the last 30 days (by endpoint and status). Free. Useful for answering \"which integration is making these calls?\".", + "type": "boolean" +} - added
Input schema / properties / include_usageAdded value: +{ + "description": "Also return the month-to-date credit usage broken down by operation type. Free.", + "type": "boolean" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "balance_usd": { + "type": [ + "number", + "null" + ] + }, + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "email": { + "type": [ + "string", + "null" + ] + }, + "preview_tier": { + "type": [ + "boolean", + "null" + ] + }, + "prices_source": { + "type": "string" + }, + "recent_transactions": {}, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "token_analytics": {}, + "usage": {}, + "used_this_month_usd": { + "type": [ + "number", + "null" + ] + }, + "vocabulary_warnings": { + "type": "array" + }, + "your_prices_usd": {} + }, + "type": "object" +}
- Changed
get_bulk_job1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "job": {}, + "job_id": { + "type": "string" + }, + "job_type": { + "type": "string" + }, + "results": {}, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + } + }, + "type": "object" +}
- Changed
get_lead_by_url1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "company": {}, + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "found": { + "type": "boolean" + }, + "lead": {}, + "mode": { + "type": "string" + }, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + } + }, + "type": "object" +}
- Changed
health1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "account": { + "type": [ + "string", + "null" + ] + }, + "api_base": { + "type": "string" + }, + "balance_usd": { + "type": [ + "number", + "null" + ] + }, + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "credential_error": {}, + "credential_valid": { + "type": "boolean" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "has_credential": { + "type": "boolean" + }, + "ms": { + "type": "number" + }, + "ok": { + "type": "boolean" + }, + "server": { + "type": "string" + }, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "version": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + } + }, + "type": "object" +}
- Changed
manage_webhooks1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "action": { + "type": "string" + }, + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + }, + "webhooks": {} + }, + "type": "object" +}
- Changed
preview_leads5 fields changed- added
Input schema / properties / allow_unlisted_valuesAdded value: +{ + "description": "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.", + "type": "boolean" +} - added
Input schema / properties / company_filters / properties / allow_unlisted_valuesAdded value: +{ + "description": "Escape hatch for the local vocabulary check — see the lead-side field of the same name.", + "type": "boolean" +} - added
Input schema / properties / confirm_spend_usdAdded value: +{ + "description": "Explicit 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.", + "type": "number" +} - added
Input schema / properties / count_onlyAdded value: +{ + "description": "Return 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.", + "type": "boolean" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "api_returned_more_than_requested": { + "type": "number" + }, + "blocked_by_vocabulary": { + "$ref": "#/properties/vocabulary_warnings" + }, + "companies": { + "type": "array" + }, + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "escalated_to_realtime_because": { + "items": { + "type": "string" + }, + "type": "array" + }, + "escalation_note": { + "type": "string" + }, + "fix": { + "type": "string" + }, + "leads": { + "type": "array" + }, + "mode": { + "type": "string" + }, + "next_page_args": {}, + "note": { + "type": "string" + }, + "requested_rows": { + "type": "number" + }, + "results_count": { + "type": [ + "number", + "null" + ] + }, + "returned": { + "type": "number" + }, + "spend_guard": {}, + "status": { + "type": "string" + }, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + } + }, + "type": "object" +}
- Added
resolve_profile - Changed
search_companies3 fields changed- added
Input schema / properties / allow_unlisted_valuesAdded value: +{ + "description": "Escape hatch for the local vocabulary check — see the lead-side field of the same name.", + "type": "boolean" +} - added
Input schema / properties / confirm_spend_usdAdded value: +{ + "description": "Explicit 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.", + "type": "number" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "api_returned_more_than_requested": { + "type": "number" + }, + "blocked_by_vocabulary": { + "$ref": "#/properties/vocabulary_warnings" + }, + "companies": { + "type": "array" + }, + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "escalated_to_realtime_because": { + "items": { + "type": "string" + }, + "type": "array" + }, + "escalation_note": { + "type": "string" + }, + "fix": { + "type": "string" + }, + "leads": { + "type": "array" + }, + "mode": { + "type": "string" + }, + "next_page_args": {}, + "note": { + "type": "string" + }, + "requested_rows": { + "type": "number" + }, + "results_count": { + "type": [ + "number", + "null" + ] + }, + "returned": { + "type": "number" + }, + "spend_guard": {}, + "status": { + "type": "string" + }, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + } + }, + "type": "object" +}
- Changed
search_leads4 fields changed- added
Input schema / properties / allow_unlisted_valuesAdded value: +{ + "description": "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.", + "type": "boolean" +} - added
Input schema / properties / company_filters / properties / allow_unlisted_valuesAdded value: +{ + "description": "Escape hatch for the local vocabulary check — see the lead-side field of the same name.", + "type": "boolean" +} - added
Input schema / properties / confirm_spend_usdAdded value: +{ + "description": "Explicit 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.", + "type": "number" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "api_returned_more_than_requested": { + "type": "number" + }, + "blocked_by_vocabulary": { + "$ref": "#/properties/vocabulary_warnings" + }, + "companies": { + "type": "array" + }, + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "escalated_to_realtime_because": { + "items": { + "type": "string" + }, + "type": "array" + }, + "escalation_note": { + "type": "string" + }, + "fix": { + "type": "string" + }, + "leads": { + "type": "array" + }, + "mode": { + "type": "string" + }, + "next_page_args": {}, + "note": { + "type": "string" + }, + "requested_rows": { + "type": "number" + }, + "results_count": { + "type": [ + "number", + "null" + ] + }, + "returned": { + "type": "number" + }, + "spend_guard": {}, + "status": { + "type": "string" + }, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + } + }, + "type": "object" +}
- Changed
start_bulk_job2 fields changed- added
Input schema / properties / confirm_spend_usdAdded value: +{ + "description": "Explicit 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.", + "type": "number" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "dropped": { + "type": "number" + }, + "job": {}, + "job_type": { + "type": "string" + }, + "mode": { + "type": "string" + }, + "next_step": { + "type": "string" + }, + "reservation_note": { + "type": "string" + }, + "reserved_worst_case_usd": { + "type": "number" + }, + "submitted": { + "type": "number" + }, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + } + }, + "type": "object" +}
- Changed
validate_email1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "additionalProperties": false, + "properties": { + "cost": { + "additionalProperties": false, + "properties": { + "amount_charged_usd": { + "type": [ + "number", + "null" + ] + }, + "billed": { + "type": "string" + }, + "note": { + "type": "string" + }, + "operation": { + "type": "string" + } + }, + "type": "object" + }, + "deprecated_params_ignored": { + "additionalProperties": { + "type": "string" + }, + "type": "object" + }, + "results": {}, + "submitted": { + "type": "number" + }, + "test_mode": { + "type": "boolean" + }, + "test_mode_notice": { + "type": "string" + }, + "vocabulary_warnings": { + "type": "array" + } + }, + "type": "object" +}
16 tool updates
- Added
count_companies - Added
count_leads - Added
enrich_company - Added
enrich_lead - Added
find_phone - Changed
generate_email12 fields changed- changed
Input schema / properties / candidates / descriptionPrevious value: -"Batch mode: resolve many people in one call. Each needs first_name, last_name, domain (middle_name optional)."New value: +"Batch mode. Each entry uses the same identifier rules as the single-person form." - added
Input schema / properties / candidates / items / descriptionAdded value: +"One of: {lead_id} | {linkedin_url} | {first_name,last_name,domain}" - added
Input schema / properties / candidates / items / properties / lead_idAdded value: +{ + "type": "string" +} - added
Input schema / properties / candidates / items / properties / linkedin_urlAdded value: +{ + "type": "string" +} - removed
Input schema / properties / candidates / items / requiredRemoved value: -[ - "first_name", - "last_name", - "domain" -] - changed
Input schema / properties / domain / descriptionPrevious value: -"Company domain without protocol, e.g. \"generect.com\" (required in single-person mode)."New value: +"Company domain without protocol, e.g. \"stripe.com\" (name+domain mode)." - changed
Input schema / properties / first_name / descriptionPrevious value: -"First name (single-person mode)."New value: +"First name (name+domain mode)." - changed
Input schema / properties / last_name / descriptionPrevious value: -"Last name (single-person mode)."New value: +"Last name (name+domain mode)." - added
Input schema / properties / lead_idAdded value: +{ + "description": "Generect lead id from search / preview / enrich results — the cheapest and most accurate identifier.", + "type": "string" +} - added
Input schema / properties / linkedin_urlAdded value: +{ + "description": "LinkedIn profile URL.", + "type": "string" +} - changed
Input schema / properties / middle_name / descriptionPrevious value: -"Middle name (optional)."New value: +"Middle name (optional, improves pattern matching)." - changed
Input schema / properties / timeout_ms / descriptionPrevious value: -"Request timeout in milliseconds"New value: +"Request timeout in milliseconds."
- Added
get_balance - Added
get_bulk_job - Changed
get_lead_by_url12 fields changed- changed
Input schema / properties / comments / descriptionPrevious value: -"Include comments data"New value: +"DEPRECATED — accepted but ignored. Removed: v1 enrich returns the full profile without per-section toggles." - removed
Input schema / properties / comments / typeRemoved value: -"boolean" - added
Input schema / properties / compactAdded value: +{ + "description": "Default 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.", + "type": "boolean" +} - changed
Input schema / properties / inexact_company / descriptionPrevious value: -"Allow inexact company matching"New value: +"DEPRECATED — accepted but ignored. Removed: v1 enrich matches on the identifier you pass." - removed
Input schema / properties / inexact_company / typeRemoved value: -"boolean" - added
Input schema / properties / modeAdded value: +{ + "description": "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 a recent cached record is good enough and cost matters more than freshness.", + "enum": [ + "auto", + "database", + "realtime" + ], + "type": "string" +} - changed
Input schema / properties / people_also_viewed / descriptionPrevious value: -"Include people also viewed"New value: +"DEPRECATED — accepted but ignored. Removed: v1 enrich returns the full profile without per-section toggles." - removed
Input schema / properties / people_also_viewed / typeRemoved value: -"boolean" - changed
Input schema / properties / posts / descriptionPrevious value: -"Include posts data"New value: +"DEPRECATED — accepted but ignored. Removed: v1 enrich returns the full profile without per-section toggles." - removed
Input schema / properties / posts / typeRemoved value: -"boolean" - changed
Input schema / properties / timeout_ms / descriptionPrevious value: -"Request timeout in milliseconds"New value: +"Request timeout in milliseconds." - changed
Input schema / properties / url / descriptionPrevious value: -"LinkedIn profile URL (e.g., https://www.linkedin.com/in/username/)"New value: +"LinkedIn profile URL (e.g. https://www.linkedin.com/in/username/)."
- Changed
health4 fields changed- added
Input schema / properties / check_credentialAdded value: +{ + "description": "Also verify the API token against the free /accounts/me endpoint. Default true.", + "type": "boolean" +} - removed
Input schema / properties / deepRemoved value: -{ - "description": "Run a live API probe (lead-by-link). Consumes a credit. Default false.", - "type": "boolean" -} - changed
Input schema / properties / timeout_ms / descriptionPrevious value: -"Request timeout in milliseconds"New value: +"Request timeout in milliseconds." - removed
Input schema / properties / urlRemoved value: -{ - "description": "LinkedIn profile URL for the deep probe (defaults to a public profile).", - "type": "string" -}
- Added
manage_webhooks - Added
preview_leads - Changed
search_companies29 fields changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Default true: 6-field summary per company. Set false for the full raw object."New value: +"Default true: return a small per-company 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." - changed
Input schema / properties / company_names / descriptionPrevious value: -"Restrict to specific company names."New value: +"Restrict to specific company names — realtime only: using it forces the pricier live mode." - changed
Input schema / properties / company_types / descriptionPrevious value: -"Company types. Allowed values: \"Public Company\", \"Educational\", \"Self Employed\", \"Government Agency\", \"Non Profit\", \"Self Owned\", \"Privately Held\", \"Partnership\"."New value: +"Company types: \"Public Company\",\"Privately Held\",\"Non Profit\",\"Government Agency\",\"Educational\", …" - added
Input schema / properties / department_headcountAdded value: +{ + "additionalProperties": false, + "description": "Department size, e.g. {\"name\":\"engineering\",\"min\":10,\"max\":100} — realtime only: using it forces the pricier live mode.", + "properties": { + "max": { + "type": "number" + }, + "min": { + "type": "number" + }, + "name": { + "type": "string" + } + }, + "required": [ + "name" + ], + "type": "object" +} - added
Input schema / properties / exclude_domainsAdded value: +{ + "description": "Exclude companies by domain (e.g. existing customers).", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / exclude_idsAdded value: +{ + "description": "Exclude companies by LinkedIn id/URN.", + "items": { + "type": [ + "string", + "number" + ] + }, + "type": "array" +} - changed
Input schema / properties / exclude_industries / descriptionPrevious value: -"Industries to exclude (same taxonomy as industries)."New value: +"Industries to exclude." - changed
Input schema / properties / exclude_locations / descriptionPrevious value: -"Locations to exclude."New value: +"HQ locations to exclude." - changed
Input schema / properties / fallback_from_leads / descriptionPrevious value: -"Default FALSE. If true and the company search is empty, derive candidate company NAMES by aggregating a keyword lead search. These are lead-derived name counts (source:\"leads_derived\"), NOT real company records, and cost an extra query."New value: +"DEPRECATED — accepted but ignored. Removed. It fabricated lead-derived name aggregates and cost an extra billable query." - removed
Input schema / properties / fallback_from_leads / typeRemoved value: -"boolean" - changed
Input schema / properties / get_max_companies / descriptionPrevious value: -"Also report the total number of matching companies."New value: +"DEPRECATED — accepted but ignored. Always on now: search responses include results_count without asking." - removed
Input schema / properties / get_max_companies / typeRemoved value: -"boolean" - added
Input schema / properties / headcount_growthAdded value: +{ + "additionalProperties": false, + "description": "Headcount growth in percent — realtime only: using it forces the pricier live mode.", + "properties": { + "max": { + "type": "number" + }, + "min": { + "type": "number" + } + }, + "type": "object" +} - changed
Input schema / properties / headcounts / descriptionPrevious value: -"Employee headcount 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+\")."New value: +"Size buckets. Allowed ONLY: \"1-10\",\"11-50\",\"51-200\",\"201-500\",\"501-1000\",\"1001-5000\",\"5001-10000\",\"10 000+\"." - added
Input schema / properties / hiring_on_linkedinAdded value: +{ + "description": "Only companies actively hiring — realtime only: using it forces the pricier live mode.", + "type": "boolean" +} - changed
Input schema / properties / industries / descriptionPrevious value: -"Industries. Must match Generect industry names exactly (e.g. \"Software Development\", \"Financial Services\"). Names are hierarchical. Invalid names are rejected (HTTP 400)."New value: +"Company industries. Must match Generect industry names exactly (e.g. \"Software Development\"); unknown names are rejected with HTTP 400." - changed
Input schema / properties / keywords / descriptionPrevious value: -"Free-text keywords (Boolean phrases allowed)."New value: +"Free-text keywords across name/description/specialties — realtime only: using it forces the pricier live mode." - changed
Input schema / properties / limit / descriptionPrevious value: -"Alias for limit_by"New value: +"Alias for limit_by." - changed
Input schema / properties / limit_by / descriptionPrevious value: -"Companies to return (1–100, default 25)."New value: +"Rows to return this call (1–100, default 25). You are billed per returned row, so this number IS the price of the call." - added
Input schema / properties / linkedins_linksAdded value: +{ + "description": "Specific LinkedIn company URLs — realtime only: using it forces the pricier live mode.", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Input schema / properties / locations / descriptionPrevious value: -"Locations (countries/regions, e.g. [\"United States\"])."New value: +"HQ locations — cities, states or countries." - added
Input schema / properties / modeAdded value: +{ + "description": "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 freshness is not critical and cost matters more than freshness.", + "enum": [ + "auto", + "database", + "realtime" + ], + "type": "string" +} - changed
Input schema / properties / num_of_followers / descriptionPrevious value: -"LinkedIn follower-count buckets."New value: +"LinkedIn follower buckets: \"1-50\",\"51-100\",\"101-1000\",\"1001-5000\",\"5001+\" — realtime only: using it forces the pricier live mode." - changed
Input schema / properties / offset / descriptionPrevious value: -"Alias for offset_by"New value: +"Alias for offset_by." - changed
Input schema / properties / offset_by / descriptionPrevious value: -"Offset for pagination."New value: +"Rows to skip (pagination)." - changed
Input schema / properties / revenues_range / descriptionPrevious value: -"Annual revenue range in millions USD, e.g. {\"min\":0.5,\"max\":1001}. Single object, NOT an array."New value: +"Annual revenue range, single object {min,max} — realtime only: using it forces the pricier live mode." - added
Input schema / properties / sub_industriesAdded value: +{ + "description": "Expand each selected industry to its sub-industries as well (broadens the match).", + "type": "boolean" +} - changed
Input schema / properties / technologies / descriptionPrevious value: -"Technologies the company uses (BuiltWith taxonomy)."New value: +"Technologies the company uses — realtime only: using it forces the pricier live mode." - changed
Input schema / properties / timeout_ms / descriptionPrevious value: -"Request timeout in milliseconds"New value: +"Request timeout in milliseconds."
- Changed
search_leads46 fields changed- changed
Input schema / properties / changed_jobs / descriptionPrevious value: -"Only leads who recently changed jobs."New value: +"Only leads who recently changed jobs — realtime only: using it forces the pricier live mode." - changed
Input schema / properties / compact / descriptionPrevious value: -"Default true: return a 9-field summary per lead (name/title/company/industry/location/linkedin_url). Set false for the full raw lead object (skills, experience, etc.). Neither mode includes email — use generate_email."New value: +"Default 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." - added
Input schema / properties / company_filtersAdded value: +{ + "additionalProperties": false, + "description": "Optional: only return leads at companies matching these filters (two-level ICP).", + "properties": { + "company_names": { + "description": "Restrict to specific company names — realtime only: using it forces the pricier live mode.", + "items": { + "type": "string" + }, + "type": "array" + }, + "company_types": { + "description": "Company types: \"Public Company\",\"Privately Held\",\"Non Profit\",\"Government Agency\",\"Educational\", …", + "items": { + "type": "string" + }, + "type": "array" + }, + "department_headcount": { + "additionalProperties": false, + "description": "Department size, e.g. {\"name\":\"engineering\",\"min\":10,\"max\":100} — realtime only: using it forces the pricier live mode.", + "properties": { + "max": { + "type": "number" + }, + "min": { + "type": "number" + }, + "name": { + "type": "string" + } + }, + "required": [ + "name" + ], + "type": "object" + }, + "exclude_domains": { + "description": "Exclude companies by domain (e.g. existing customers).", + "items": { + "type": "string" + }, + "type": "array" + }, + "exclude_ids": { + "description": "Exclude companies by LinkedIn id/URN.", + "items": { + "type": [ + "string", + "number" + ] + }, + "type": "array" + }, + "exclude_industries": { + "description": "Industries to exclude.", + "items": { + "type": "string" + }, + "type": "array" + }, + "exclude_locations": { + "description": "HQ locations to exclude.", + "items": { + "type": "string" + }, + "type": "array" + }, + "headcount_growth": { + "additionalProperties": false, + "description": "Headcount growth in percent — realtime only: using it forces the pricier live mode.", + "properties": { + "max": { + "type": "number" + }, + "min": { + "type": "number" + } + }, + "type": "object" + }, + "headcounts": { + "description": "Size buckets. Allowed ONLY: \"1-10\",\"11-50\",\"51-200\",\"201-500\",\"501-1000\",\"1001-5000\",\"5001-10000\",\"10 000+\".", + "items": { + "type": "string" + }, + "type": "array" + }, + "hiring_on_linkedin": { + "description": "Only companies actively hiring — realtime only: using it forces the pricier live mode.", + "type": "boolean" + }, + "industries": { + "description": "Company industries. Must match Generect industry names exactly (e.g. \"Software Development\"); unknown names are rejected with HTTP 400.", + "items": { + "type": "string" + }, + "type": "array" + }, + "keywords": { + "description": "Free-text keywords across name/description/specialties — realtime only: using it forces the pricier live mode.", + "items": { + "type": "string" + }, + "type": "array" + }, + "linkedins_links": { + "description": "Specific LinkedIn company URLs — realtime only: using it forces the pricier live mode.", + "items": { + "type": "string" + }, + "type": "array" + }, + "locations": { + "description": "HQ locations — cities, states or countries.", + "items": { + "type": "string" + }, + "type": "array" + }, + "num_of_followers": { + "description": "LinkedIn follower buckets: \"1-50\",\"51-100\",\"101-1000\",\"1001-5000\",\"5001+\" — realtime only: using it forces the pricier live mode.", + "items": { + "type": "string" + }, + "type": "array" + }, + "revenues_range": { + "additionalProperties": false, + "description": "Annual revenue range, single object {min,max} — realtime only: using it forces the pricier live mode.", + "properties": { + "max": { + "type": "number" + }, + "min": { + "type": "number" + } + }, + "required": [ + "min", + "max" + ], + "type": "object" + }, + "sub_industries": { + "description": "Expand each selected industry to its sub-industries as well (broadens the match).", + "type": "boolean" + }, + "technologies": { + "description": "Technologies the company uses — realtime only: using it forces the pricier live mode.", + "items": { + "type": "string" + }, + "type": "array" + } + }, + "type": "object" +} - changed
Input schema / properties / company_id / descriptionPrevious value: -"Anchor to a specific LinkedIn company id (returns its employees; this branch is less deterministic and does not enforce lead_industries)."New value: +"Anchor to one company by LinkedIn numeric id." - changed
Input schema / properties / company_id / typePrevious value: -"string"New value: +[ + "string", + "number" +] - changed
Input schema / properties / company_industries / descriptionPrevious value: -"Filter by the lead employer's industry (same taxonomy as lead_industries)."New value: +"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." - changed
Input schema / properties / company_link / descriptionPrevious value: -"Anchor to a specific LinkedIn company URL."New value: +"Anchor to one company by LinkedIn URL." - changed
Input schema / properties / company_locations / descriptionPrevious value: -"Filter by the employer HQ location (country/region names)."New value: +"HQ location of the lead's current employer." - changed
Input schema / properties / company_name / descriptionPrevious value: -"Anchor to a specific company by name."New value: +"Anchor to one company by name (exclusive with company_link/company_id)." - changed
Input schema / properties / company_types / descriptionPrevious value: -"Employer types: \"Public Company\",\"Educational\",\"Self Employed\",\"Government Agency\",\"Non Profit\",\"Self Owned\",\"Privately Held\",\"Partnership\"."New value: +"Employer types: \"Public Company\",\"Privately Held\",\"Non Profit\",\"Government Agency\",\"Educational\",\"Self Employed\",\"Self Owned\",\"Partnership\"." - added
Input schema / properties / exclude_company_headcountsAdded value: +{ + "description": "Employer size buckets to exclude.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / exclude_company_industriesAdded value: +{ + "description": "Employer industries to exclude.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / exclude_company_locationsAdded value: +{ + "description": "Employer HQ locations to exclude.", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Input schema / properties / exclude_ids / descriptionPrevious value: -"sales_ids to exclude — pass the ids of leads already returned in prior calls to paginate/deduplicate."New value: +"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." - added
Input schema / properties / exclude_locationsAdded value: +{ + "description": "Lead locations to exclude.", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Input schema / properties / exclude_names / descriptionPrevious value: -"Full names to exclude from results."New value: +"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." - changed
Input schema / properties / exclude_title_keywords / descriptionPrevious value: -"Title keywords to exclude from persona matching. Defaults to [assistant, intern, junior, student, trainee]; pass [] to disable."New value: +"DEPRECATED — accepted but ignored. No v1 equivalent. Narrow job_titles instead, or filter the returned rows yourself." - removed
Input schema / properties / exclude_title_keywords / itemsRemoved value: -{ - "type": "string" -} - removed
Input schema / properties / exclude_title_keywords / typeRemoved value: -"array" - added
Input schema / properties / filter_empty_varsAdded value: +{ + "description": "Drop leads where these fields are empty, e.g. [\"profile_photo\",\"job_started_on\"]. Useful to raise data quality before paying.", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Input schema / properties / functions / descriptionPrevious value: -"Job functions (LinkedIn Sales-Nav categories, e.g. [\"Engineering\",\"Operations\",\"Marketing\",\"Sales\",\"Finance\"]). Validated by the API."New value: +"Job functions, e.g. [\"Sales\",\"Marketing\",\"Engineering\"] — realtime only: using it forces the pricier live mode." - changed
Input schema / properties / get_max_leads / descriptionPrevious value: -"Also report the total number of matching leads (results_count). The number of rows returned is still bounded by limit_by."New value: +"DEPRECATED — accepted but ignored. Always on now: search responses include results_count without asking." - removed
Input schema / properties / get_max_leads / typeRemoved value: -"boolean" - changed
Input schema / properties / job_title / descriptionPrevious value: -"Single job title (e.g., \"CEO\"). For multiple titles use job_titles."New value: +"DEPRECATED alias for job_titles. Still honoured: it is merged into job_titles." - changed
Input schema / properties / job_titles / descriptionPrevious value: -"One or more target job titles, OR-matched (e.g. [\"CEO\",\"Founder\",\"Owner\",\"President\"]). Preferred over job_title. Assistant/intern/junior/student/trainee are excluded by default; override with exclude_title_keywords."New value: +"Target job titles, OR-matched (e.g. [\"CEO\",\"Founder\",\"Owner\"]). A lead needs to match only one." - changed
Input schema / properties / keywords / descriptionPrevious value: -"Free-text keywords matched against the profile (Boolean phrases allowed)."New value: +"Free-text keywords across headline/summary/skills — realtime only: using it forces the pricier live mode." - changed
Input schema / properties / lead_industries / descriptionPrevious value: -"Lead personal-industry filter. Must match Generect industry names exactly (e.g. \"Financial Services\", \"IT Services and IT Consulting\"). Names are hierarchical (Financial Services includes Banking/Insurance). Invalid names are rejected (HTTP 400)."New value: +"DEPRECATED — accepted but ignored. Removed: v1 filters on the employer's industry. Use company_industries." - removed
Input schema / properties / lead_industries / itemsRemoved value: -{ - "type": "string" -} - removed
Input schema / properties / lead_industries / typeRemoved value: -"array" - changed
Input schema / properties / limit / descriptionPrevious value: -"Alias for limit_by"New value: +"Alias for limit_by." - changed
Input schema / properties / limit_by / descriptionPrevious value: -"Total leads to return this call (1–100, default 25). This is a TOTAL cap across all personas. For more, paginate with exclude_ids."New value: +"Rows to return this call (1–100, default 25). You are billed per returned row, so this number IS the price of the call." - added
Input schema / properties / linkedin_filter_linkAdded value: +{ + "description": "A LinkedIn / Sales Navigator search URL to lift filters from — realtime only: using it forces the pricier live mode.", + "type": "string" +} - changed
Input schema / properties / locations / descriptionPrevious value: -"Lead location filter — country/region names, e.g. [\"United States\",\"Canada\"]."New value: +"Where the lead lives — matches cities, states and countries, e.g. [\"United States\",\"Berlin\"]." - added
Input schema / properties / modeAdded value: +{ + "description": "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 freshness is not critical and cost matters more than freshness.", + "enum": [ + "auto", + "database", + "realtime" + ], + "type": "string" +} - changed
Input schema / properties / offset / descriptionPrevious value: -"Alias for offset_by"New value: +"Alias for offset_by." - changed
Input schema / properties / offset_by / descriptionPrevious value: -"Offset for pagination (note: ordering is not stable — exclude_ids is more reliable)."New value: +"Rows to skip (pagination)." - added
Input schema / properties / past_company_namesAdded value: +{ + "description": "Companies the lead previously worked at (alumni targeting) — realtime only: using it forces the pricier live mode.", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Input schema / properties / personas / descriptionPrevious value: -"Advanced: raw persona tuples [label,[titles],[secondary],[exclusions],seniority?]. Overrides job_title/job_titles."New value: +"Advanced raw persona tuples [name, functions, seniorities, prohibits, priority?] — realtime only: using it forces the pricier live mode." - changed
Input schema / properties / posted_on_linkedin / descriptionPrevious value: -"Only leads who recently posted on LinkedIn."New value: +"Only leads who recently posted on LinkedIn — realtime only: using it forces the pricier live mode." - changed
Input schema / properties / seniorities / descriptionPrevious value: -"Seniority levels (LinkedIn Sales-Nav categories, e.g. [\"Director\",\"VP\",\"Head\",\"Owner\",\"Manager\"]). Validated by the API."New value: +"Seniority at the current employer, e.g. [\"Owner\",\"CXO\",\"VP\",\"Director\",\"Manager\"]. Current position only." - added
Input schema / properties / strictAdded value: +{ + "description": "Fields to match strictly, e.g. [\"company_locations\"].", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Input schema / properties / timeout_ms / descriptionPrevious value: -"Request timeout in milliseconds"New value: +"Request timeout in milliseconds." - changed
Input schema / properties / without_company / descriptionPrevious value: -"Search across all companies (filter-only). Auto-enabled when no company_id/link/name is given; this branch enforces all filters. Ignored when a company anchor is set."New value: +"DEPRECATED — accepted but ignored. No longer needed — v1 filter-only search is the default when no company anchor is set." - removed
Input schema / properties / without_company / typeRemoved value: -"boolean" - added
Input schema / properties / years_in_companyAdded value: +{ + "description": "Time at current company, same buckets as years_in_position — realtime only: using it forces the pricier live mode.", + "items": { + "type": "number" + }, + "type": "array" +} - added
Input schema / properties / years_in_positionAdded value: +{ + "description": "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.", + "items": { + "type": "number" + }, + "type": "array" +}
- Added
start_bulk_job - Added
validate_email
4 tool updates
- Changed
generate_email6 fields changed- added
Input schema / properties / candidatesAdded value: +{ + "description": "Batch mode: resolve many people in one call. Each needs first_name, last_name, domain (middle_name optional).", + "items": { + "additionalProperties": false, + "properties": { + "domain": { + "type": "string" + }, + "first_name": { + "type": "string" + }, + "last_name": { + "type": "string" + }, + "middle_name": { + "type": "string" + } + }, + "required": [ + "first_name", + "last_name", + "domain" + ], + "type": "object" + }, + "type": "array" +} - changed
Input schema / properties / domain / descriptionPrevious value: -"Company domain without protocol (e.g., generect.com)"New value: +"Company domain without protocol, e.g. \"generect.com\" (required in single-person mode)." - changed
Input schema / properties / first_name / descriptionPrevious value: -"First name of the person"New value: +"First name (single-person mode)." - changed
Input schema / properties / last_name / descriptionPrevious value: -"Last name of the person"New value: +"Last name (single-person mode)." - added
Input schema / properties / middle_nameAdded value: +{ + "description": "Middle name (optional).", + "type": "string" +} - removed
Input schema / requiredRemoved value: -[ - "first_name", - "last_name", - "domain" -]
- Changed
health2 fields changed- added
Input schema / properties / deepAdded value: +{ + "description": "Run a live API probe (lead-by-link). Consumes a credit. Default false.", + "type": "boolean" +} - changed
Input schema / properties / url / descriptionPrevious value: -"LinkedIn profile URL to validate (defaults to a public profile)"New value: +"LinkedIn profile URL for the deep probe (defaults to a public profile)."
- Changed
search_companies15 fields changed- changed
Input schema / properties / compact / descriptionPrevious value: -"Return compact summary instead of full JSON"New value: +"Default true: 6-field summary per company. Set false for the full raw object." - added
Input schema / properties / company_namesAdded value: +{ + "description": "Restrict to specific company names.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / exclude_industriesAdded value: +{ + "description": "Industries to exclude (same taxonomy as industries).", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / exclude_locationsAdded value: +{ + "description": "Locations to exclude.", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Input schema / properties / fallback_from_leads / descriptionPrevious value: -"If no companies, derive from leads by keywords"New value: +"Default FALSE. If true and the company search is empty, derive candidate company NAMES by aggregating a keyword lead search. These are lead-derived name counts (source:\"leads_derived\"), NOT real company records, and cost an extra query." - changed
Input schema / properties / get_max_companies / descriptionPrevious value: -"Get maximum companies"New value: +"Also report the total number of matching companies." - changed
Input schema / properties / headcounts / descriptionPrevious value: -"Employee headcount ranges. Allowed values ONLY: \"1\", \"2-10\", \"11-50\", \"51-200\", \"201-500\", \"501-1000\", \"1001-5000\", \"5001-10000\", \"10000+\". Note the largest bucket is \"10000+\" (NOT \"10001+\")."New value: +"Employee headcount 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+\")." - changed
Input schema / properties / industries / descriptionPrevious value: -"Industries. Must match Generect industry names exactly (e.g. \"Software Development\", \"Financial Services\"). Invalid names are rejected by the API."New value: +"Industries. Must match Generect industry names exactly (e.g. \"Software Development\", \"Financial Services\"). Names are hierarchical. Invalid names are rejected (HTTP 400)." - changed
Input schema / properties / keywords / descriptionPrevious value: -"Keywords"New value: +"Free-text keywords (Boolean phrases allowed)." - changed
Input schema / properties / limit_by / descriptionPrevious value: -"Number of results to return"New value: +"Companies to return (1–100, default 25)." - changed
Input schema / properties / locations / descriptionPrevious value: -"Locations (countries, e.g. [\"United States\"])"New value: +"Locations (countries/regions, e.g. [\"United States\"])." - added
Input schema / properties / num_of_followersAdded value: +{ + "description": "LinkedIn follower-count buckets.", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Input schema / properties / offset_by / descriptionPrevious value: -"Offset for pagination"New value: +"Offset for pagination." - added
Input schema / properties / revenues_rangeAdded value: +{ + "additionalProperties": false, + "description": "Annual revenue range in millions USD, e.g. {\"min\":0.5,\"max\":1001}. Single object, NOT an array.", + "properties": { + "max": { + "type": "number" + }, + "min": { + "type": "number" + } + }, + "required": [ + "min", + "max" + ], + "type": "object" +} - added
Input schema / properties / technologiesAdded value: +{ + "description": "Technologies the company uses (BuiltWith taxonomy).", + "items": { + "type": "string" + }, + "type": "array" +}
- Changed
search_leads25 fields changed- added
Input schema / properties / changed_jobsAdded value: +{ + "description": "Only leads who recently changed jobs.", + "type": "boolean" +} - changed
Input schema / properties / compact / descriptionPrevious value: -"Return compact summary instead of full JSON"New value: +"Default true: return a 9-field summary per lead (name/title/company/industry/location/linkedin_url). Set false for the full raw lead object (skills, experience, etc.). Neither mode includes email — use generate_email." - added
Input schema / properties / company_headcountsAdded value: +{ + "description": "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+\").", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Input schema / properties / company_id / descriptionPrevious value: -"LinkedIn company id"New value: +"Anchor to a specific LinkedIn company id (returns its employees; this branch is less deterministic and does not enforce lead_industries)." - added
Input schema / properties / company_industriesAdded value: +{ + "description": "Filter by the lead employer's industry (same taxonomy as lead_industries).", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Input schema / properties / company_link / descriptionPrevious value: -"LinkedIn company URL"New value: +"Anchor to a specific LinkedIn company URL." - added
Input schema / properties / company_locationsAdded value: +{ + "description": "Filter by the employer HQ location (country/region names).", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Input schema / properties / company_name / descriptionPrevious value: -"Company name"New value: +"Anchor to a specific company by name." - added
Input schema / properties / company_typesAdded value: +{ + "description": "Employer types: \"Public Company\",\"Educational\",\"Self Employed\",\"Government Agency\",\"Non Profit\",\"Self Owned\",\"Privately Held\",\"Partnership\".", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / exclude_idsAdded value: +{ + "description": "sales_ids to exclude — pass the ids of leads already returned in prior calls to paginate/deduplicate.", + "items": { + "type": [ + "string", + "number" + ] + }, + "type": "array" +} - added
Input schema / properties / exclude_namesAdded value: +{ + "description": "Full names to exclude from results.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / exclude_title_keywordsAdded value: +{ + "description": "Title keywords to exclude from persona matching. Defaults to [assistant, intern, junior, student, trainee]; pass [] to disable.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / functionsAdded value: +{ + "description": "Job functions (LinkedIn Sales-Nav categories, e.g. [\"Engineering\",\"Operations\",\"Marketing\",\"Sales\",\"Finance\"]). Validated by the API.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / get_max_leadsAdded value: +{ + "description": "Also report the total number of matching leads (results_count). The number of rows returned is still bounded by limit_by.", + "type": "boolean" +} - changed
Input schema / properties / job_title / descriptionPrevious value: -"Job title filter (e.g., CEO, CTO, Engineer)"New value: +"Single job title (e.g., \"CEO\"). For multiple titles use job_titles." - added
Input schema / properties / job_titlesAdded value: +{ + "description": "One or more target job titles, OR-matched (e.g. [\"CEO\",\"Founder\",\"Owner\",\"President\"]). Preferred over job_title. Assistant/intern/junior/student/trainee are excluded by default; override with exclude_title_keywords.", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / keywordsAdded value: +{ + "description": "Free-text keywords matched against the profile (Boolean phrases allowed).", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Input schema / properties / lead_industries / descriptionPrevious value: -"Industry filter. Must match Generect industry names exactly (e.g. \"Information Technology and Services\", \"Financial Services\"). Invalid names are rejected by the API."New value: +"Lead personal-industry filter. Must match Generect industry names exactly (e.g. \"Financial Services\", \"IT Services and IT Consulting\"). Names are hierarchical (Financial Services includes Banking/Insurance). Invalid names are rejected (HTTP 400)." - changed
Input schema / properties / limit_by / descriptionPrevious value: -"Number of results to return"New value: +"Total leads to return this call (1–100, default 25). This is a TOTAL cap across all personas. For more, paginate with exclude_ids." - changed
Input schema / properties / locations / descriptionPrevious value: -"Location filter — country or region names, e.g. [\"United States\", \"Canada\"]"New value: +"Lead location filter — country/region names, e.g. [\"United States\",\"Canada\"]." - changed
Input schema / properties / offset_by / descriptionPrevious value: -"Offset for pagination"New value: +"Offset for pagination (note: ordering is not stable — exclude_ids is more reliable)." - added
Input schema / properties / personasAdded value: +{ + "description": "Advanced: raw persona tuples [label,[titles],[secondary],[exclusions],seniority?]. Overrides job_title/job_titles.", + "type": "array" +} - added
Input schema / properties / posted_on_linkedinAdded value: +{ + "description": "Only leads who recently posted on LinkedIn.", + "type": "boolean" +} - added
Input schema / properties / senioritiesAdded value: +{ + "description": "Seniority levels (LinkedIn Sales-Nav categories, e.g. [\"Director\",\"VP\",\"Head\",\"Owner\",\"Manager\"]). Validated by the API.", + "items": { + "type": "string" + }, + "type": "array" +} - changed
Input schema / properties / without_company / descriptionPrevious value: -"Search leads without filtering by companies"New value: +"Search across all companies (filter-only). Auto-enabled when no company_id/link/name is given; this branch enforces all filters. Ignored when a company anchor is set."
2 tool updates
- Changed
search_companies6 fields changed- changed
Input schema / properties / company_types / descriptionPrevious value: -"Company types"New value: +"Company types. Allowed values: \"Public Company\", \"Educational\", \"Self Employed\", \"Government Agency\", \"Non Profit\", \"Self Owned\", \"Privately Held\", \"Partnership\"." - changed
Input schema / properties / headcounts / descriptionPrevious value: -"Headcount ranges"New value: +"Employee headcount ranges. Allowed values ONLY: \"1\", \"2-10\", \"11-50\", \"51-200\", \"201-500\", \"501-1000\", \"1001-5000\", \"5001-10000\", \"10000+\". Note the largest bucket is \"10000+\" (NOT \"10001+\")." - changed
Input schema / properties / industries / descriptionPrevious value: -"Industries"New value: +"Industries. Must match Generect industry names exactly (e.g. \"Software Development\", \"Financial Services\"). Invalid names are rejected by the API." - added
Input schema / properties / limitAdded value: +{ + "description": "Alias for limit_by", + "type": "number" +} - changed
Input schema / properties / locations / descriptionPrevious value: -"Locations (Countries, e.g \"United States\")"New value: +"Locations (countries, e.g. [\"United States\"])" - added
Input schema / properties / offsetAdded value: +{ + "description": "Alias for offset_by", + "type": "number" +}
- Changed
search_leads5 fields changed- changed
Input schema / properties / lead_industries / descriptionPrevious value: -"Industry filter (e.g., Technology, Healthcare)"New value: +"Industry filter. Must match Generect industry names exactly (e.g. \"Information Technology and Services\", \"Financial Services\"). Invalid names are rejected by the API." - added
Input schema / properties / limitAdded value: +{ + "description": "Alias for limit_by", + "type": "number" +} - changed
Input schema / properties / locations / descriptionPrevious value: -"Location filter (e.g., San Francisco, New York)"New value: +"Location filter — country or region names, e.g. [\"United States\", \"Canada\"]" - added
Input schema / properties / offsetAdded value: +{ + "description": "Alias for offset_by", + "type": "number" +} - changed
Input schema / properties / without_company / descriptionPrevious value: -"Search leads without filrest by companies"New value: +"Search leads without filtering by companies"
2 tool updates
- Changed
search_companies4 fields changed- added
Input schema / properties / limit_byAdded value: +{ + "description": "Number of results to return", + "type": "number" +} - added
Input schema / properties / locationsAdded value: +{ + "description": "Locations (Countries, e.g \"United States\")", + "items": { + "type": "string" + }, + "type": "array" +} - removed
Input schema / properties / max_itemsRemoved value: -{ - "description": "Maximum items to include in response (local trim)", - "type": "number" -} - added
Input schema / properties / offset_byAdded value: +{ + "description": "Offset for pagination", + "type": "number" +}
- Changed
search_leads10 fields changed- removed
Input schema / properties / industryRemoved value: -{ - "description": "Industry filter (e.g., Technology, Healthcare)", - "type": "string" -} - added
Input schema / properties / lead_industriesAdded value: +{ + "description": "Industry filter (e.g., Technology, Healthcare)", + "items": { + "type": "string" + }, + "type": "array" +} - removed
Input schema / properties / limitRemoved value: -{ - "description": "Number of results to return", - "type": "number" -} - added
Input schema / properties / limit_byAdded value: +{ + "description": "Number of results to return", + "type": "number" +} - removed
Input schema / properties / locationRemoved value: -{ - "description": "Location filter (e.g., San Francisco, New York)", - "type": "string" -} - added
Input schema / properties / locationsAdded value: +{ + "description": "Location filter (e.g., San Francisco, New York)", + "items": { + "type": "string" + }, + "type": "array" +} - removed
Input schema / properties / max_itemsRemoved value: -{ - "description": "Maximum items to include in response (local trim)", - "type": "number" -} - removed
Input schema / properties / offsetRemoved value: -{ - "description": "Offset for pagination", - "type": "number" -} - added
Input schema / properties / offset_byAdded value: +{ + "description": "Offset for pagination", + "type": "number" +} - added
Input schema / properties / without_companyAdded value: +{ + "description": "Search leads without filrest by companies", + "type": "boolean" +}
5 tool updates
- First observed
generate_email - First observed
get_lead_by_url - First observed
health - First observed
search_companies - First observed
search_leads
Related MCP Connectors
Real-time B2B data for agents: search and enrich 1B+ people and 200M+ company profiles.
Lead enrichment for AI agents: email finder, company enrichment, people data, firmographics.
Search companies, enrich contacts, and reveal emails and phones from your AI agent.
B2B data enrichment: verified work emails, phones, firmographics, tech stack, hiring signals.
Related MCP Servers
AlicenseAqualityFmaintenanceEnables AI tools to search and enrich B2B leads, including finding professional emails, company profiles, and filtering people and companies by various criteria.5468 npmMIT- FlicenseNot gradedqualityBmaintenanceEnables AI assistants to search, enrich, and score B2B leads in real time from a database of 10M+ companies.-
- AlicenseAqualityDmaintenanceGive your AI agent access to 60M+ companies and 300M+ verified contacts. Enrich leads, find work emails, discover tech stacks, and identify buying intent — directly from Claude, Cursor, Windsurf, or any MCP-compatible AI agent.118 npmMIT
- FlicenseAqualityDmaintenanceEnables AI agents to research companies and find contacts with structured data from multiple free sources, including company info, tech stack, and email addresses.3-
Glama MCP Gateway
Add one secure layer between your agents and this server.