Skip to main content
Glama

Apollo Search

apollo_search
Read-only

Search Apollo's database for people or companies.

People search is free. Organization search costs 1 Sliq credit per page when the user is on Sliq credits; free when the user has connected their own Apollo key. Use liberally for people; be deliberate for organizations.

People search returns partial names (first name + last initial) and no LinkedIn URLs. The has_email and has_phone fields are boolean indicators only — the actual email and phone number are not returned. These masked previews are NOT saved to the Output tab (no identity to key or link them by) and should not be recorded via record_search_results. To turn a preview into an actionable, saved person, call find_email with the name + company — it resolves the real person and persists them to the row store at the source. apollo_enrich is org-only and does not accept person identifiers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number (1-indexed, 25 results per page)
typeYes"people" or "organizations"
keywordsNoGeneral keyword search
locationsNoFilter by location (e.g. ["San Francisco", "New York"])
seniorityNoFilter by seniority level (people only, e.g. ["vp", "director", "c_suite", "manager", "senior"])
industriesNoFilter by industry (e.g. ["computer software", "financial services"])
job_titlesNoFilter by job titles (people only, e.g. ["VP Sales", "CTO"])
technologiesNoFilter by technologies used (organizations only, e.g. ["python", "react"])
company_namesNoFilter by specific company names (people only). Apollo's people endpoint only accepts org IDs, so each name is first resolved to an Apollo organization id via a companies-search round-trip. Pair with `company_domains` when subsidiaries may collide (e.g. "Indigo Ag" → "Indigo Ag Argentina").
revenue_rangesNoFilter by company revenue (organizations only, e.g. ["1000000,10000000"])
company_domainsNoOptional domain per `company_names` entry (positional pairing — must be the same length when set). Acts as a strict disambiguator: when set, only orgs whose `primary_domain` matches are kept; names with no domain match are returned in `unresolved_company_names` and dropped from the filter.
employee_count_rangesNoFilter by company size — "min,max" headcount bounds, e.g. ["25,200"]. Arbitrary bounds are honoured; an empty side is unbounded ("500," / ",50").

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, but the description adds substantial behavioral context: masked names, no LinkedIn URLs, boolean-only has_email/has_phone fields, no persistence to the Output tab, and a warning against using record_search_results. It also discloses credit costs and the org resolution round-trip for company_names, all beyond what annotations provide.

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

Conciseness5/5

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

The description is dense but every sentence earns its place: purpose, cost, return limitations, persistence caveats, and sibling routing. It is front-loaded with the core purpose and immediately gives actionable usage guidance without filler.

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

Completeness5/5

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

For a 12-parameter tool with no output schema, the description covers the key operational caveats: partial/masked results, boolean-only contact fields, non-persistence to Output, the find_email escape hatch, and apollo_enrich's org-only scope. Combined with the fully documented input schema, an agent has enough context to invoke the tool correctly and interpret its results.

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 100%, so the input schema already documents every parameter. The description adds context around the 'type' parameter (people vs. organizations, cost differences) and high-level result limitations, but it does not need to explain individual filter parameters. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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

Purpose5/5

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

The description states a specific action ('Search Apollo's database') with clear object types ('people or companies'), which distinguishes it from generic search tools. It also explicitly contrasts with apollo_enrich ('org-only and does not accept person identifiers') and find_email, helping disambiguate sibling tools.

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 gives explicit cost guidance for people vs. organization searches, instructs when to use liberally vs. deliberately, and names alternatives with their distinct roles: find_email for resolving masked previews into saved persons, and apollo_enrich for org-only enrichment. This is clear when-to-use and when-not-to-use guidance.

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