People search, LinkedIn lookup and verified work emails for AI agents. First search needs no login.
Scored across 14 tools
The descriptions do real work here: each email tool names the input you need (id for fetch_email, name+company for find_work_email, LinkedIn URL for find_email_from_linkedin, domain for find_company_emails) and explicitly points to the alternative. Still, there are genuine overlaps — people_search can also look up one named person, competing with find_linkedin_profile, and company_search by website competes with lookup_company by LinkedIn URL.
Most tools use verb_noun (find_people, lookup_company, verify_email, reveal_profile), but company_search and people_search invert to noun_verb, and the verb vocabulary mixes find_/lookup_/reveal_/check_/reverse_ without a clean rule distinguishing them. Readable overall, but not a predictable pattern.
14 tools is well within a healthy range for a people/email enrichment API and covers distinct credit-cost tiers. A couple of pairs (find_linkedin_profile/lookup_linkedin_profile, fetch_email/find_work_email) could arguably be collapsed into one tool with an identifier parameter.
The lifecycle is well covered: search companies and people, preview, unlock profiles, resolve emails by id/name/LinkedIn, verify deliverability, reverse-lookup, and check credits. Gaps are minor — no credit purchase/top-up, no saved-list or export management, and no standalone 'get profile by id' outside of fetch_email.
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 uses 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 declare readOnly/idempotent/openWorld, and the description adds information annotations cannot convey: searching consumes no credits, the tool works without a PeopleSearch.im account, and in that unauthenticated state it caps at 3 results per search and 10 searches per day. Those rate and auth details are exactly the behavioral context an agent needs.
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-loads the core action and result fields, then the three query modes, then the free/no-account caveats. Each sentence adds new information — no restatement of the title 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?
With no output schema, the description compensates by listing the returned attributes. Combined with the query-mode semantics and the unauthenticated result cap, an agent knows what to send, what comes back, and what limits apply.
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 single param's schema description already names the three forms, so baseline would be 3. The description goes further with worked examples ('warmly.ai', 'Warmly', 'Series B fintech companies in London with 50-200 employees') that clarify the expected string format and which form yields a single exact match.
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 company database') plus the returned fields (industry, size, location, website), and enumerates three distinct query modes with concrete examples. An agent can tell this is a broad company-discovery tool rather than the narrower lookup_company or find_company_emails siblings.
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 clear usage context: three input forms with examples and which is 'most exact' for identifying a single company. It also states cost ('no credits') and the unauthenticated fallback limits, which help an agent decide whether to call it now. It stops short of explicitly saying when to prefer lookup_company or find_company_emails instead, so not a full 5.
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.
Given a LinkedIn profile URL, return that person's professional email address, verified live, with their current role and company. Use this when you have someone's LinkedIn page and need to email them; for a name and company without a URL use find_work_email. Spends 3 credits, refunded if no email is found.
| Name | Required | Description | Default |
|---|---|---|---|
| linkedin_url | Yes | A LinkedIn profile URL, e.g. https://www.linkedin.com/in/… |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the 3-credit cost, the refund policy when no email is found, and that results are 'verified live' — critical context for a non-idempotent, open-world lookup. It also preempts output-shape questions by naming role and company alongside the email.
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 carrying purpose, routing, cost, and refund policy with zero filler; the core action leads the first sentence and the alternative follows immediately.
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 still tells the agent what comes back (email, role, company) and what happens on failure (refund). Nothing an agent needs to call it correctly or explain the cost to a user 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?
Only one required parameter at 100% schema coverage, and the schema already supplies the format and an example URL. The description reinforces that the input is a profile URL specifically but adds no syntax 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?
States a specific verb and resource ('Given a LinkedIn profile URL, return that person's professional email address') plus the returned extras (current role and company), and explicitly names the sibling it is not: find_work_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?
Gives the exact selection condition ('when you have someone's LinkedIn page and need to email them') and names the alternative with its own condition ('for a name and company without a URL use find_work_email'), leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a named person's LinkedIn profile: its URL with their current title, company and location. Give their first and last name, plus their company (name or website) and/or job title when you know them. A name only one person has is found from the name alone; when several people share it, the answer says how many and nothing is charged, so call again with their company or job title. Spends 2 credits, refunded if no confident match is found.
| Name | Required | Description | Default |
|---|---|---|---|
| job_title | No | Their job title ("Head of Sales"). Tells apart people who share a name, together with or instead of company_or_domain. | |
| last_name | Yes | The person's last name. | |
| first_name | Yes | The person's first name. | |
| company_or_domain | No | The company they work at, as its name or website (acme.com). Needed for a name several people share, together with or instead of job_title. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and openWorldHint=true, but the description goes substantially further: it discloses the 2-credit cost, the refund policy when no confident match is found, and that ambiguous-name lookups charge nothing and return only a count. These are exactly the behavioral traits an agent needs before deciding to spend 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?
Three sentences, front-loaded with purpose then input guidance then cost/fallback behavior — the order matches the agent's decision sequence. No sentence is redundant with 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?
There is no output schema, so the description must convey return shape, which it does (URL with title, company, location; a count-only response for ambiguous names). Cost, refund conditions, and the retry path are all covered, leaving nothing material an agent needs 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 baseline is 3; the description nonetheless adds decision semantics — company_or_domain and job_title are framed as disambiguators 'together with or instead of' each other, which clarifies they are alternatives rather than both-required. The one gap is that it does not clarify expected formats (full company name vs. bare domain) beyond the schema's own example.
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 ('Find a named person's LinkedIn profile') and specifies the returned payload (URL, current title, company, location). This cleanly distinguishes it from lookup_linkedin_profile (URL-keyed) and people_search, which an agent can infer from the name-plus-attributes input contract.
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 clear operational context: supply name plus company and/or job title when known, and retry with those attributes when the ambiguous-name response returns a count. It does not explicitly name sibling alternatives such as lookup_linkedin_profile, so routing to the right tool still requires inference from the tool names.
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. Set include_email to true when the user wants to contact them: each person's verified work email is looked up in the same call, 1 more credit each, refunded when none is found (lookups still running are collected free with fetch_email and the id). Without it, call fetch_email with each person's id later. WARNING for autonomous use: this can spend up to count credits in a single call (twice that with emails), 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. | |
| include_email | No | Also look up each unlocked person's verified professional email (1 more credit each, refunded if none is found). Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description discloses the credit model (1 per newly unlocked person, already-owned profiles free, +1 per email with refund when not found), the maximum possible spend, and that exceeding credits returns an error rather than overspending. This is a strong behavioral picture, though it leaves the atomicity/failure semantics if a batch partially fails unstated.
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-loads identity ("The list-building tool") then cost, then the email branch, with no filler sentences. It is dense and long, and the credit explanation is restated in both the body and the warning, costing a little tightness.
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 spending, nested-schema tool with no output schema, the description covers what comes back (name, title, company, location, LinkedIn URL, `id`, plus `broadenedBy`), how broadening is reported, and how to continue with fetch_email. Nothing an agent needs to invoke this safely 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 baseline is 3; the description earns above that by tying `count` to credit spend and framing `include_email` in terms of cost, refunds, and an alternative follow-up path with fetch_email. It adds real economic meaning to the two non-obvious parameters without contradicting the schema's own wording.
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 list-building tool. Runs a people search exactly as people_search does ... and unlocks up to `count` full profiles in ONE atomic charge" states the verb (search + unlock), the resource (people), and the distinguishing scope against the search-only sibling. An agent can tell immediately that this is search-plus-purchase rather than a preview or a single-profile reveal.
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 routing: reuse the same `filters` you checked with people_search so you pay only for people you saw; set `include_email` when the user wants to contact them; otherwise call fetch_email later with the `id`. It also names the sibling alternatives (people_search, fetch_email) and the condition that selects each, plus an autonomous-use warning to confirm large batches with the user.
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 uses no credits: use it to check that the right people come back before revealing anyone, 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?
Beyond readOnly/openWorld annotations, it discloses that results are masked previews carrying opaque tokens, that searching consumes no credits, that broadening happens in stages (broadenedRole, then dropped filters reported in broadenedBy, then ignored), and that without a connected account it caps at 3 previews and 10 searches a day. The broadening and quota behavior are exactly the facts an agent cannot infer from annotations or schema.
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 search-then-reveal workflow are front-loaded, and nearly every sentence carries operational content. It is still a single dense block with some duplication of schema field explanations, which costs it a point against a tighter structure.
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, yet the description explains the shape of results (masked name, role, industry, company size, location, token) and the metadata fields returned on broadening or ignored filters. Combined with the auth/quota notes, an agent has everything needed to call this 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 each nested filter is already documented, so much of the description's field talk is repetition (company_keywords, job_titles broadening). It still adds strategy the schema does not: a worked filters example, the rule that query degrades to a label when filters are present, and the advice to supply wording variants because values within a list are OR'd.
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) and what comes back (masked sample plus true total count). It clearly separates itself from reveal_profile and find_people by naming them as the routes to unmasked identities and batch unlocking.
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: filters vs query for discovery, first_name/last_name plus company for one named person, company_keywords for employer kinds no industry names, and reveal_profile / find_people for unlocking. It also tells the agent to search first and refine because searching costs no credits, which is a concrete when-to-use policy rather than an implication.
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. Checks the format and the domain's mail servers, then asks the mail provider about the exact mailbox, without sending anything. Returns verdict: deliverable, undeliverable, risky (a disposable address) or unknown (the mail server neither confirmed nor rejected the mailbox), with reason. Spends 1 credit for the mailbox check; a malformed address or a domain that takes no email is answered free, and an unknown is refunded.
| 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?
Annotations only declare readOnly/openWorld/non-idempotent/non-destructive; the description goes well beyond by disclosing that nothing is sent, enumerating the checks performed, and specifying the credit model including which outcomes are free and which are refunded. It also defines the four possible verdict values and the accompanying `reason`, which the annotations cannot 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?
Two sentences, both front-loaded: the first states the decision it supports, the second gives mechanics, return values and cost. No sentence is redundant with the title or the schema.
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 naming the returned fields (`verdict` with its four enumerated values, plus `reason`). It also covers the cost model, so an agent has everything needed to call it 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?
Schema description coverage is 100% and the single `email` parameter is already documented with an example, so the description adds no syntax or format guidance beyond it. Baseline 3 applies for a fully-covered 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?
States a specific verb and resource: check whether an email address exists and is deliverable, and spells out the three checks (format, domain mail servers, mailbox). Distinguishes itself from siblings like find_work_email and reverse_email_lookup, which search for or reverse-lookup addresses rather than validating one.
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 clear timing context ("before it bounces") that tells the agent when this tool is the right pick, and the credit/refund note signals a cost tradeoff to weigh. However, it never names an alternative or an explicit when-not-to-use case among the twelve siblings.
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 / include_emailAdded value: +{
+ "description": "Also look up each unlocked person's verified professional email (1 more credit each, refunded if none is found). Default false.",
+ "type": "boolean"
+}find_email_from_linkedinfind_linkedin_profile2 fields changedInput schema / properties / company_or_domain / descriptionPrevious value: -"Optional but recommended: the company name or domain they work at, to disambiguate common names."New value: +"The company they work at, as its name or website (acme.com). Needed for a name several people share, together with or instead of job_title."Input schema / properties / job_titleAdded value: +{
+ "description": "Their job title (\"Head of Sales\"). Tells apart people who share a name, together with or instead of company_or_domain.",
+ "type": "string"
+}find_people1 field changedInput schema / properties / filters / properties / company_domains / descriptionPrevious 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."New value: +"Current employers by website, e.g. [\"stripe.com\"]. Each website is searched as the company that owns it (its LinkedIn page), so a domain that also hosts other companies' pages (careers pages on workable.com, payment links on stripe.com) finds only the owner's staff. Some large companies' pages list another site (Amazon's lists aboutamazon.com): name those with company_ids."people_search1 field changedInput schema / properties / filters / properties / company_domains / descriptionPrevious 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."New value: +"Current employers by website, e.g. [\"stripe.com\"]. Each website is searched as the company that owns it (its LinkedIn page), so a domain that also hosts other companies' pages (careers pages on workable.com, payment links on stripe.com) finds only the owner's staff. Some large companies' pages list another site (Amazon's lists aboutamazon.com): name those with company_ids."find_people1 field changedInput schema / properties / filters / properties / companies / descriptionPrevious value: -"Current employers by name, e.g. [\"Stripe\"]."New value: +"Current employers by name, e.g. [\"Stripe\"]. A name written with a legal form or a listing's tagline (\"Stripe, Inc.\", \"Acme Pvt Ltd - Software House\") is searched without it; for an exact company use company_domains or company_ids."people_search1 field changedInput schema / properties / filters / properties / companies / descriptionPrevious value: -"Current employers by name, e.g. [\"Stripe\"]."New value: +"Current employers by name, e.g. [\"Stripe\"]. A name written with a legal form or a listing's tagline (\"Stripe, Inc.\", \"Acme Pvt Ltd - Software House\") is searched without it; for an exact company use company_domains or company_ids."find_people2 fields changedInput schema / properties / filters / properties / exclude_companiesAdded value: +{
+ "description": "Current employers to leave out, by name, e.g. [\"Stripe\"]. Needs another field to search by: with past_companies [\"Stripe\"] it finds former Stripe employees who no longer work there (11,810 of the 14,616 with Stripe in their past, measured 2026-10-19).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / filters / properties / past_companies / descriptionPrevious value: -"Former employers by name, e.g. [\"McKinsey\"] for ex-McKinsey people."New value: +"Former employers by name, e.g. [\"McKinsey\"] for ex-McKinsey people. Some people with a company in their past work there again or still: add the same names to exclude_companies for people who have left (\"former employees of Stripe\")."people_search2 fields changedInput schema / properties / filters / properties / exclude_companiesAdded value: +{
+ "description": "Current employers to leave out, by name, e.g. [\"Stripe\"]. Needs another field to search by: with past_companies [\"Stripe\"] it finds former Stripe employees who no longer work there (11,810 of the 14,616 with Stripe in their past, measured 2026-10-19).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / filters / properties / past_companies / descriptionPrevious value: -"Former employers by name, e.g. [\"McKinsey\"] for ex-McKinsey people."New value: +"Former employers by name, e.g. [\"McKinsey\"] for ex-McKinsey people. Some people with a company in their past work there again or still: add the same names to exclude_companies for people who have left (\"former employees of Stripe\")."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_emailB2B contact data for AI agents: search 700M+ people, reveal work emails. Pay per record.
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.
