Generect Live API MCP Server

Official

Overview Schema Source Related Servers Discussions(1)Admin

Enrich one company

enrich_company

Retrieves a full company profile by Generect ID, LinkedIn URL, domain, or name. Use this to get detailed business data from the Generect Live API for lead generation or research.

Instructions

Full profile for one known company, by Generect id, LinkedIn URL, domain or name. Billable: about $0.02 per record found (not-found is refunded) 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. Not found costs nothing. Domain is the most reliable identifier after id; name matching is fuzzy.

Input Schema

Name	Required	Description
`id`	No	Generect company id.
`mode`	No	Data mode. "database" = Generect's own index: sub-second, free counts, free thin rows (see detail) or cheaper full rows; it accepts a subset of the filters today and names any it rejects. "realtime" = live LinkedIn lookup, 5–60s, billed per row, accepts every realtime filter. "auto" (default) tries database first and escalates to realtime only if a filter you passed is rejected there (the escalation is reported, and is refused above the per-call spend ceiling). 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	Default
`cost`	No
`lead`	No
`mode`	No
`found`	No
`company`	No
`test_mode`	No
`test_mode_notice`	No
`vocabulary_warnings`	No
`deprecated_params_ignored`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 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
```

changedInput schema / properties / mode / description

Previous value: -"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."New value: +"Data mode. \"database\" = Generect's own index: sub-second, free counts, free thin rows (see detail) or cheaper full rows; it accepts a subset of the filters today and names any it rejects. \"realtime\" = live LinkedIn lookup, 5–60s, billed per row, accepts every realtime filter. \"auto\" (default) tries database first and escalates to realtime only if a filter you passed is rejected there (the escalation is reported, and is refused above the per-call spend ceiling). Pick \"database\" explicitly when a recent cached record is good enough and cost matters more than freshness."

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.2/5.0

Behavior5/5

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

Goes well beyond the annotations: discloses that the call is billable at ~$0.02 per record found, that not-found is refunded, that account-specific pricing is retrievable via get_balance, and that the actual charge appears in cost.amount_charged_usd. That is exactly the financial context an agent needs before spending.

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-loaded with identity and price, and dense with useful detail. Mild redundancy: "(not-found is refunded)" is restated by "Not found costs nothing".

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?

An output schema exists, so return contents need not be described, and cost, identifiers, and modes are covered. The one gap is that all seven parameters are optional and the description never says at least one identifier must be supplied.

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 coverage is 100%, so baseline is 3; the description adds genuine value by ranking identifier reliability (id > domain > fuzzy name) and pointing at the cost field. Mode/compact semantics live in the schema rather than the description, so it does not fully exceed the schema.

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

Purpose4/5

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

States a concrete verb and resource ("Full profile for one known company") and enumerates the four accepted identifiers. The singular, known-entity framing implicitly separates it from search_companies, but no sibling is named explicitly.

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?

Gives real selection guidance on identifiers — domain is the most reliable after id, name matching is fuzzy — and the schema's mode description explains database vs realtime vs auto. It does not explicitly say when to prefer search_companies or resolve_profile over this tool.

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