Generect Live API MCP Server

Official

by generect

Overview Schema Source Related Servers Discussions(1)Admin

TypeScript

Hybrid

Find a verified work email

generate_email

Read-only

Find and verify a work email using a lead ID, LinkedIn URL, or name and company domain. Supports batch resolution of several people and async bulk jobs for larger lists.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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

TableJSON Schema

Name	Required	Description	Default
`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

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv0.9.0Sep 24, 2026

addedInput schema / properties / candidates

Added value: +{
+  "description": "Batch mode. Each entry uses the same identifier rules as the single-person form.",
+  "items": {
+    "additionalProperties": false,
+    "description": "One of: {lead_id} | {linkedin_url} | {first_name,last_name,domain}",
+    "properties": {
+      "domain": {
+        "type": "string"
+      },
+      "first_name": {
+        "type": "string"
+      },
+      "last_name": {
+        "type": "string"
+      },
+      "lead_id": {
+        "type": "string"
+      },
+      "linkedin_url": {
+        "type": "string"
+      },
+      "middle_name": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}

changedInput schema / properties / domain / description

Previous value: -"Company domain without protocol (e.g., generect.com)"New value: +"Company domain without protocol, e.g. \"stripe.com\" (name+domain mode)."

changedInput schema / properties / first_name / description

Previous value: -"First name of the person"New value: +"First name (name+domain mode)."

changedInput schema / properties / last_name / description

Previous value: -"Last name of the person"New value: +"Last name (name+domain mode)."

addedInput schema / properties / lead_id

Added value: +{
+  "description": "Generect lead id from search / preview / enrich results — the cheapest and most accurate identifier.",
+  "type": "string"
+}

addedInput schema / properties / linkedin_url

Added value: +{
+  "description": "LinkedIn profile URL.",
+  "type": "string"
+}

addedInput schema / properties / middle_name

Added value: +{
+  "description": "Middle name (optional, improves pattern matching).",
+  "type": "string"
+}

changedInput schema / properties / timeout_ms / description

Previous value: -"Request timeout in milliseconds"New value: +"Request timeout in milliseconds."

removedInput schema / required

Removed value: -[
-  "first_name",
-  "last_name",
-  "domain"
-]

changedOutput 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"
+}

First observedv0.1.0May 26, 2026

TDQS

A4.3/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server