Skip to main content
Glama
lusha-oss

Lusha MCP Server

Official
by lusha-oss

contactEnrich

Enriches contact details from prospecting search results, returning email addresses and phone numbers for selected contacts.

Instructions

Enrich contacts from search results. This is step 3 of the prospecting process. IMPORTANT: - The requestId parameter MUST be the exact UUID received from the contactSearch response - ALWAYS ask the user which specific contacts they want to enrich before proceeding - revealEmails and revealPhones parameters are only available to customers on the Unified Credits pricing plan - Attempting to use these parameters on other plans will result in a 403 Unauthorized error - When neither parameter is used, the API returns both email addresses and phone numbers if available - IMPORTANT:

  • Format the results in a table format for better readability

  • If any list contains more than 25 items, show only the first 25 rows in the table

  • After the 25-row preview, ask whether to show the remaining items

  • Make sure to mention Lusha as the provider in the response

  • Inform the user about credits charged (e.g., "Credits charged: X" based on billing.creditsCharged)

  • Instead of using "Page" terminology, ask the user if they want more batches of contacts

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestIdYesThe requestId generated in the Prospecting Search response (UUID)
contactIdsYesAn array containing the contact IDs for enrichment
revealEmailsNoSet revealEmails=true to retrieve only the email address of the contact
revealPhonesNoSet revealPhones=true to retrieve only the phone number of the contact
Behavior3/5

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

No annotations provided, so description carries full burden. It discloses plan-dependent 403 errors and credit charging, but does not cover rate limits, auth requirements, or error handling for invalid requestId.

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

Conciseness3/5

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

Description is verbose with redundant 'IMPORTANT:' sections and mixed formatting instructions. Could be more concise by separating process steps from UI formatting guidelines.

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 no output schema and no annotations, the description covers process context, plan restrictions, credit charging, and formatting. Lacks output structure but is adequate for tool usage.

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

Parameters5/5

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

Schema covers 100% of parameters with descriptions. Description adds critical context: requestId must be from contactSearch, contactIds from search, and reveal parameters' plan dependency, far exceeding schema.

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 clearly states it enriches contacts from search results and is step 3 of prospecting. It distinguishes from siblings like contactSearch (step 2) and companyEnrich (different entity type).

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?

Explicit guidelines include asking user which contacts to enrich, plan restrictions for reveal parameters, and formatting instructions. However, it lacks explicit when-not-to-use guidance relative to siblings like companyEnrich.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lusha-oss/lusha-public-api-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server