Skip to main content
Glama

AIsa Go-To-Market

People API Search

post_apollo_mixed_people_api_search
Read-onlyIdempotent

Find people matching criteria rather than enriching someone you already identified. Filter by job title, seniority, location, company domain, headcount and industry, and page with page and per_page. Returns total_entries and a people array. Note what search deliberately withholds: entries carry last_name_obfuscated and boolean flags — has_email, has_direct_phone, has_city, has_state, has_country — instead of the values themselves. Search tells you a match exists; enrichment reveals the contact details. Feed the ids into post_apollo_people_match or post_apollo_people_bulk_match to get emails and phone numbers, which is also where the credits are spent.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoThe page number of the Apollo data that you want to retrieve. Use this parameter in combination with the per_page parameter to make search results for navigable and improve the performance of the endpoint. Example: 4
per_pageNoThe number of search results that should be returned for each page. Limiting the number of results per page improves the endpoint's performance. Use the page parameter to search the different pages of data. Example: 10
q_keywordsNoA string of words over which we want to filter the results.
person_titlesNoJob titles held by the people you want to find. For a person to be included in search results, they only need to match 1 of the job titles you add. Adding more job titles expands your search results. Results also include job titles with the same terms, even if they are not exact matches. For example, searching for marketing manager might return people with the job title content marketing manager. Use this parameter in combination with the person_seniorities[] parameter to find people based on specific job functions and seniority levels. Examples: sales development representative; marketing manager; research analyst
revenue_rangeNo
organization_idsNoThe Apollo IDs for the companies (employers) you want to include in your search results. Each company in the Apollo database is assigned a unique ID. To find IDs, call the Organization Search endpoint and identify the values for organization_id. Example: 5e66b6381e05b4008c8331b8
person_locationsNoThe location where people live. You can search across cities, US states, and countries. To find people based on the headquarters locations of their current employer, use the organization_locations parameter. Examples: california; ireland; chicago
person_senioritiesNoThe job seniority that people hold within their current employer. This enables you to find people that currently hold positions at certain reporting levels, such as Director level or senior IC level. For a person to be included in search results, they only need to match 1 of the seniorities you add. Adding more seniorities expands your search results. Searches only return results based on their current job title, so searching for Director-level employees only returns people that currently hold a Director-level title. If someone was previously a Director, but is currently a VP, they would not be included in your search results. Use this parameter in combination with the person_titles[] parameter to find people based on specific job functions and seniority levels. The following options can be used for this parameter: owner founder c_suite partner vp head director manager senior entry intern
contact_email_statusNoThe email statuses for the people you want to find. You can add multiple statuses to expand your search. The statuses you can search include: verified unverified likely to engage unavailable
include_similar_titlesNoThis parameter determines whether people with job titles similar to the titles you define in the person_titles[] parameter are returned in the response. Set this parameter to false when using person_titles[] to return only strict matches for job titles.
organization_locationsNoThe location of the company headquarters for a person's current employer. You can search across cities, US states, and countries. If a company has several office locations, results are still based on the headquarters location. For example, if you search chicago but a company's HQ location is in boston, people that work for the Boston-based company will not appear in your results, even if they match other parameters. To find people based on their personal location, use the person_locations parameter. Examples: texas; tokyo; spain
q_organization_job_titlesNoThe job titles that are listed in active job postings at the person's current employer. Examples: sales manager; research analyst
organization_job_locationsNoThe locations of the jobs being actively recruited by the person's employer. Examples: atlanta; japan
organization_num_jobs_rangeNo
q_organization_domains_listNoThe domain name for the person's employer. This can be the current employer or a previous employer. Do not include www., the @ symbol, or similar. This parameter accepts up to 1,000 domains in a single request. Examples: apollo.io; microsoft.com
organization_job_posted_at_rangeNo
organization_num_employees_rangesNoThe number range of employees working for the person's current company. This enables you to find people based on the headcount of their employer. You can add multiple ranges to expand your search results. Each range you add needs to be a string, with the upper and lower numbers of the range separated only by a comma. Examples: 1,10; 250,500; 10000,20000
currently_using_all_of_technology_uidsNoFind people based on all of the technologies their current employer uses. Apollo supports filtering by 1,500+ technologies. Apollo calculates technologies data from multiple sources. This data is updated regularly. Check out the full list of supported technologies by downloading this CSV file . Use underscores (_) to replace spaces and periods for the technologies listed in the CSV file. Examples: salesforce; google_analytics; wordpress_org
currently_using_any_of_technology_uidsNoFind people based on any of the technologies their current employer uses. Apollo supports filtering by 1,500+ technologies. Apollo calculates technologies data from multiple sources. This data is updated regularly. Check out the full list of supported technologies by downloading this CSV file . Use underscores (_) to replace spaces and periods for the technologies listed in the CSV file. Examples: salesforce; google_analytics; wordpress_org
currently_not_using_any_of_technology_uidsNoExclude people from your search based on any of the technologies their current employer uses. Apollo supports filtering by 1,500+ technologies. Apollo calculates technologies data from multiple sources. This data is updated regularly. Check out the full list of supported technologies by downloading this CSV file . Use underscores (_) to replace spaces and periods for the technologies listed in the CSV file. Examples: salesforce; google_analytics; wordpress_org

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Despite annotations already declaring readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, the description adds non-obvious behavioral context: entries return 'last_name_obfuscated' and boolean flags ('has_email', 'has_direct_phone', etc.) instead of actual values, and 'Search tells you a match exists; enrichment reveals the contact details.' This shapes agent expectations about response content and cost in a way the annotations do not.

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

Conciseness5/5

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

Five sentences with no filler: purpose first, then filter categories, return shape, deliberate withholding, and routing to enrichment. Every sentence earns its place and the most important distinction (search vs. enrichment) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is strong overall, covering purpose, filtering, return structure, obfuscation behavior, and downstream tool usage. Minor deduction: it mentions 'industry' as a filterable dimension, but the input schema contains no explicit industry parameter, which could briefly mislead an agent looking for that parameter in the schema.

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

Parameters3/5

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

Schema description coverage is high at 85%, so the input schema already provides detailed semantics for page, per_page, person_titles, person_seniorities, and the rest. The description only summarily lists filter categories and mentions pagination, adding little beyond what the schema says. This matches the baseline of 3 when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description opens with 'Find people matching criteria rather than enriching someone you already identified,' using a specific verb and resource that separates it from the people_match and bulk_match siblings. It lists concrete filter dimensions (title, seniority, location, domain, headcount) and explicitly names the sibling tools for enrichment, so the agent can distinguish this search tool without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use this tool ('Find people matching criteria') and when not to ('rather than enriching someone you already identified'). It goes further by routing to alternatives: 'Feed the ids into post_apollo_people_match or post_apollo_people_bulk_match to get emails and phone numbers,' and clarifies that credits are spent at enrichment, not search.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources