Generect Live API MCP Server

Official

Overview Schema Source Related Servers Discussions(1)Admin

Find a phone number (most expensive)

find_phone

Finds a phone number for a single person using a lead ID, name plus company/domain, or LinkedIn URL, so you can contact a specific qualified prospect.

Instructions

Find a phone number for one person. Billable: about $0.4 per phone found (a miss is free) at the Tier 0 list price. Accounts can pay a different rate: get_balance returns this account's prices, and every response reports what was actually spent in cost.amount_charged_usd. The most expensive operation here, roughly 20x an email lookup, so it suits people the user has already qualified rather than a whole list. start_bulk_job takes an approved list.

Input Schema

Name	Required	Description
`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	Default
`cost`	No
`result`	No
`test_mode`	No
`test_mode_notice`	No
`vocabulary_warnings`	No
`deprecated_params_ignored`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.12.2Oct 16, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

removedInput schema / additionalProperties
```
Removed value: -false
```

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedOutput schema / properties / deprecated_params_ignored / propertyNames
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / vocabulary_warnings / items
```
Added value: +{}
```

Addedv0.9.0Sep 24, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: a concrete price (~$0.4 per hit, misses free), the Tier 0 list-price caveat, the per-account variance and how to check it, and where the actual charge appears in the response (cost.amount_charged_usd). That is exactly the billing disclosure annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true) do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then pricing, then the volume guidance — a sensible order with no filler. The pricing paragraph is slightly long (list price, account rate, response field all in one breath) but each clause carries real decision value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema and annotations, the description covers scope, cost, and volume routing well. The remaining gap is input-side: with zero required parameters, an agent gets no hint here about which identifier combination is valid, relying entirely on schema text.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains every parameter including lead_id being "the cheapest and most accurate identifier." The description adds nothing about the name+domain vs name+company modes or the fact that all seven parameters are optional and must be combined, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource scoped to a single person: "Find a phone number for one person." It also implicitly separates itself from the sibling contact tool by referencing "an email lookup" and from list workflows by naming start_bulk_job, so an agent can place it 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.

Usage Guidelines5/5

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

Gives an explicit selection rule: it suits already-qualified people "rather than a whole list," and routes list work to start_bulk_job. It also offers get_balance as the alternative for account-specific pricing, covering both the when-to-use and the where-to-look-next questions.

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