People search, LinkedIn lookup and verified work emails for AI agents. First search needs no login.
Scored across 13 tools
Most tools have clearly distinct purposes, but there are a few genuinely confusable pairs: find_work_email vs fetch_email (both retrieve a work email, differing only by input type) and find_linkedin_profile (name to URL) vs lookup_linkedin_profile (URL to data). The detailed descriptions explicitly call out these boundaries, which keeps ambiguity low.
The dominant pattern is verb_noun (check_credits, fetch_email, find_people, verify_email), which is applied consistently across most tools. Two outliers use noun_verb (company_search, people_search), a minor deviation that is still readable.
13 tools is well within a healthy range for a people/company enrichment API and each tool earns its place. Search, unlock, email retrieval, verification, reverse lookup, company data and credit checks are all distinct capabilities.
The surface covers the full lifecycle: free discovery (people_search, company_search), single and batch unlock (reveal_profile, find_people), email retrieval and verification (fetch_email, find_work_email, verify_email), reverse lookup, company lookups, and credit management. No obvious dead ends for the stated domain.
Return the current credit balance for the API key making the request. Free and read-only. Use it before a large find_people call to confirm there are enough credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the description doesn't need to restate safety. It adds value by disclosing that the call is free and that the balance is tied to the requesting API key, which are behavioral facts not present in annotations. It doesn't describe the response format, but the behavior is simple enough that this is a minor gap.
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 is front-loaded, followed by cost/safety context and a practical usage tip. 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 zero-parameter, read-only tool with strong annotations, the description fully covers what the tool does, what it costs, and when to use it. No output schema exists, but the return value is self-evident from the tool name and description, so nothing critical 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?
With zero parameters and 100% schema coverage, there is nothing for the description to clarify. The baseline of 4 applies because the tool requires no parameters and the description correctly implies that no arguments are needed.
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 ('Return'), a clear resource ('current credit balance'), and the auth scope ('for the API key making the request'). This clearly distinguishes it from all sibling tools, which deal with searches, lookups, and email verification rather than account credits.
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 explicitly says when to use this tool: before a large find_people call, to confirm sufficient credits. It also names the specific sibling tool (find_people) and frames the check as a prerequisite, giving the agent concrete decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a global company database and get matching companies with industry, size, location and website. Three ways to ask: a company's website ('warmly.ai') returns that one company, the most exact way to identify one; a company's name ('Warmly') returns the companies of that name; a description in plain English ('Series B fintech companies in London with 50-200 employees') returns the companies that fit it. Searching companies is FREE and spends no credits. It also works before a PeopleSearch.im account is connected: without one it returns up to 3 companies per search, up to 10 searches a day.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A company's website, a company's name, or the companies you want described in plain English. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/openWorld/idempotent/non-destructive, and the description adds genuinely new behavior: zero credit cost, works without a PeopleSearch.im account, and hard limits of 3 companies and 10 searches/day in that unauthenticated state. It does not say whether authenticated results are capped or how pagination works, which keeps it below 5.
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?
Front-loaded with purpose and return fields, then the query modes, then cost and limits — a logical order with no filler sentences. The description is on the longer side for a single-parameter tool, but each clause (cost, limits, three modes) carries information an agent needs.
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?
No output schema exists, so the description correctly names the return fields and the result limits itself. Combined with annotations covering the safety profile, an agent has everything needed to decide to call it and interpret the response.
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% and there is only one parameter, so the baseline would be 3, but the description adds real meaning beyond the schema by giving concrete examples of each accepted query form ('warmly.ai', 'Warmly', 'Series B fintech companies in London with 50-200 employees') and the differing result cardinality of each.
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?
States a specific verb+resource ('Search a global company database') and enumerates the returned fields (industry, size, location, website). It clearly differentiates itself from lookups by describing three input modes and the fan-out behavior of each (website returns one company; name/description can return many).
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?
Gives explicit guidance on how to phrase the query and what each phrasing yields, plus a cost condition ('FREE and spends no credits') and a pre-account fallback path. It stops short of naming siblings (lookup_company, find_company_emails) that an agent might otherwise confuse it with, so it lacks explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the verified professional (work) email for a person you have already unlocked with find_people (or reveal_profile). Pass their id. Spends 1 credit, refunded automatically if no email is found. The lookup is live: if it returns emailStatus 'searching', call fetch_email again with the same id (no extra charge) to collect the result once it resolves. Returns a professional address, never a personal one; not every person has a findable work email.
| Name | Required | Description | Default |
|---|---|---|---|
| profile_id | Yes | The `id` of a person returned by find_people (or reveal_profile). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses meaningful behavior: it spends 1 credit, refunds if no email is found, can return a transient 'searching' status requiring a no-charge retry, and never returns personal addresses. This gives the agent essential operational expectations for a live lookup.
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 concise but information-dense, front-loading the core purpose and then covering credit cost, retry semantics, result type, and limitations. Every sentence contributes operational value with 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 single-parameter tool with no output schema, the description sufficiently covers input expectations, return semantics, retry behavior, and edge cases. It could be slightly more explicit about output fields beyond emailStatus, but it is complete enough for an agent to invoke and interpret the result 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 coverage is 100%, but the description adds practical meaning by clarifying the parameter is the person id from find_people or reveal_profile, and that the same id can be reused for the retry. This supplements the schema's simple description without being redundant.
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 tool looks up a verified professional work email for an already-unlocked person, with a specific resource (person id) in scope. It is distinct from sibling tools like verify_email or company search because it targets a person's work email specifically.
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 it for a person already unlocked via find_people or reveal_profile, and pass their id. It also explains the retry flow when emailStatus is 'searching'. It does not explicitly name alternatives or exclusions relative to siblings, so it stops 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.
Given a company domain or name, return the contactable role-based email addresses discovered for that organization (such as contact@, sales@, support@), each with a confidence level. Use this for reaching a company inbox, not a specific named person (for a named person use find_people or find_linkedin_profile). Spends 2 credits, refunded if none are found.
| Name | Required | Description | Default |
|---|---|---|---|
| domain_or_company | Yes | A company domain (preferred, e.g. acme.com) or company name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the credit cost and refund behavior, which is not captured in the annotations. It also clarifies the output includes confidence levels. It does not contradict the annotations, and while readOnlyHint is false, the description sufficiently explains the resource-affecting aspect via credit spend.
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 behavior, followed by usage routing and cost transparency. Every sentence earns its place with no redundancy or 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 single-parameter tool with no output schema, the description fully covers input, output content, confidence levels, use cases, exclusions, alternatives, and credit implications. Nothing essential is missing for an agent to invoke 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 schema already documents the single parameter at 100% coverage, but the description adds practical meaning: domain is preferred, company name is also accepted, and it provides an example format. This goes beyond the schema's basic 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?
The description clearly identifies the tool's function: given a company domain or name, return role-based email addresses with confidence levels. It explicitly distinguishes itself from named-person lookups by naming find_people and find_linkedin_profile, so an agent can immediately tell what this tool is for.
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 states when to use the tool ('Use this for reaching a company inbox') and when not to ('not a specific named person'), and names the exact alternative tools. It also notes the preferred input format (domain preferred), giving clear operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the LinkedIn profile URL for a named person. Provide their first and last name; adding the company or domain sharply improves the match. Spends 2 credits, refunded if no confident match is found.
| Name | Required | Description | Default |
|---|---|---|---|
| last_name | Yes | The person's last name. | |
| first_name | Yes | The person's first name. | |
| company_or_domain | No | Optional but recommended: the company name or domain they work at, to disambiguate common names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations by disclosing the credit cost and refund policy for unmatched results. No contradiction with annotations; readOnlyHint=false is consistent with spending credits.
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 tightly written sentences: purpose first, then input guidance, then cost/refund behavior. Every sentence earns its place with no repetition or 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 simple lookup tool with no output schema, the description covers inputs, expected output, and cost/refund behavior. It does not detail the exact URL format or what happens on a non-confident match, but it is sufficient for correct invocation.
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 each parameter. The description adds extra value by emphasizing that company_or_domain sharply improves match success, which helps agents decide whether to populate an optional field.
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 tool's purpose: finding the LinkedIn profile URL for a named person. It specifies a concrete verb, resource, and input requirement, but it does not explicitly differentiate itself from siblings like lookup_linkedin_profile or reveal_profile.
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 gives clear operational guidance: provide first and last name, and use company_or_domain to improve match quality. It does not explicitly state when to prefer this tool over alternative lookup tools, but the intended use case is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The list-building tool. Runs a people search exactly as people_search does (the same filters or query, including its automatic broadening, reported in broadenedBy) and unlocks up to count full profiles in ONE atomic charge: 1 credit per newly unlocked person, and anyone you already own is free. Pass the same filters you checked with people_search, so you pay for the people you saw. Returns each person's real name, title, company, location, LinkedIn URL and an id. Emails are NOT fetched here (that is a separate credit): after unlocking, call fetch_email with each person's id to get their verified work email. WARNING for autonomous use: this can spend up to count credits in a single call, so choose count deliberately and confirm with the user before large batches. Returns an out-of-credits error instead of overspending.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many people to unlock, 1-100 (default 25). Spends up to this many credits. | |
| query | No | Who you are looking for, in plain English (role, seniority, industry, company, company size, location). Parsed for you. A company's website identifies it exactly, alone or in brackets after its name ('Head of Growth at Linear (linear.app)'). Optional when `filters` is given, where it is only a label. | |
| filters | No | Exact filters, recommended for AI agents and programs: state each part of the request instead of a sentence. Values inside one list are alternatives (OR); different fields must all match (AND). Give a few variants where people word things differently (titles: ["M&A Associate", "Investment Banking Associate"]). When filters are given, `query` is only a label and is not parsed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds materially beyond them: the exact credit model (1 credit per newly unlocked person, already-owned people free, up to `count` credits in ONE atomic charge), the out-of-credits error instead of overspending, and an explicit warning telling an autonomous agent to pick `count` deliberately and confirm large batches. This is exactly the kind of cost/consequence disclosure annotations cannot carry.
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?
Front-loaded with the one-line identity of the tool, then cost model, then return values, then the credit warning. Every sentence carries information, but there is minor redundancy between the opening 'unlocks up to count... 1 credit per newly unlocked person' and the later 'spends up to count credits', and the warning could sit closer to the cost sentence.
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?
With no output schema and a complex, nested-filter, credit-spending tool, the description still covers what is returned (real name, title, company, location, LinkedIn URL, `id`), what is not returned (emails), the broadening signal (`broadenedBy`), the failure mode (out-of-credits error), and the next tool to call. An agent has everything needed to invoke 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?
Schema coverage is 100%, so the baseline is 3. The description adds meaning over the schema by tying `count` directly to spend ('choose `count` deliberately', 'spends up to count credits') and by explaining that `filters` and `query` are interchangeable in the same way as people_search, including the automatic broadening reported in `broadenedBy`. That is real added framing, though most field-level detail remains 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?
Opens with a clear positioning statement ('The list-building tool') and states a specific action pair: it searches exactly like people_search and unlocks up to `count` full profiles in one atomic charge. It distinguishes itself from the closest siblings (people_search for searching, fetch_email for emails) without the agent needing to open either schema.
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?
Explicit routing: pass the same filters you checked with people_search so you pay only for people you saw, and call fetch_email afterwards with each `id` for emails. When-not-to-use is also stated ('Emails are NOT fetched here'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find and verify the professional (work) email of a person you can name: give their first name, last name and the company they work at (its domain, such as acme.com, matches best; a company name also works). Returns the address with a confidence label (Verified or Likely) and their LinkedIn profile when it can be matched. Spends 2 credits, refunded automatically if no email is found. People who asked to be removed from PeopleSearch.im are never looked up. To find people you cannot name yet, use people_search or find_people, then fetch_email.
| Name | Required | Description | Default |
|---|---|---|---|
| last_name | Yes | The person's last name. | |
| first_name | Yes | The person's first name. | |
| company_or_domain | Yes | The company they work at: its domain (best, e.g. acme.com) or its name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover safety/idempotency hints; the description adds real operational context the annotations cannot: 2-credit cost with automatic refund when nothing is found, the PeopleSearch.im opt-out guarantee, and the Verified/Likely confidence label plus LinkedIn match in the result. This is exactly the extra behavioral detail the annotations leave out.
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, front-loaded with purpose then parameters then cost/privacy then routing. Every sentence carries information the agent needs (inputs, cost, result shape, alternative tool); nothing is padding.
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?
With no output schema, the description compensates by describing the return (email + confidence label + optional LinkedIn URL). Cost, refund behavior, privacy exclusion, and sibling routing are all covered for a 3-param open-world 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?
Schema coverage is 100% and the schema already documents all three fields, including the 'domain (best)' hint, so the description largely restates it. It adds marginal value by reiterating that a domain matches best, but no new syntax or format guidance. Baseline 3 applies when the schema carries the load.
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?
States a specific verb+resource combination ('find and verify the professional (work) email of a person') and explicitly scopes it to people the caller can already name. It also names the sibling tools (people_search, find_people, fetch_email) it is not, so an agent can route without opening a schema.
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?
Gives a clear when-to-use condition (you can name the person: first name, last name, company) and an explicit when-not path with alternatives ('To find people you cannot name yet, use people_search or find_people, then fetch_email'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a LinkedIn company URL into firmographic data: industry, size, location and website. Spends 1 credit, refunded if the company cannot be retrieved.
| Name | Required | Description | Default |
|---|---|---|---|
| linkedin_company_url | Yes | A LinkedIn company URL, e.g. https://linkedin.com/company/… |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the 1-credit cost and the refund-on-failure behavior, which is useful operational context beyond the annotations. The wording implies a non-destructive lookup-style call, and nothing contradicts the supplied 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 tight sentences: the first covers purpose and output, the second covers cost and failure behavior. No redundant phrasing or 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 one-parameter tool with no output schema, the description fully covers input, output fields, and credit/refund behavior. An agent has enough information to call it correctly and interpret the result.
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 fully documents the single required parameter with a format and example, so the description adds little beyond what the schema provides. This matches the baseline for high schema coverage.
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?
Uses a specific verb ('turn') and a clear resource ('LinkedIn company URL'), then names the exact output fields: industry, size, location, and website. The company-focused phrasing distinguishes it from profile/email siblings like lookup_linkedin_profile and fetch_email.
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 trigger condition is clear: use this when you have a LinkedIn company URL and need firmographic data. It does not explicitly compare against company_search or state when not to use it, but the intended 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.
Turn a LinkedIn profile URL into clean structured data: name, current role and company, and location. Spends 2 credits, refunded if the profile cannot be retrieved.
| Name | Required | Description | Default |
|---|---|---|---|
| linkedin_url | Yes | A LinkedIn profile URL, e.g. https://linkedin.com/in/… |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses that the tool spends 2 credits and refunds them if the profile cannot be retrieved, which is important cost-related behavior. It also communicates the return shape. Annotations already indicate readOnlyHint=false and idempotentHint=false, so the description adds meaningful context without contradicting them.
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 sentences deliver all key information: input, output, and credit cost/refund behavior. There is no filler or redundancy, and the most useful content 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 simple one-parameter tool with no output schema, the description is complete: it defines the input, the output fields, and the credit cost/refund behavior. No critical information for calling the tool 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 description coverage is 100%, so the schema already fully documents the single linkedin_url parameter. The description adds no new parameter-level syntax or constraints beyond what the schema provides, which aligns with the baseline score of 3.
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 ('Turn'), the resource ('a LinkedIn profile URL'), and the specific output fields (name, current role/company, location). It does not explicitly distinguish itself from sibling tools like find_linkedin_profile or reveal_profile, which keeps it from a 5.
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 the right usage context: use this when you already have a LinkedIn profile URL and want structured profile data. It does not state when not to use it or name alternatives, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a global professional database for people and get a sample of matches plus the true total match count. Ask with filters (recommended: state each part exactly, for example {"job_titles": ["M&A Associate", "Investment Banking Associate"], "locations": ["Frankfurt", "Munich"], "industries": ["Investment Banking"], "schools": ["University of Mannheim"]}) or with query, a plain-English sentence that is parsed for you (for example 'Heads of Marketing at Series B SaaS in New York'). Results are masked previews (a masked name, role, industry, company size and location) and each one carries an opaque token. Searching is FREE and spends no credits: use it to check that the right people come back before you pay, and refine the filters if they do not. To look up one named person, give first_name and last_name with their company or company domain when known. For a kind of employer no industry names exactly, use company_keywords (words its own description contains, for example ["hostel"] or ["SEO"] with industries ["Marketing Services"]). If nothing matches exactly, the search broadens itself: a job title is read more broadly first (broadenedRole gives the title as asked and as searched), then the least essential filters are dropped and broadenedBy names them; ignored lists any filter that could not be applied. To get a person's real name, LinkedIn and verified email, pass their token to reveal_profile, or use find_people with the same filters to unlock a batch in one call. It also works before a PeopleSearch.im account is connected: without one it returns up to 3 previews per search, up to 10 searches a day.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many masked previews to return (1-25, default 10). This does not limit the reported total. | |
| query | No | Who you are looking for, in plain English (role, seniority, industry, company, company size, location). Parsed for you. A company's website identifies it exactly, alone or in brackets after its name ('Head of Growth at Linear (linear.app)'). Optional when `filters` is given, where it is only a label. | |
| filters | No | Exact filters, recommended for AI agents and programs: state each part of the request instead of a sentence. Values inside one list are alternatives (OR); different fields must all match (AND). Give a few variants where people word things differently (titles: ["M&A Associate", "Investment Banking Associate"]). When filters are given, `query` is only a label and is not parsed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnly/idempotent/openWorld/destructive=false) by disclosing that results are masked previews carrying an opaque token, that searching spends no credits, that the search auto-broadens (broadenedRole, broadenedBy, ignored), and that without an account it returns at most 3 previews across 10 searches a day. These are exactly the operational traits an agent needs before calling.
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?
Purpose and the free-search constraint are front-loaded, which is good, but the body is a single dense paragraph mixing behavioral rules, examples and edge cases. The inline JSON and plain-English examples largely duplicate what the schema already shows, so several clauses do not fully 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?
With no output schema, the description must explain returns, and it does: masked name, role, industry, company size, location, an opaque token, and the total match count, plus the broadening/ignored reporting fields. Combined with the free/rate-limit and no-account details, an agent has everything needed to call and interpret this 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?
Schema description coverage is 100%, so the baseline is 3, but the description adds strategy-level semantics: state each filter part exactly, prefer filters over query, and treat query as a label when filters are present, plus a worked filters example. Some of this overlaps the schema's own filters description, so it is reinforcement rather than wholly new 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?
States a specific verb and resource ('Search a global professional database for people') plus the output shape (sample of matches + true total match count). It also distinguishes itself from siblings by naming reveal_profile and find_people as the paid follow-up steps, so an agent can place it in the workflow without opening other schemas.
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?
Explicit routing: search is free and should be used to validate results before paying; reveal_profile is for one person's real name/LinkedIn/email; find_people unlocks a batch with the same filters. It also covers the named-person case (first_name + last_name with company) and the no-industry-name case (company_keywords), giving when-to-use and when-to-use-something-else.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unlock ONE person from a people_search result. Pass the token from that result. Spends 1 credit and returns the full profile: real name, current title and company, location and LinkedIn URL. Set include_email to true to also look up their verified professional (work) email in the same call, which spends 1 more credit that is refunded if no email is found. Revealing the same person again is free (idempotent). The email is looked up live and may take a moment: if it returns emailStatus 'searching', call reveal_profile again with the same token (no extra charge) to collect it.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The opaque `token` of a person returned by people_search. | |
| include_email | No | Also fetch the person's verified professional email (a second credit, refunded if none is found). Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by disclosing credit costs, the refund policy for email lookups, idempotent re-reveal behavior, live email latency, and the emailStatus 'searching' retry protocol. This is rich, actionable behavioral context with no contradiction to 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?
Four sentences, front-loaded with the core purpose, and every sentence adds necessary operational detail. There is no redundant restatement of the schema or annotations.
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?
Even without an output schema, the description lists the returned profile fields, covers the optional email path, credit impact, idempotency, and retry behavior. Given the two-parameter schema and the people_search provenance, nothing critical is missing for correct invocation.
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%, but the description adds essential semantics: where the token comes from, that include_email is processed in the same call, the extra refundable credit, and how to handle the 'searching' email status. These details are not inferable from the schema alone.
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?
States a specific verb ('Unlock') and resource ('ONE person') while explicitly tying the input to a people_search result pool. This clearly distinguishes it from sibling tools like people_search, find_people, or fetch_email.
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?
Clear context is given: use it after a people_search returns a token, and set include_email when a verified email is also wanted. It does not explicitly name alternatives or say when not to use this tool, but the prerequisite is unambiguous enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a professional email address into the real person behind it and their LinkedIn profile. Best for work emails; free-mailbox addresses often have no public profile to match. Spends 13 credits (this is the single most expensive lookup), refunded automatically if no match is found.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email address to identify, e.g. jordan@acme.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral detail beyond annotations: 'Spends 13 credits (this is the single most expensive lookup), refunded automatically if no match is found.' This cost and refund behavior is valuable context not visible in the annotations, and it is consistent with idempotentHint=false and readOnlyHint=false.
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 tightly written sentences with no filler. The main purpose is front-loaded, followed by usage qualification and the cost/refund detail. 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 one-parameter tool with no output schema, the description is complete: it states what the tool returns ('real person behind it and their LinkedIn profile'), when it works, and what happens on failure (automatic refund). An agent has enough context to invoke 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 schema already covers the email parameter fully with an example. The description adds extra semantics by calling it a 'professional email address' and explaining the work-email/free-mailbox distinction, which helps the agent choose valid inputs and set expectations.
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 ('Turn') and states the resource ('professional email address') and the result ('real person behind it and their LinkedIn profile'), making the tool's purpose concrete. However, it does not explicitly distinguish itself from overlapping siblings like find_linkedin_profile or reveal_profile.
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 provides clear usage context: 'Best for work emails' and warns that 'free-mailbox addresses often have no public profile to match,' which serves as a when-to-use and when-not-to-use signal. It does not name sibling alternatives for routing, but the work-email versus free-mailbox guidance is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether an email address exists and is safe to send to, before it bounces. Returns a deliverability verdict (deliverable, undeliverable, or unknown) without sending anything. Spends 1 credit, refunded if no verdict can be reached.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email address to verify, e.g. jordan@acme.com. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description reveals important behaviors: it spends 1 credit, refunds if no verdict can be reached, and sends nothing. This adds value beyond readOnlyHint being false and clarifies side effects and cost, which are essential for an agent to use the tool correctly.
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 concise sentences, each earning its place: purpose, outcome, and side effect. It is front-loaded with the core question and avoids unnecessary 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 single-parameter tool with no output schema, the description is complete. It explains the verdict values, the credit cost, the refund behavior, and the fact that nothing is sent. An agent has enough information to decide whether and how to invoke this 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 only parameter is already fully described in the schema with a clear example. The tool description does not add extra meaning beyond what the schema provides, so the baseline score 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 states a specific verb ('Check') and resource ('whether an email address exists and is safe to send to'), and clarifies its unique role with 'before it bounces' and 'without sending anything.' This distinguishes it clearly from sibling tools like reverse_email_lookup, which do not focus on deliverability.
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 provides clear context for when to use the tool: before sending an email to avoid bounces. It does not explicitly name alternatives or exclusion criteria, but the context is strong enough for an agent to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_people1 field changedInput schema / properties / filters / properties / company_idsAdded value: +{
+ "description": "Current employers by their LinkedIn company page, the most exact way to name a company: the page's URL or its name in the URL, e.g. [\"https://www.linkedin.com/company/google\"] or [\"google\"], or LinkedIn's numeric company id. Use it for large companies, whose website often misses them (Google's page lists a short link, Amazon's lists aboutamazon.com).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}people_search1 field changedInput schema / properties / filters / properties / company_idsAdded value: +{
+ "description": "Current employers by their LinkedIn company page, the most exact way to name a company: the page's URL or its name in the URL, e.g. [\"https://www.linkedin.com/company/google\"] or [\"google\"], or LinkedIn's numeric company id. Use it for large companies, whose website often misses them (Google's page lists a short link, Amazon's lists aboutamazon.com).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}find_people1 field changedInput schema / properties / filters / properties / company_domains / descriptionPrevious value: -"Current employers by website domain, the most exact way to name a company, e.g. [\"stripe.com\"]."New value: +"Current employers by the website their LinkedIn company page lists, e.g. [\"stripe.com\"]. Exact for most companies, but some large ones list another site (Amazon's page lists aboutamazon.com, so amazon.com finds AWS staff), and a domain that hosts other organisations' pages (google.com) matches those organisations: check the company of the people returned."people_search1 field changedInput schema / properties / filters / properties / company_domains / descriptionPrevious value: -"Current employers by website domain, the most exact way to name a company, e.g. [\"stripe.com\"]."New value: +"Current employers by the website their LinkedIn company page lists, e.g. [\"stripe.com\"]. Exact for most companies, but some large ones list another site (Amazon's page lists aboutamazon.com, so amazon.com finds AWS staff), and a domain that hosts other organisations' pages (google.com) matches those organisations: check the company of the people returned."find_people1 field changedInput schema / properties / filters / properties / job_titles / descriptionPrevious value: -"Current job titles, matched as case-insensitive substrings (\"Account Executive\" also finds \"Senior Account Executive\"). Include the variants people use: [\"VP Sales\", \"Vice President of Sales\", \"Head of Sales\"]."New value: +"Current job titles, matched as case-insensitive whole words (\"Account Executive\" also finds \"Senior Account Executive\"). Each is also searched in its other spellings (\"CEO\" and \"Chief Executive Officer\", \"VP Sales\" and \"Vice President of Sales\"). A bare \"President\" or \"Owner\" means the top job: Vice Presidents and Product Owners are left out unless you list such a title too. When nobody holds the titles, the same job under other titles is searched first (the company's President or Owner for \"CEO\"), reported in broadenedRole."people_search1 field changedInput schema / properties / filters / properties / job_titles / descriptionPrevious value: -"Current job titles, matched as case-insensitive substrings (\"Account Executive\" also finds \"Senior Account Executive\"). Include the variants people use: [\"VP Sales\", \"Vice President of Sales\", \"Head of Sales\"]."New value: +"Current job titles, matched as case-insensitive whole words (\"Account Executive\" also finds \"Senior Account Executive\"). Each is also searched in its other spellings (\"CEO\" and \"Chief Executive Officer\", \"VP Sales\" and \"Vice President of Sales\"). A bare \"President\" or \"Owner\" means the top job: Vice Presidents and Product Owners are left out unless you list such a title too. When nobody holds the titles, the same job under other titles is searched first (the company's President or Owner for \"CEO\"), reported in broadenedRole."company_search1 field changedInput schema / properties / query / descriptionPrevious value: -"The companies you want, in plain English."New value: +"A company's website, a company's name, or the companies you want described in plain English."find_people1 field changedInput schema / properties / query / descriptionPrevious value: -"Who you are looking for, in plain English (role, seniority, industry, company, company size, location). Parsed for you. Optional when `filters` is given, where it is only a label."New value: +"Who you are looking for, in plain English (role, seniority, industry, company, company size, location). Parsed for you. A company's website identifies it exactly, alone or in brackets after its name ('Head of Growth at Linear (linear.app)'). Optional when `filters` is given, where it is only a label."people_search1 field changedInput schema / properties / query / descriptionPrevious value: -"Who you are looking for, in plain English (role, seniority, industry, company, company size, location). Parsed for you. Optional when `filters` is given, where it is only a label."New value: +"Who you are looking for, in plain English (role, seniority, industry, company, company size, location). Parsed for you. A company's website identifies it exactly, alone or in brackets after its name ('Head of Growth at Linear (linear.app)'). Optional when `filters` is given, where it is only a label."find_people2 fields changedInput schema / properties / filters / properties / first_nameAdded value: +{
+ "description": "To find one named person: their first name, with the variants they may use, e.g. [\"Timothy\", \"Tim\"]. Use with last_name, and add companies or company_domains when known (\"Anqi Dai at Memorial Sloan Kettering\" finds the one person).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / filters / properties / last_nameAdded value: +{
+ "description": "To find one named person: their last name, e.g. [\"Dai\"]. If the name with the employer finds nobody, the search tries the last name at the employer, then the full name anywhere.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}people_search2 fields changedInput schema / properties / filters / properties / first_nameAdded value: +{
+ "description": "To find one named person: their first name, with the variants they may use, e.g. [\"Timothy\", \"Tim\"]. Use with last_name, and add companies or company_domains when known (\"Anqi Dai at Memorial Sloan Kettering\" finds the one person).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / filters / properties / last_nameAdded value: +{
+ "description": "To find one named person: their last name, e.g. [\"Dai\"]. If the name with the employer finds nobody, the search tries the last name at the employer, then the full name anywhere.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}find_people1 field changedInput schema / properties / filters / properties / company_keywordsAdded value: +{
+ "description": "Words the current employer's own description should contain, for a KIND of employer no industry names exactly, e.g. [\"hostel\"], [\"coffee\"] (founders of coffee roasteries), [\"SEO\"] (with industries [\"Marketing Services\"] for SEO agencies), [\"community college\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}people_search1 field changedInput schema / properties / filters / properties / company_keywordsAdded value: +{
+ "description": "Words the current employer's own description should contain, for a KIND of employer no industry names exactly, e.g. [\"hostel\"], [\"coffee\"] (founders of coffee roasteries), [\"SEO\"] (with industries [\"Marketing Services\"] for SEO agencies), [\"community college\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}find_people3 fields changedInput schema / properties / filtersAdded value: +{
+ "additionalProperties": false,
+ "description": "Exact filters, recommended for AI agents and programs: state each part of the request instead of a sentence. Values inside one list are alternatives (OR); different fields must all match (AND). Give a few variants where people word things differently (titles: [\"M&A Associate\", \"Investment Banking Associate\"]). When filters are given, `query` is only a label and is not parsed.",
+ "properties": {
+ "companies": {
+ "description": "Current employers by name, e.g. [\"Stripe\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "company_domains": {
+ "description": "Current employers by website domain, the most exact way to name a company, e.g. [\"stripe.com\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "company_size_max": {
+ "description": "Maximum employees at the current employer.",
+ "minimum": 1,
+ "type": "integer"
+ },
+ "company_size_min": {
+ "description": "Minimum employees at the current employer.",
+ "minimum": 1,
+ "type": "integer"
+ },
+ "exclude_job_titles": {
+ "description": "Titles to leave out, e.g. [\"Intern\", \"Recruiter\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "industries": {
+ "description": "Industry of the current employer, as LinkedIn names it, e.g. [\"Investment Banking\"], [\"Software Development\"], [\"Hospitals and Health Care\"], [\"Venture Capital and Private Equity Principals\"], [\"Staffing and Recruiting\"]. Common older names are mapped; a name that is not an industry is reported in `ignored` and not applied.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "job_titles": {
+ "description": "Current job titles, matched as case-insensitive substrings (\"Account Executive\" also finds \"Senior Account Executive\"). Include the variants people use: [\"VP Sales\", \"Vice President of Sales\", \"Head of Sales\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "keywords": {
+ "description": "Words to find anywhere on the profile (headline, descriptions, past roles), for what no other field covers.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "languages": {
+ "description": "Languages the person speaks, e.g. [\"German\"] or [\"DE\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "locations": {
+ "description": "Where the person lives or works: cities, states, countries or regions, e.g. [\"Frankfurt\", \"Munich\"], [\"Germany\"], [\"DACH\"], [\"Texas\"]. Use \"City, Country\" to tell same-named places apart (\"Paris, France\"). Country names are safest; ISO codes are converted.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "past_companies": {
+ "description": "Former employers by name, e.g. [\"McKinsey\"] for ex-McKinsey people.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "past_job_titles": {
+ "description": "Titles the person held before their current job.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "schools": {
+ "description": "Schools the person attended, matched as substrings; add the local-language name too, e.g. [\"University of Mannheim\", \"Universität Mannheim\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "skills": {
+ "description": "Skills listed on the profile, e.g. [\"Python\", \"Kubernetes\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "years_experience_max": {
+ "description": "Maximum total years of professional experience.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "years_experience_min": {
+ "description": "Minimum total years of professional experience.",
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "type": "object"
+}Input schema / properties / query / descriptionPrevious value: -"Who you want, in plain English (same grammar as people_search)."New value: +"Who you are looking for, in plain English (role, seniority, industry, company, company size, location). Parsed for you. Optional when `filters` is given, where it is only a label."Input schema / requiredRemoved value: -[
- "query"
-]people_search3 fields changedInput schema / properties / filtersAdded value: +{
+ "additionalProperties": false,
+ "description": "Exact filters, recommended for AI agents and programs: state each part of the request instead of a sentence. Values inside one list are alternatives (OR); different fields must all match (AND). Give a few variants where people word things differently (titles: [\"M&A Associate\", \"Investment Banking Associate\"]). When filters are given, `query` is only a label and is not parsed.",
+ "properties": {
+ "companies": {
+ "description": "Current employers by name, e.g. [\"Stripe\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "company_domains": {
+ "description": "Current employers by website domain, the most exact way to name a company, e.g. [\"stripe.com\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "company_size_max": {
+ "description": "Maximum employees at the current employer.",
+ "minimum": 1,
+ "type": "integer"
+ },
+ "company_size_min": {
+ "description": "Minimum employees at the current employer.",
+ "minimum": 1,
+ "type": "integer"
+ },
+ "exclude_job_titles": {
+ "description": "Titles to leave out, e.g. [\"Intern\", \"Recruiter\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "industries": {
+ "description": "Industry of the current employer, as LinkedIn names it, e.g. [\"Investment Banking\"], [\"Software Development\"], [\"Hospitals and Health Care\"], [\"Venture Capital and Private Equity Principals\"], [\"Staffing and Recruiting\"]. Common older names are mapped; a name that is not an industry is reported in `ignored` and not applied.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "job_titles": {
+ "description": "Current job titles, matched as case-insensitive substrings (\"Account Executive\" also finds \"Senior Account Executive\"). Include the variants people use: [\"VP Sales\", \"Vice President of Sales\", \"Head of Sales\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "keywords": {
+ "description": "Words to find anywhere on the profile (headline, descriptions, past roles), for what no other field covers.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "languages": {
+ "description": "Languages the person speaks, e.g. [\"German\"] or [\"DE\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "locations": {
+ "description": "Where the person lives or works: cities, states, countries or regions, e.g. [\"Frankfurt\", \"Munich\"], [\"Germany\"], [\"DACH\"], [\"Texas\"]. Use \"City, Country\" to tell same-named places apart (\"Paris, France\"). Country names are safest; ISO codes are converted.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "past_companies": {
+ "description": "Former employers by name, e.g. [\"McKinsey\"] for ex-McKinsey people.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "past_job_titles": {
+ "description": "Titles the person held before their current job.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "schools": {
+ "description": "Schools the person attended, matched as substrings; add the local-language name too, e.g. [\"University of Mannheim\", \"Universität Mannheim\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "skills": {
+ "description": "Skills listed on the profile, e.g. [\"Python\", \"Kubernetes\"].",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "years_experience_max": {
+ "description": "Maximum total years of professional experience.",
+ "minimum": 0,
+ "type": "integer"
+ },
+ "years_experience_min": {
+ "description": "Minimum total years of professional experience.",
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "type": "object"
+}Input schema / properties / query / descriptionPrevious value: -"Who you are looking for, in plain English. Include role, seniority, industry, company stage/size, and location as needed."New value: +"Who you are looking for, in plain English (role, seniority, industry, company, company size, location). Parsed for you. Optional when `filters` is given, where it is only a label."Input schema / requiredRemoved value: -[
- "query"
-]find_work_emailcheck_creditscompany_searchfetch_emailfind_company_emailsfind_linkedin_profilefind_peoplelookup_companylookup_linkedin_profilepeople_searchreveal_profilereverse_email_lookupverify_emailEmail finder + verifier for AI agents: find work emails by name and company, check deliverability.
B2B lead and company data for AI agents: free search, pay only for emails, phones, profiles.
Search companies, enrich contacts, and reveal emails and phones from your AI agent.
B2B contact database for AI agents: search, count, export and enrich 375M+ contacts.
Add one secure layer between your agents and this server.
