Generect Live API MCP Server

Official

Overview Schema Source Related Servers Discussions(1)Admin

Validate email deliverability

validate_email

Check deliverability of existing email addresses before sending. Each submitted address is billed and returns a deliverability verdict.

Instructions

Check deliverability of emails you already have. Billable: about $0.005 per email submitted (every address is billed, whatever the verdict) 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. This is the one operation where every submitted address is billed: the verdict is the deliverable. An address generate_email returned as valid is already verified, so validating it again only adds cost.

Input Schema

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	Default
`cost`	No
`results`	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.

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

Behavior5/5

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

Goes well beyond the annotations: discloses per-address billing regardless of verdict, the approximate Tier 0 price ($0.005), that account-specific rates exist and are retrievable via get_balance, and that actual spend appears in cost.amount_charged_usd. The readOnlyHint=false / openWorldHint=true annotations are consistent with a billable external lookup; 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.

Conciseness4/5

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

Purpose is front-loaded, followed by pricing and then the re-validation caveat. The billing point is restated twice ('every address is billed' and 'every submitted address is billed'), which is slightly redundant but defensible given the cost implication.

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

Completeness5/5

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

An output schema exists, so return values needn't be explained, and the description still names the cost field to look for. Billing, pricing lookup, and the duplicate-validation pitfall are all covered; an agent has everything needed to call it responsibly.

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%, including 'Each one is billed' for emails, so the schema already carries parameter meaning. The description reinforces the billing-per-address semantics but adds nothing about timeout_ms or input format. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb+resource and scope: 'Check deliverability of emails you already have'. The qualifier 'you already have' distinguishes it from the sibling generate_email, which produces addresses rather than validating existing ones.

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?

Explicitly warns against re-validating addresses that generate_email already returned as valid, which is a real when-not-to-use rule. It also routes pricing questions to get_balance. It doesn't contrast with enrich_lead or enrich_company, which may also surface validation-adjacent data, so it stops short of full sibling routing.

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