MCP server for the Enrow API — find and verify professional emails and phone numbers from any AI assistant
Enrow MCP demonstrates solid definition quality with consistent naming patterns, comprehensive parameter schemas using Zod, and clear descriptions for most tools. All 12 tools follow verb_noun naming (find_*, get_*, verify_*) and include descriptions. Schemas are well-structured with type definitions and parameter descriptions. However, output schemas are not explicitly documented, responses are returned as plain JSON text without formal schema declarations. Error handling is present but generic (HTTP status + message). Tool descriptions average ~150 chars, within the 10-1024 baseline. Parameter descriptions are present but some lack format/constraint details (e.g., 'id' params don't specify format or length). The async polling pattern (find_* returns id, get_* retrieves result) is well-documented but adds cognitive load for agents.
Find a professional email address from a name and a company domain or name. At least one of company_domain or company_name is required. Asynchronous: returns a search id, then poll get_email_result.
Find multiple email addresses in bulk (up to 5,000 per batch). Asynchronous: returns a batch id, then poll get_emails_bulk_result.
Find a mobile phone number from a LinkedIn URL (recommended) or first name + last name + company. Asynchronous: returns a search id, then poll get_phone_result.
Find multiple phone numbers in bulk (up to 3,000 per batch). Asynchronous: returns a batch id, then poll get_phones_bulk_result.
Retrieve the result of a previously launched email search
Retrieve results of a bulk email search
Output schemas not formally documented. Tools return plain JSON text responses without declared response schemas. LLMs cannot predict output structure for downstream planning.
Async polling pattern requires agents to manage state across multiple calls. No guidance on polling interval, timeout, or max retries. Agents may retry indefinitely or give up too early.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Retrieve the result of a previously launched phone search
Retrieve results of a bulk phone search
Retrieve the result of a previously launched email verification
Retrieve results of a bulk email verification
Verify if an email address is deliverable. Works on catch-all domains. Asynchronous: returns a verification id, then poll get_verification_result.
Verify multiple email addresses in bulk (up to 5,000 per batch). Asynchronous: returns a batch id, then poll get_verifications_bulk_result.
Error messages are generic HTTP status + detail. No recovery guidance. E.g., 'Error 400: ...' tells agent nothing about whether to retry, ask user, or abort.
Parameter descriptions lack format/constraint details. E.g., 'id' params don't specify expected format (UUID, alphanumeric, length). LLMs may pass invalid IDs.
Bulk tools accept arrays without documented limits. find_emails_bulk says 'up to 5,000' but no validation or error if exceeded. find_phones_bulk says 'max 3,000' but inconsistent with email limit.