Deeplead
Server Details
Find local businesses, companies and decision makers with verified emails for B2B outreach.
- Status
- Healthy
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP ยท MCP 2025-11-25
- URL
TDQS
Scored across 11 tools
Each tool targets a distinct resource-action combination: businesses, contacts, credits, organizations, and persons are clearly separated, and within each resource, actions like search, enrich, find, create, list, and lookup are unambiguous. Even similar tools like persons_lookup and persons_find_email have clear distinctions in purpose and output.
All tools follow a consistent resource_verb or resource_verb_noun pattern in snake_case (e.g., businesses_search, organizations_enrich, persons_find_email). The naming is uniform, predictable, and easy to infer, with no mixed conventions or vague verbs.
With 11 tools covering five distinct resource domains, the count is well-scoped and each tool serves a clear purpose. The number is within the ideal range for a lead-generation server, providing enough functionality without unnecessary bloat.
The tool surface covers the primary workflows: searching businesses, organizations, and persons; enriching organizations; finding decision makers and contact details; managing contacts; and checking credits. Minor gaps exist (e.g., no update/delete for contacts, no direct business lookup by ID), but these are not critical for the server's core lead-generation purpose.
Available Tools
11 toolsbusinesses_searchSearch local businesses from Google Business ProfilesAInspect
Search local businesses from Google Business Profiles. 23M+ businesses with ratings, reviews, website contacts, socials and ad pixels. 30 per page. Charges 1 credit per business with an email or phone and 0.5 per business without. saveToContacts also stores them in your contacts. Send an Idempotency-Key header to make retries safe.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starting at 1; up to 30 businesses per page | |
| niches | Yes | Google categories or plain niches, e.g. ["dentist"] | |
| rating | No | Google rating band to match | |
| keyword | No | Matched against the business name and categories | |
| require | No | e.g. { "email": true, "metaAds": false }; false matches only businesses checked and found without it | |
| reviews | No | Google review-count band to match | |
| location | Yes | A city ("Austin, TX"), a US state ("Texas") or a country ("Germany") | |
| radiusMiles | No | Around a city; default 30 | |
| excludedNiches | No | Business categories or niches to exclude | |
| saveToContacts | No | Save returned businesses to your Deeplead contacts |
Output Schema
| Name | Required | Description |
|---|---|---|
| businesses | Yes | |
| chargedCredits | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses credit charges per result, the optional saveToContacts side effect, 30-per-page pagination, and the Idempotency-Key requirement for safe retries. This goes well beyond the annotations, which only mark the operation as not read-only, not open-world, and not destructive; no contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, all information-bearing: scope, data coverage, pagination, pricing, side effect, and idempotency. It is front-loaded with the core purpose and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with ten parameters, nested objects, and an output schema, the description covers the operational essentials: cost, side effects, pagination, and retry safety. The schema handles parameter semantics and output structure, so nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all ten parameters. The description adds minor semantic value by noting '30 per page' (tying to page) and that saveToContacts 'also stores them in your contacts', but it does not materially extend the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search local businesses from Google Business Profiles', naming a specific verb, resource, and data source. This clearly distinguishes it from sibling tools like organizations_search and persons_search, which target different entity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for local business search but does not explicitly state when to prefer it over alternatives or when not to use it. It never names sibling tools or exclusion conditions, so the agent must infer applicability from the title and first sentence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contacts_createSave your own contacts or organizationsAInspect
Save your own contacts or organizations. Free. Existing contacts are matched and kept, never duplicated.
| Name | Required | Description | Default |
|---|---|---|---|
| contacts | Yes | Contacts to save; each needs an email, LinkedIn URL, website or organization ID |
Output Schema
| Name | Required | Description |
|---|---|---|
| saved | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: existing contacts are matched and kept, never duplicated. This conveys idempotency/merge behavior, which readOnlyHint=false and destructiveHint=false do not express. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. It front-loads the purpose, then adds cost and behavioral details that are all relevant for tool selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema and output schema cover parameter requirements and return structure, so the description does not need to repeat those. It adequately conveys the core behavior, though it could more explicitly clarify how organizations are represented within the contacts array.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents the contacts parameter and the requirement that each contact needs an email, LinkedIn URL, website, or organization ID. The tool description itself adds no new parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Save your own contacts or organizations.' It distinguishes from list/search siblings by emphasizing 'your own,' but it does not explicitly name any alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicit: saving your own contacts or organizations. It gives context like 'Free' and the non-duplication behavior, but it does not state when to prefer this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contacts_listList your contacts in a stable order; page with nextBeforeBRead-onlyInspect
List your contacts in a stable order; page with nextBefore
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum saved contacts to return on this page | |
| before | No | The nextBefore of the previous page |
Output Schema
| Name | Required | Description |
|---|---|---|
| contacts | Yes | |
| nextBefore | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive. The description adds a meaningful behavioral guarantee: a stable order across pages, which is essential for correct cursor-based pagination. It does not mention auth or rate limits, but for a simple read-only list with an output schema, the added context is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It packs the verb, resource, stable-order guarantee, and pagination method into a compact form, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter list endpoint with complete schema descriptions, read-only annotations, and an output schema, the description covers the essential usage and pagination behavior. Return values are handled by the output schema, so the only real omission is explicit alternative routing, which is already captured in the usage_guidelines dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are already fully documented in the schema with 100% coverage: limit has default/min/max, and before is defined as 'The nextBefore of the previous page.' The description merely echoes the before behavior and adds no new parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent this is for listing contacts and explains the pagination mechanism ('page with nextBefore'), which is useful for paging through results. However, it never states when to prefer this tool over contacts_create or the search-based siblings, nor does it give any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
credits_getCurrent credit balanceCRead-onlyInspect
Current credit balance
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| credits | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral context such as snapshot semantics, units, or response specifics, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three words with no filler, but the phrase is under-specified for a definition: it is a tautological noun phrase rather than an instructive sentence. Conciseness is fine, but the structure lacks a verb or usage statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only balance lookup with an output schema and safety annotations, the description provides enough to understand what will be returned. It is not a complex workflow, so the missing verb and usage note are smaller gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there are no parameter semantics to document. The baseline of 4 applies; no compensation is needed from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No sentence or phrase explains when to call this tool or when to prefer an alternative. The only implied context is from the title/name, and the sibling tools are unrelated categories, so the description gives no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
organizations_enrichEnrich a company from its domainAInspect
Enrich a company from its domain. Returns the company's firmographics, socials and website data. Charges 0.5 credits only when the company is found. Send an Idempotency-Key header to make retries safe.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Company domain or website URL, e.g. "stripe.com" |
Output Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| organization | Yes | |
| chargedCredits | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior beyond the annotations: it charges 0.5 credits only when the company is found, and it instructs sending an Idempotency-Key header for safe retries. These are non-obvious side effects and requirements that the annotations alone do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no filler: purpose first, then return data, then billing and retry guidance. Every sentence earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema and annotations, the description covers the key operational details: what data is returned, the credit cost condition, and retry safety. Nothing essential is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage, including an example ('stripe.com'). The description adds no new parameter semantics beyond what the schema states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Enrich') with a clear resource ('a company from its domain') and specifies the type of data returned (firmographics, socials, website data). This clearly distinguishes it from sibling search-oriented tools like organizations_search or businesses_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly conveys when to use the tool: when you have a company domain and want enrichment data rather than search/find operations. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
organizations_find_decision_makerFind the decision maker of an organization with a verified emailAInspect
Find the decision maker of an organization with a verified email. Charges 2 credits only when a decision maker is found. Can take a few minutes. Send an Idempotency-Key header to make retries safe.
| Name | Required | Description | Default |
|---|---|---|---|
| organizationId | Yes | Company ID returned by organization search or enrichment |
Output Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| decisionMaker | Yes | |
| creditsCharged | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: it charges 2 credits only on success, can take several minutes, and recommends an Idempotency-Key header for safe retries. This is strong practical guidance, though it stops short of describing failure modes or the exact async response flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by three high-value operational notes. The only minor redundancy is that the first sentence mirrors the title exactly, but overall every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description covers the important non-schema details: cost, slowness, and retry safety. It does not mention polling or callback behavior for the multi-minute wait, but the provided output schema and simple parameter surface make this reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single parameter organizationId is already fully documented as a company ID from search or enrichment. The tool description adds no additional parameter-level meaning, which is acceptable given the schema already carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: find an organization's decision maker with a verified email. It is specific enough to separate the tool from sibling search/enrichment tools, though it does not explicitly name those alternatives or define what counts as a decision maker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus siblings like organizations_enrich, persons_find_email, or organizations_search. The operational caveats about credits and latency are helpful, but no when/when-not conditions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
organizations_searchSearch organizations, or look them up by domainAInspect
Search organizations, or look them up by domain. Charges 0.5 credits per returned organization. limit 0 returns only totalCount, free. Send an Idempotency-Key header to make retries safe.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum companies to return; 0 returns only a free count | |
| query | No | Free text matched against company name, description and keywords | |
| hqCity | No | City names of the headquarters, e.g. ["Austin"] | |
| offset | No | Number of matching companies to skip for pagination | |
| domains | No | Look companies up by domain, e.g. ["stripe.com"] | |
| hqState | No | US state names or codes of the headquarters | |
| semantic | No | What the company is and sells, matched by meaning, e.g. "outsourced medical billing for clinics" | |
| hqCountry | No | ISO alpha-2 country codes of the headquarters, e.g. ["US", "DE"] | |
| fundedAfter | No | Year of the last funding round, at least; known for about 1 in 100 US companies | |
| foundedAfter | No | Earliest founding year to include | |
| revenueRange | No | Annual company revenue bands | |
| technologies | No | Technologies used by the company | |
| employeeBands | No | Headcount bands | |
| foundedBefore | No | Latest founding year to include | |
| monthlyVisitsMin | No | Minimum monthly website visits; known for about 1 in 8 US companies, the rest are excluded | |
| employeeGrowthMin | No | Minimum employee growth on LinkedIn in percent, e.g. 10; known for about 1 in 13 US companies | |
| industryNaicsDirect | No | NAICS codes | |
| includeWithoutWebsite | No | Include companies without websites in search results |
Output Schema
| Name | Required | Description |
|---|---|---|
| totalCount | Yes | |
| organizations | Yes | |
| chargedCredits | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: '0.5 credits per returned organization', 'limit 0 returns only totalCount, free', and the Idempotency-Key retry guidance. These are useful operational details that the annotations do not provide, and nothing in the description contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: purpose, cost behavior, and retry safety. The most important operational constraint (credit cost) is front-loaded immediately after the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 18 parameters, the schema documents all of them and an output schema exists, so the description only needs to cover cross-cutting concerns. It covers cost, the free count mode, and retry safety, making it complete enough for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the description does not need to re-document parameters. It adds only a cost-related note tied to the limit parameter, which is helpful but does not materially expand on the schema's already rich parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the resource ('organizations') and the primary verb ('Search'), and adds a second distinct mode ('look them up by domain'). It is specific enough for an agent to understand what the tool does, though it does not explicitly differentiate itself from siblings like organizations_enrich or businesses_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('Search organizations, or look them up by domain') and gives context for the domain-lookup path. However, it does not name alternative tools or state when to choose one sibling over another, so the guidance is clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
persons_find_emailFind a person's work email by LinkedIn URL, or full name and company domainAInspect
Find a person's work email by LinkedIn URL, or full name and company domain. Charges 1 credit only when an email is found. Send an Idempotency-Key header to make retries safe.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Full name, e.g. "Jane Doe"; needs domain | |
| domain | No | Company domain, e.g. "acme.com" | |
| No | e.g. "https://www.linkedin.com/in/jane-doe" |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| Yes | ||
| found | Yes | |
| jobTitle | Yes | |
| Yes | ||
| companyName | Yes | |
| chargedCredits | Yes | |
| companyWebsite | Yes | |
| alternateEmails | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two important behavioral traits not captured by annotations: credit is charged only when an email is found, and an Idempotency-Key header is recommended for safe retries. This meaningfully adds context beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The core purpose comes first, followed by billing behavior and a retry-safety instruction. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers how to invoke the tool, the alternate input modes, the cost model, and retry guidance. With an output schema available, no critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the parameter relationship: LinkedIn can be used alone, while name requires domain. This combination logic is not fully explicit in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'a person's work email', and specifies the two lookup strategies: LinkedIn URL or full name plus company domain. This is specific enough to distinguish from siblings like persons_find_phone and persons_lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear conditions for use: supply either a LinkedIn URL or a name plus domain. It does not explicitly discuss when not to use it or name alternative tools, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
persons_find_phoneFind a person's phone number by LinkedIn URL, email, or full name and company domainAInspect
Find a person's phone number by LinkedIn URL, email, or full name and company domain. Charges 2 credits only when a phone number is found. Send an Idempotency-Key header to make retries safe.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Full name, e.g. "Jane Doe"; needs domain | |
| No | Known email address identifying the person | ||
| domain | No | Company domain, e.g. "acme.com" | |
| No | e.g. "https://www.linkedin.com/in/jane-doe" |
Output Schema
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| found | Yes | |
| phone | Yes | |
| phones | Yes | |
| jobTitle | Yes | |
| Yes | ||
| companyName | Yes | |
| chargedCredits | Yes | |
| companyWebsite | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the minimal boolean annotations, the description discloses a real behavioral trait: it charges 2 credits only when a phone number is found. It also instructs callers to send an Idempotency-Key header for safe retries. It does not mention auth or rate limits, but the material side effects are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core purpose and accepted inputs are front-loaded, and the cost and idempotency guidance each earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high schema coverage and presence of an output schema, the description covers the main decisions an agent faces: which inputs are valid and what side effects to expect. It could be slightly stronger by explicitly saying to use persons_find_email when only an email address is needed, but it is otherwise complete for a lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes each parameter well, so the baseline is 3. The description adds value by clarifying the accepted identifier alternatives and the dependency between 'name' and 'company domain' via the phrase 'full name and company domain.' This helps an agent understand valid combinations beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Find'), a concrete resource ('a person's phone number'), and the exact input routes (LinkedIn URL, email, or full name plus company domain). This clearly distinguishes the tool from siblings like persons_find_email and persons_lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when you need a phone number and have one of the listed identifiers. It does not explicitly name alternative sibling tools or state when not to use it, but the identifier-based usage is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
persons_lookupLook up one person by LinkedIn URL, email, or name and company domainAInspect
Look up one person by LinkedIn URL, email, or name and company domain. Returns the person with their emails, phones, role and company. Charges 1 credit only when the person is found with an email or phone. saveToContacts also stores them in your contacts. Send an Idempotency-Key header to make retries safe.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Full name, e.g. "Jane Doe"; needs domain | |
| No | Known email address identifying the person | ||
| domain | No | Company domain, e.g. "acme.com" | |
| No | e.g. "https://www.linkedin.com/in/jane-doe" | ||
| saveToContacts | No | Save the returned person to your Deeplead contacts |
Output Schema
| Name | Required | Description |
|---|---|---|
| found | Yes | |
| person | Yes | |
| chargedCredits | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds important behavioral details beyond the annotations: the credit is charged only when a person is found with email or phone, saveToContacts has a storage side effect, and sending an Idempotency-Key makes retries safe. This gives the agent an accurate cost and safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences deliver the purpose, lookup modes, return content, billing behavior, side effect, and retry guidance without any redundant phrasing. The most important operational constraint, the credit charge, is front-loaded after the purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a single-person lookup tool: it covers accepted inputs, output highlights, billing, side effects, and retry safety. Because an output schema exists, the return details do not need to be spelled out. The only implicit requirement, that at least one identifier must be supplied, is strongly implied by 'by LinkedIn URL, email, or name and company domain.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds meaning beyond the schema by clarifying that saveToContacts stores the person in contacts and by tying the charge to a successful person-with-contact-info result, which helps the agent reason about cost and side effects for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Look up'), a single resource ('one person'), and the three accepted identifier modes ('LinkedIn URL, email, or name and company domain'). This clearly differentiates it from the sibling search tools, which imply multiple results, and from persons_find_email/persons_find_phone, which target a single contact channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use this tool when you need one person and have a known identifier such as LinkedIn URL, email, or name plus company domain. It does not explicitly name alternatives or exclusion conditions such as 'use persons_search for broad lookups,' so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
persons_searchSearch persons with their emails and phonesAInspect
Search persons with their emails and phones. Returns only people with an email or phone, with full contact data, and charges 1 credit per returned person. Page with nextOffset. limit 0 returns only totalCount, free. saveToContacts also stores them in your contacts, where people you already had are refunded. Send an Idempotency-Key header to make retries safe.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum people to return; 0 returns only a free count | |
| query | No | Free text matched against company name, description and keywords | |
| offset | No | Pagination offset; use nextOffset from the previous response | |
| domains | No | Look companies up by domain, e.g. ["stripe.com"] | |
| hqState | No | US state names or codes of the headquarters | |
| jobLevel | No | Allowed job seniority levels | |
| jobTitle | No | Matched as partial text, so "CEO" also finds "Assistant to the CEO"; combine with jobLevel to narrow | |
| semantic | No | What the company is and sells, matched by meaning, e.g. "outsourced medical billing for clinics" | |
| hqCountry | No | ISO alpha-2 country codes of the headquarters, e.g. ["US", "DE"] | |
| inCountry | No | ISO alpha-2 country codes where the person is based | |
| personCity | No | Cities where the person is based | |
| fundedAfter | No | Year of the last funding round, at least; known for about 1 in 100 US companies | |
| personState | No | States where the person is based | |
| foundedAfter | No | Earliest founding year to include | |
| revenueRange | No | Annual company revenue bands | |
| technologies | No | Technologies used by the company | |
| employeeBands | No | Headcount bands | |
| foundedBefore | No | Latest founding year to include | |
| saveToContacts | No | Save returned people to your Deeplead contacts | |
| jobTitleExclude | No | Job title phrases to exclude | |
| organizationIds | No | Limit to organizations from /organizations/search | |
| monthlyVisitsMin | No | Minimum monthly website visits; known for about 1 in 8 US companies, the rest are excluded | |
| employeeGrowthMin | No | Minimum employee growth on LinkedIn in percent, e.g. 10; known for about 1 in 13 US companies | |
| decisionMakersOnly | No | C-level, VP or director seniority, or a founder, owner, CEO, managing director or president title | |
| onePerOrganization | No | Return at most one person per company | |
| industryNaicsDirect | No | NAICS codes |
Output Schema
| Name | Required | Description |
|---|---|---|
| persons | Yes | |
| nextOffset | Yes | |
| totalCount | Yes | With limit 0: all matching people, including those without an email or phone |
| chargedCredits | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description openly discloses billing behavior ('charges 1 credit per returned person'), filtering ('Returns only people with an email or phone'), pagination ('Page with nextOffset'), a free count mode, the side effect of saveToContacts including refunds for existing contacts, and idempotency guidance. These are meaningful behavioral details that go well beyond the readOnlyHint/openWorldHint/destructiveHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: the core purpose is front-loaded, and every subsequent sentence contributes a distinct operational fact (contact filtering, cost, pagination, free count, contacts side effect, idempotency). For a tool with 26 parameters, this is appropriately sized and avoids restating schema text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the fact that the input schema and output schema are rich, the description covers the non-obvious aspects an agent needs: cost, free count, pagination, contact-saving side effects, and safe retries. It is slightly incomplete only in not helping an agent distinguish this from sibling search/lookup tools by naming alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds useful parameter-specific meaning: it clarifies that limit=0 'returns only totalCount, free' and that saveToContacts 'stores them in your contacts, where people you already had are refunded.' It doesn't re-document all params, which is appropriate since the schema already handles them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and object: 'Search persons with their emails and phones,' and further narrows the scope by saying it returns only people with an email or phone. Although it doesn't explicitly contrast sibling tools like persons_lookup or persons_find_email, the verb 'search' plus the contact-data qualifier makes the intended resource clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operating context: use this when you need people with contact data along with full contact information, and it explains when limit=0 is appropriate ('returns only totalCount, free') plus when to send an Idempotency-Key ('to make retries safe'). It does not explicitly name alternative tools or state when not to use it, so it misses the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
14 tool updates
- Changed
businesses_search6 fields changed- added
Input schema / properties / excludedNiches / descriptionAdded value: +"Business categories or niches to exclude" - added
Input schema / properties / page / descriptionAdded value: +"Page number, starting at 1; up to 30 businesses per page" - added
Input schema / properties / rating / descriptionAdded value: +"Google rating band to match" - added
Input schema / properties / reviews / descriptionAdded value: +"Google review-count band to match" - added
Input schema / properties / saveToContactsAdded value: +{ + "default": false, + "description": "Save returned businesses to your Deeplead contacts", + "type": "boolean" +} - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "businesses": { + "items": { + "additionalProperties": false, + "properties": { + "adPixels": { + "additionalProperties": false, + "properties": { + "chatgpt": { + "type": [ + "boolean", + "null" + ] + }, + "googleAds": { + "type": [ + "boolean", + "null" + ] + }, + "googleAnalytics": { + "type": [ + "boolean", + "null" + ] + }, + "meta": { + "type": [ + "boolean", + "null" + ] + }, + "tiktok": { + "type": [ + "boolean", + "null" + ] + } + }, + "required": [ + "meta", + "googleAds", + "googleAnalytics", + "tiktok", + "chatgpt" + ], + "type": "object" + }, + "address": { + "type": [ + "string", + "null" + ] + }, + "businessId": { + "type": "string" + }, + "categories": { + "items": { + "type": "string" + }, + "type": "array" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": [ + "string", + "null" + ] + }, + "email": { + "type": [ + "string", + "null" + ] + }, + "emails": { + "items": { + "type": "string" + }, + "type": "array" + }, + "googleProfileClaimed": { + "type": [ + "boolean", + "null" + ] + }, + "name": { + "type": "string" + }, + "phone": { + "type": [ + "string", + "null" + ] + }, + "phones": { + "items": { + "type": "string" + }, + "type": "array" + }, + "rating": { + "type": [ + "number", + "null" + ] + }, + "reviewCount": { + "type": [ + "number", + "null" + ] + }, + "reviewsByStars": { + "description": "Counts of 1 to 5 star reviews", + "items": { + "type": [ + "number", + "null" + ] + }, + "type": "array" + }, + "socials": { + "additionalProperties": false, + "properties": { + "facebook": { + "type": [ + "string", + "null" + ] + }, + "instagram": { + "type": [ + "string", + "null" + ] + }, + "linkedin": { + "type": [ + "string", + "null" + ] + }, + "tiktok": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "facebook", + "instagram", + "linkedin", + "tiktok" + ], + "type": "object" + }, + "website": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "businessId", + "name", + "categories", + "address", + "city", + "country", + "website", + "email", + "emails", + "phone", + "phones", + "rating", + "reviewCount", + "reviewsByStars", + "googleProfileClaimed", + "socials", + "adPixels" + ], + "type": "object" + }, + "type": "array" + }, + "chargedCredits": { + "type": "number" + } + }, + "required": [ + "chargedCredits", + "businesses" + ], + "type": "object" +}
- Changed
contacts_create2 fields changed- added
Input schema / properties / contacts / descriptionAdded value: +"Contacts to save; each needs an email, LinkedIn URL, website or organization ID" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "saved": { + "type": "number" + } + }, + "required": [ + "saved" + ], + "type": "object" +}
- Changed
contacts_list2 fields changed- added
Input schema / properties / limit / descriptionAdded value: +"Maximum saved contacts to return on this page" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "contacts": { + "items": { + "additionalProperties": false, + "properties": { + "companyName": { + "type": [ + "string", + "null" + ] + }, + "contactId": { + "type": "string" + }, + "email": { + "type": [ + "string", + "null" + ] + }, + "jobTitle": { + "type": [ + "string", + "null" + ] + }, + "linkedin": { + "type": [ + "string", + "null" + ] + }, + "name": { + "type": [ + "string", + "null" + ] + }, + "organizationId": { + "type": [ + "string", + "null" + ] + }, + "website": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "contactId", + "name", + "email", + "jobTitle", + "companyName", + "website", + "linkedin", + "organizationId" + ], + "type": "object" + }, + "type": "array" + }, + "nextBefore": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "contacts", + "nextBefore" + ], + "type": "object" +}
- Changed
credits_get1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "credits": { + "type": "number" + } + }, + "required": [ + "credits" + ], + "type": "object" +}
- Added
organizations_enrich - Added
organizations_find_decision_maker - Removed
organizations_findDecisionMaker - Changed
organizations_search10 fields changed- added
Input schema / properties / foundedAfter / descriptionAdded value: +"Earliest founding year to include" - added
Input schema / properties / foundedBefore / descriptionAdded value: +"Latest founding year to include" - added
Input schema / properties / hqCityAdded value: +{ + "description": "City names of the headquarters, e.g. [\"Austin\"]", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / includeWithoutWebsite / descriptionAdded value: +"Include companies without websites in search results" - added
Input schema / properties / limit / descriptionAdded value: +"Maximum companies to return; 0 returns only a free count" - changed
Input schema / properties / limit / minimumPrevious value: -1New value: +0 - added
Input schema / properties / offset / descriptionAdded value: +"Number of matching companies to skip for pagination" - added
Input schema / properties / revenueRange / descriptionAdded value: +"Annual company revenue bands" - added
Input schema / properties / technologies / descriptionAdded value: +"Technologies used by the company" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "chargedCredits": { + "type": "number" + }, + "organizations": { + "items": { + "additionalProperties": false, + "properties": { + "adPixels": { + "additionalProperties": false, + "description": "true/false where the website was checked, null where it never was", + "properties": { + "chatgpt": { + "type": [ + "boolean", + "null" + ] + }, + "googleAds": { + "type": [ + "boolean", + "null" + ] + }, + "googleAnalytics": { + "type": [ + "boolean", + "null" + ] + }, + "meta": { + "type": [ + "boolean", + "null" + ] + }, + "tiktok": { + "type": [ + "boolean", + "null" + ] + } + }, + "required": [ + "meta", + "googleAds", + "googleAnalytics", + "tiktok", + "chatgpt" + ], + "type": "object" + }, + "description": { + "type": [ + "string", + "null" + ] + }, + "domain": { + "type": [ + "string", + "null" + ] + }, + "emails": { + "description": "Found on the company website", + "items": { + "type": "string" + }, + "type": "array" + }, + "employeeCount": { + "type": [ + "number", + "null" + ] + }, + "employeeGrowthRate": { + "description": "Employee growth on LinkedIn in percent", + "type": [ + "number", + "null" + ] + }, + "employeeMax": { + "type": [ + "number", + "null" + ] + }, + "employeeMin": { + "type": [ + "number", + "null" + ] + }, + "foundedYear": { + "type": [ + "number", + "null" + ] + }, + "hqCity": { + "type": [ + "string", + "null" + ] + }, + "hqCountry": { + "type": [ + "string", + "null" + ] + }, + "hqState": { + "type": [ + "string", + "null" + ] + }, + "industry": { + "type": [ + "string", + "null" + ] + }, + "keywords": { + "type": [ + "string", + "null" + ] + }, + "lastFunding": { + "additionalProperties": false, + "properties": { + "amount": { + "description": "USD", + "type": [ + "number", + "null" + ] + }, + "date": { + "type": [ + "string", + "null" + ] + }, + "type": { + "description": "e.g. Seed Round, Series A, Private Equity Round", + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "type", + "date", + "amount" + ], + "type": "object" + }, + "linkedin": { + "type": [ + "string", + "null" + ] + }, + "linkedinDescription": { + "type": [ + "string", + "null" + ] + }, + "monthlyGoogleAdSpend": { + "description": "Estimated monthly Google Ads spend in USD", + "type": [ + "number", + "null" + ] + }, + "monthlyVisits": { + "description": "Estimated monthly website visits", + "type": [ + "number", + "null" + ] + }, + "naicsCodes": { + "items": { + "type": "string" + }, + "type": "array" + }, + "name": { + "type": [ + "string", + "null" + ] + }, + "organizationId": { + "type": "string" + }, + "phones": { + "description": "Found on the company website", + "items": { + "type": "string" + }, + "type": "array" + }, + "revenueRange": { + "type": [ + "string", + "null" + ] + }, + "socials": { + "additionalProperties": false, + "properties": { + "facebook": { + "type": [ + "string", + "null" + ] + }, + "instagram": { + "type": [ + "string", + "null" + ] + }, + "linkedin": { + "type": [ + "string", + "null" + ] + }, + "tiktok": { + "type": [ + "string", + "null" + ] + }, + "x": { + "type": [ + "string", + "null" + ] + }, + "youtube": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "facebook", + "instagram", + "linkedin", + "x", + "tiktok", + "youtube" + ], + "type": "object" + }, + "technologies": { + "type": [ + "string", + "null" + ] + }, + "totalFunding": { + "description": "USD", + "type": [ + "number", + "null" + ] + }, + "website": { + "type": [ + "string", + "null" + ] + }, + "websiteAlive": { + "type": [ + "boolean", + "null" + ] + }, + "websiteDescription": { + "type": [ + "string", + "null" + ] + }, + "websiteTitle": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "organizationId", + "name", + "domain", + "website", + "websiteAlive", + "websiteTitle", + "websiteDescription", + "linkedin", + "linkedinDescription", + "description", + "industry", + "naicsCodes", + "keywords", + "technologies", + "employeeCount", + "employeeMin", + "employeeMax", + "revenueRange", + "monthlyVisits", + "monthlyGoogleAdSpend", + "employeeGrowthRate", + "lastFunding", + "totalFunding", + "foundedYear", + "hqCity", + "hqState", + "hqCountry", + "emails", + "phones", + "socials", + "adPixels" + ], + "type": "object" + }, + "type": "array" + }, + "totalCount": { + "type": "number" + } + }, + "required": [ + "totalCount", + "chargedCredits", + "organizations" + ], + "type": "object" +}
- Added
persons_find_email - Added
persons_find_phone - Added
persons_lookup - Removed
persons_save - Changed
persons_search14 fields changed- added
Input schema / properties / foundedAfter / descriptionAdded value: +"Earliest founding year to include" - added
Input schema / properties / foundedBefore / descriptionAdded value: +"Latest founding year to include" - added
Input schema / properties / jobLevel / descriptionAdded value: +"Allowed job seniority levels" - added
Input schema / properties / jobTitleExclude / descriptionAdded value: +"Job title phrases to exclude" - added
Input schema / properties / limit / descriptionAdded value: +"Maximum people to return; 0 returns only a free count" - changed
Input schema / properties / limit / minimumPrevious value: -1New value: +0 - added
Input schema / properties / offset / descriptionAdded value: +"Pagination offset; use nextOffset from the previous response" - added
Input schema / properties / onePerOrganizationAdded value: +{ + "default": false, + "description": "Return at most one person per company", + "type": "boolean" +} - added
Input schema / properties / personCity / descriptionAdded value: +"Cities where the person is based" - added
Input schema / properties / personState / descriptionAdded value: +"States where the person is based" - added
Input schema / properties / revenueRange / descriptionAdded value: +"Annual company revenue bands" - added
Input schema / properties / saveToContactsAdded value: +{ + "default": false, + "description": "Save returned people to your Deeplead contacts", + "type": "boolean" +} - added
Input schema / properties / technologies / descriptionAdded value: +"Technologies used by the company" - changed
Output schema / (root)Previous value: -nullNew value: +{ + "$schema": "https://json-schema.org/draft/2020-12/schema", + "additionalProperties": false, + "properties": { + "chargedCredits": { + "type": "number" + }, + "nextOffset": { + "type": [ + "number", + "null" + ] + }, + "persons": { + "items": { + "additionalProperties": false, + "properties": { + "alternateEmails": { + "items": { + "type": "string" + }, + "type": "array" + }, + "city": { + "type": [ + "string", + "null" + ] + }, + "companyEmployeeGrowthRate": { + "description": "Percent", + "type": [ + "number", + "null" + ] + }, + "companyLastFundingDate": { + "type": [ + "string", + "null" + ] + }, + "companyLastFundingType": { + "type": [ + "string", + "null" + ] + }, + "companyMonthlyVisits": { + "type": [ + "number", + "null" + ] + }, + "companyName": { + "type": [ + "string", + "null" + ] + }, + "companyWebsite": { + "type": [ + "string", + "null" + ] + }, + "country": { + "type": [ + "string", + "null" + ] + }, + "email": { + "type": [ + "string", + "null" + ] + }, + "foundedYear": { + "type": [ + "number", + "null" + ] + }, + "jobFunction": { + "type": [ + "string", + "null" + ] + }, + "jobLevel": { + "type": [ + "string", + "null" + ] + }, + "jobTitle": { + "type": [ + "string", + "null" + ] + }, + "linkedin": { + "type": [ + "string", + "null" + ] + }, + "naicsCodes": { + "items": { + "type": "string" + }, + "type": "array" + }, + "name": { + "type": [ + "string", + "null" + ] + }, + "organizationId": { + "type": [ + "string", + "null" + ] + }, + "personId": { + "type": [ + "string", + "null" + ] + }, + "phone": { + "type": [ + "string", + "null" + ] + }, + "phones": { + "items": { + "type": "string" + }, + "type": "array" + }, + "revenueRange": { + "type": [ + "string", + "null" + ] + }, + "state": { + "type": [ + "string", + "null" + ] + } + }, + "required": [ + "personId", + "name", + "email", + "alternateEmails", + "phone", + "phones", + "linkedin", + "jobTitle", + "jobLevel", + "jobFunction", + "city", + "state", + "country", + "organizationId", + "companyName", + "companyWebsite", + "revenueRange", + "naicsCodes", + "foundedYear", + "companyMonthlyVisits", + "companyEmployeeGrowthRate", + "companyLastFundingType", + "companyLastFundingDate" + ], + "type": "object" + }, + "type": "array" + }, + "totalCount": { + "description": "With limit 0: all matching people, including those without an email or phone", + "type": "number" + } + }, + "required": [ + "totalCount", + "nextOffset", + "chargedCredits", + "persons" + ], + "type": "object" +}
- Removed
search_parse
9 tool updates
- First observed
businesses_search - First observed
contacts_create - First observed
contacts_list - First observed
credits_get - First observed
organizations_findDecisionMaker - First observed
organizations_search - First observed
persons_save - First observed
persons_search - First observed
search_parse
Related MCP Connectors
Find B2B decision makers and verify work emails.
Search B2B contacts, enrich verified emails and phone numbers, and export results.
Find B2B leads with verified work emails, find and verify emails, and run cold email outreach.
351Discover B2B companies by industry and location.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables finding decision makers at a company and revealing their verified work email addresses, with free search and paid contact reveal.MIT
- AlicenseNot gradedqualityFmaintenanceEnables searching 12M+ verified businesses across 10 countries and 19 directories, with tools for lead generation, competitive analysis, and market research.MIT
- AlicenseNot gradedqualityBmaintenanceFinds, filters, and verifies local-business leads on demand; every returned email carries a verification receipt (verifier, verdict, timestamp). Credit-based with per-key spend budgets; 25 free validated leads at signup.MIT
- AlicenseAqualityDmaintenanceFinds and verifies business email addresses using DNS/SMTP verification and web scraping, with no external API costs.518 npm11MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.