Lusha MCP Server

Official

by lusha-oss

Overview Schema Related Servers Score Discussions(1)

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.2.0
Disambiguation5/5
Each tool targets a distinct operation: company vs contact, and search/filter/enrich/bulk lookup are clearly separated. No overlapping purposes.
Naming Consistency5/5
All tool names follow a consistent camelCase pattern with entity prefix (company/contact/person) and action (BulkLookup, Enrich, Filters, Search). No mixing of conventions.
Tool Count5/5
Eight tools cover the full prospecting workflow (search, filter, enrich, bulk lookup) for both companies and contacts without being excessive or insufficient.
Completeness5/5
The tool set provides a complete lifecycle for company and contact data access: search with filters, enrichment, and bulk lookup. No obvious gaps for the intended purpose.
Average 4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It lists filter types and mentions that 'locations' requires a parameter, but fails to explain return format, pagination, authentication needs, or error handling. Moreover, the claim that 'requires locationSearchText parameter' conflicts with the schema where locationSearchText is not required, causing potential confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a single introductory sentence followed by a bullet list summarizing all supported filter types. It is front-loaded and contains no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (retrieving filter lists), the description covers the main behavior and parameter linkage. However, it omits details about the response format, how results are structured, and the exact behavior for each filter type (e.g., whether departments returns labels or IDs). The parameter requirement inconsistency also detracts from completeness.
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?
The input schema has 100% coverage with parameter descriptions, so baseline is 3. The description adds value by linking each filter type to its purpose and clarifying that 'locations' needs locationSearchText. However, the statement that locationSearchText is required contradicts the schema's optional definition, slightly undermining clarity.
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?
Description clearly states it retrieves available filter values for contact search and explicitly lists five supported filter types (departments, seniority, etc.), distinguishing it from the sibling 'companyFilters' tool. The verb 'Get' and resource 'filter values' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when populating contact search filters by listing the types, but it does not specify when not to use this tool or mention alternatives (e.g., using companyFilters for company-related data). No explicit usage context or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the external API and parameter usage, but does not disclose rate limits, pagination, or what happens if data is missing. The read-only nature is implied by 'look up' but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences and two bullet points, front-loading the core purpose. Every sentence adds essential value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing crucial context: no mention of return format or output structure, given there is no output schema. Does not differentiate from sibling tools like contactEnrich. For a complex nested schema, this is a significant gap.
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 coverage is 0%, so the description must compensate. It explains the required combinations for each contact and the reveal flags, but does not detail other fields like contactId, metadata.filterBy, or nested company properties. Adds moderate value beyond the raw 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?
The description clearly states it looks up person information from the Lusha API, supporting both single and multiple lookups. The verb 'look up' is specific. However, it does not explicitly differentiate from sibling tools like contactEnrich or contactSearch, though the 'bulk' nature is implied.
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 explicitly lists required input combinations (LinkedIn URL, full name+company, or email) and warns against using revealEmails/revealPhones unless requested. This provides clear when-to-use guidance, though it lacks explicit comparison to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('look up') but does not disclose behavioral traits beyond input requirements. No annotations are provided, so the description carries the full burden, yet it omits details like rate limits, authentication, or response behavior when a company is not found.
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 concise (two sentences plus bullet list) and front-loaded with the action. It efficiently states the purpose and requirements without unnecessary words. Minor improvement would be better formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, no output schema, no annotations), the description lacks completeness. It does not mention the max limit of 100 companies (though schema has maxItems), return format, error handling, or what happens if a lookup fails. The tool requires more context for an agent to use correctly.
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 coverage is 0%, so the description must compensate. It adds meaning by specifying that each company must have a unique id and at least one of the four identifiers, and mentions the metadata parameter exists (though not explained). However, it does not fully explain all parameters or the purpose of metadata.
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 looks up companies information from Lusha API, with a specific verb 'look up' and resource 'companies information'. It distinguishes from sibling tools like companySearch (search) and companyEnrich (enrich) by focusing on bulk lookup by known identifiers.
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?
Provides explicit requirements for what each company must provide (name, domain, fqdn, or companyId) and a unique id field. Does not explicitly state when not to use or list alternatives, but the context of sibling tools implies use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states 'No credits charged' (positive behavioral trait) but omits read-only status, rate limits, or idempotency. The read-only nature is implied but not explicit, leaving some gaps for AI agents evaluating safety.
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?
Description is concise with clear front-loading: first sentence states purpose, then bullet list, then usage note, then source URL. Each part contributes meaning, though the searchText mention could be clarified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, the description covers purpose and usage context. However, without an output schema, it lacks detail on the response structure (e.g., list of values, format). This leaves agents guessing the return shape, which is needed for proper invocation planning.
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?
The only parameter (filterType) is fully described in the schema (enum, default). The description adds value by listing filter types and noting that some require a searchText parameter. However, searchText is not in this tool's schema, causing potential confusion. Schema coverage is 100%, so baseline is 3; description adds marginal value but with inconsistency.
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?
Description clearly states the tool retrieves filter options for company prospecting, distinguishes from sibling tools (e.g., contactFilters) by specifying 'company prospecting', and explicitly lists filter types. The phrase 'Use to explore available filter values before building prospecting queries' further clarifies its role.
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?
Description provides clear usage context: use before building prospecting queries. It notes that some filter types require a searchText parameter (even though that param isn't in the schema, hinting at broader context). Lacks explicit 'when not to use' or alternative references, but the guidance is sufficient for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description compensates by disclosing several behavioral traits: default page size of 25 (API default is 20), page/offset index starting at 0, pagination via pages or offset, credit charges to inform users, and formatting rules (table, preview limit of 25). It does not mention rate limits or authentication but provides substantial context beyond basic functionality.
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?
The description is verbose, mixing functional purpose with behavioral instructions and multiple 'IMPORTANT' sections. It front-loads the purpose and key details but includes repetitive formatting guidelines. A more streamlined structure would improve conciseness.
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 the tool's complexity (3 params, nested objects, no output schema), the description covers pagination, default settings, filter categories, workflow integration (step 2), and output formatting expectations. It lacks details about the response structure but since no output schema exists, it compensates with credit and provider information.
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?
The input schema has 0% description coverage, so the description adds significant meaning by listing filter categories and providing semantic labels (e.g., 'technologies (tech stack used)', 'intentTopics (company intent signals)'). It explains the purpose of each filter group, though it does not detail every sub-field (like location object structure). Overall, it adds value beyond the 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 is for searching contacts using various filters in Lusha API, and explicitly identifies it as step 2 of the prospecting process. It distinguishes itself from sibling tools like contactEnrich and contactFilters by explaining its role in the workflow.
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 provides explicit workflow guidance: instructs to use contactFilters first to get required filters, and advises asking the user whether to enrich results after returning search results. It doesn't explicitly compare to other search tools like companySearch, but the context of 'contact search' and step ordering is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description compensates well. Discloses credit usage, max page size 50 (overriding schema's 100), and mentions billing.creditsCharged in response. Lacks authentication details but is sufficient for a search tool.
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?
Well-structured with sections and headers, but slightly verbose with formatting instructions. Every section adds value, though some repetition (e.g., 'use companyFilters tool' appears twice). Could be slightly more concise.
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?
No output schema, so description explains credits charged, pagination (ask for more batches), and formatting instructions. Provides enough context for the agent to use the tool effectively, though missing full response structure.
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%, baseline 3. The description adds value by listing available filter types (locations, technologies, industries, etc.) and provides search tips, clarifying that page size should be max 50 despite schema allowing 100.
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 'Search for companies using advanced filters' and explicitly says 'This tool implements company search only', distinguishing it from sibling tools like companyEnrich and contactSearch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use broader filters if 0 results, combine filters, use exclude filters, and references companyFilters tool for available filter values. Also mentions that enrichment operations should use companyEnrich, clearly indicating when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes credit charging per company, formatting (table, first 25 rows, batch requests), mentions Lusha as provider, and instructs to inform user about credits charged. No annotations exist, so description fully covers behavioral traits.
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?
Well-organized with sections and bullet points. Some redundancy in credit charging emphasis, but overall concise and actionable.
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?
Comprehensive for a tool with no output schema: covers inputs, credit cost, formatting rules, preview limits, and references API documentation. No gaps for agent invocation.
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 coverage is 100% with both parameters described. Description adds context (requestId from search response, companiesIds max 50) but largely repeats schema. Does not significantly enhance meaning beyond 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?
Clearly states it enriches company information from search results, specifies required inputs (requestId, companiesIds) and limits (max 50). Distinguishes from sibling tools like companySearch and companyFilters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly warns about credit charges and requires user consent: 'WARNING: CHARGES CREDITS - always ask user first!' and 'Use only when user requests detailed information.' Provides clear when-to-use and prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![lusha-public-api-mcp MCP server](https://glama.ai/mcp/servers/lusha-oss/lusha-public-api-mcp/badges/card.svg)](https://glama.ai/mcp/servers/lusha-oss/lusha-public-api-mcp)

Score Badge

Copy to your README.md:

[![lusha-public-api-mcp MCP server](https://glama.ai/mcp/servers/lusha-oss/lusha-public-api-mcp/badges/score.svg)](https://glama.ai/mcp/servers/lusha-oss/lusha-public-api-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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