Sliq

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 each person's first name plus a masked last name, 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 result's name and apollo_id — it resolves the real person and saves them to the user's people (what query_people reads), with the email it found when they had none. It doesn't add them to an agent's list: when they belong on one, record them with record_search_results, keyed by the linkedin_url find_email returns (its email when there is none).

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	Page number (1-indexed, 25 results per page)
`type`	Yes	"people" or "organizations"
`keywords`	No	General keyword search
`locations`	No	Filter by location (e.g. ["San Francisco", "New York"])
`seniority`	No	Filter by seniority level (people only, e.g. ["vp", "director", "c_suite", "manager", "senior"])
`industries`	No	Filter by industry (e.g. ["computer software", "financial services"])
`job_titles`	No	Filter by job titles (people only, e.g. ["VP Sales", "CTO"])
`on_behalf_of`	No	An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.
`technologies`	No	Filter by technologies used (organizations only, e.g. ["python", "react"])
`company_names`	No	Filter 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_ranges`	No	Filter by company revenue (organizations only, e.g. ["1000000,10000000"])
`company_domains`	No	Optional 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_ranges`	No	Filter 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.

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / on_behalf_of

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
+}

First observedSep 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only cover readOnlyHint=true; the description adds the behavior that actually matters: per-page credit cost, key-dependent cost waiver, masking of last names and LinkedIn URLs, boolean-only has_email/has_phone, and the fact that previews are not persisted to the Output tab. That is exactly the context annotations cannot carry.

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

Conciseness4/5

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

Front-loaded with what it searches and the cost rule, then the masking caveat and the handoff to find_email. Dense and mostly waste-free, though the find_email paragraph is long enough that the key instruction ('call find_email with the result's name and apollo_id') is buried mid-sentence.

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?

With 13 params, no output schema, and a single readOnly hint, the description covers what the structured data cannot: cost, return shape, masking, non-persistence, and the follow-up path to save a real person. Nothing an agent needs to call this correctly or interpret the result is missing.

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% and the filter semantics (seniority/job_titles people-only, technologies/revenue_ranges org-only, company_domains positional pairing) live in the schema. The description adds only type-level semantics and cost, which is the baseline expectation when the schema already 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?

The description states a specific verb and resource ('Search Apollo's database for people or companies') and immediately splits the two modes with their own semantics. It also names the downstream sibling (find_email) and the list sibling (query_people), so an agent can place it in the workflow 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.

Usage Guidelines5/5

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

It gives explicit usage policy — 'Use liberally for people; be deliberate for organizations' — with the cost model that justifies the asymmetry, and it tells the agent when to escalate a preview into an actionable person via find_email rather than re-searching. Alternatives and exclusions are stated, not implied.

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

All Sliq tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?