linkedin_aiark_search
Read-only
Search LinkedIn-sourced B2B data through AI Ark (bought data, per-credit).
Not interchangeable with linkedin_unipile_search: that one drives YOUR
connected LinkedIn session (and is rate-limited by LinkedIn); this one
queries AI Ark's index and BILLS CREDITS per returned record.
op:
"people" (default): people by company + contact filters. Results do NOT include emails — use
linkedin_aiark_person(op="export")for one."companies": companies by firmographics.
Returns the AI Ark page: content[], totalElements, totalPages.
A read timeout is retried ONCE and then raised with retryable: true — a
failure, never an empty page (⚠️ the retry can bill a second time if AI Ark
had already processed the first attempt).
Tool call template
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "linkedin_aiark_search"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| op | No | "people" (default) | "companies". | people |
| _org | No | Org (id) de CET APPEL. `oto_list_orgs()`. | |
| full | No | True = the RAW AI Ark record, every block. The DEFAULT is a sourcing view that drops what sourcing never reads — past positions with the full write-up of every company worked at, education, volunteering, awards, skills, badges, statistics, languages, image URLs, the profile `summary`, birth date, non-LinkedIn social links and the `department` sub-blocks — plus the company blocks repeated identically on all 100 people of one firm. A `size=100` page returned ~3 M characters, past any tool-result cap; measured 10/09/2026, 53 % of what the sourcing view still carried was read by nobody. | |
| page | No | zero-based page number. size: 0-100 (default 10). | |
| size | No | ||
| lists | No | exclude records already in saved lists. | |
| _group | No | Équipe (id) de CET APPEL, sous son org parente. | |
| fields | No | keep ONLY these keys on each record; the envelope (totals, pagination, trackId) always stays — without it you would think you saw everything. Combine with `full=True` to project the raw record. ⚠️ These are the REAL top-level keys. op="people", default view: `id`, `identifier`, `profile`, `link`, `location`, `industry`, `department`, `company`, `last_updated` (with `full=True`, the blocks the view removes are added). op="companies", the same block as a person's `company`, default view: `id`, `summary`, `link`, `location` (+ `industries`, `technologies`, `keywords`, `naics`, `languages`, `last_updated` with `full=True`). An unrecognized name is **silently discarded**, not refused: a projection of invented names returns records that look EMPTY, and the absence reads as "no data" instead of "wrong key" (signal 717). Omitting `company` is in fact the whole point of the projection — it is the block repeated identically on every person of the same company. | |
| _run_id | No | OBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas. | |
| account | No | filters on the company. AI Ark nested DSL — each field takes an include/exclude matcher. Examples: - name: {"name": {"any": {"include": {"mode": "SMART", "content": ["Amazon"]}}}} - location: {"location": {"any": {"include": ["United States"]}}} ⚠️ This is the **HEADQUARTERS**, not "has an office there". A company whose HQ is elsewhere returns `0` even if it employs hundreds of people in the requested country, and the failure is indistinguishable from "nobody matches". Measured on 04/09/2026: `account.location = United Kingdom` on a bank headquartered in New York → 0; `contact.location = United Kingdom` on the same → 89 people. For "who works in this country", filter on `contact.location`. - employee size: {"employeeSize": {"type": "RANGE", "range": [{"start": 1000, "end": 5000}]}} - a company's site: {"domain": {"any": {"include": ["example.com"]}}} — plain list, NOT the SMART wrapper (that one is for `name` only). Combine keys in one object. Keys MEASURED to bite on op="companies": `domain`, `employeeSize`, `location`. `industries`, `technologies`, `naics` answered 400 under the forms tried (a loud failure, but their expected shape is unknown). ⚠️ REFUSED because AI Ark accepts them and silently ignores them, returning the whole database as if it were your filtered result: `website` and `linkedin_url` (filter on `domain` instead) and, on op="companies", `keywords` — dead under every form tried (plain list, `any.include`, SMART wrapper). To target a sector, use `lookalike_domains`, or sort client-side on the records' `keywords` (`full=True`). | |
| contact | No | op="people" — filters on the person, e.g. {"seniority": {"any": {"include": ["founder"]}}}. Supports seniority and location. ⚠️ `seniority` is a **normalized level, derived from the job title** — not the title itself. In sectors where the title does not follow the hierarchy (investment banking, consulting), it massively discards the right people: measured on 04/09/2026, adding `seniority: "director"` to a query that returned 89 people brought it down to 2, the first of whom was a human resources director. A "Managing Director" does not carry `director`. Use it to reduce pagination, never as a selection criterion. ⚠️ `title` and `department` are REFUSED for the same reason: AI Ark accepts them and silently ignores them, so you get the company's first page and pay for it. Filter on `seniority`, then sort client-side — `department.departments` IS on every record returned, it just cannot be filtered on. | |
| _project | No | Projet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`. | |
| _instance | No | Instance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`. | |
| lookalike_domains | No | op="companies" — up to 5 company URLs to find similar ones. |