Sliq

Query Agent People

query_agent_people

Read-only

Each row: id (the person id query_people uses), display_name, spine (title, company, location, headline), linkedin_url, linkedin_provider_id, email, and:

degree: the user's LinkedIn degree to the person, '1', '2', '3' or 'out_of_network'; null when unknown. A person the user is connected to reads '1'.
intro: the warm-intro check. state is one of not_checked, checking, queued, found, cold, connected, unresolved. connectors lists the user's 1st-degree connections who know the person (name, headline, identifier, provider_id). mutual_connections_truncated true means connectors is a sample of a longer list. shared_connections_count is LinkedIn's total. result_id is the search row the check read, null when the person has none.
outreach_stage: the person's lead-funnel bucket on this agent, '' when not in outreach here. prospect_id, email_stage and linkedin_stage are their prospect row on this agent, null when not enrolled. removal_reason says why they were removed from the campaign, '' when they weren't or no reason was recorded.
lists and sources: the search lists and discovery tools that surfaced the person. columns holds the researched [label, value] pairs.
verdict, verdict_reason and rejected_on: the curation recorded on the person's search rows, as the Verdict column shows it. 'rejected' when every row is rejected, 'qualified' when any row is qualified, else 'unclear' (screened but too thin to judge) when any row is, else null, with the reason from the latest row carrying it. On a group_by='list' bucket page, or under a "run" filter whose runs all saved to one list, it's the verdict on that list's row. rejected_on is {lists, reason}: the lists whose own verdict is 'rejected' while the person's verdict isn't, with the latest rejected row's reason; its lists is empty otherwise and on those two reads. A person rejected on every row is left out unless a "verdict" filter asks for 'rejected', a "run" filter is set or include_rejected is set — the same as the user's default view — though a tracked prospect always shows.
criteria, only with include_criteria: why the person matched, as their opened row shows it. Per list they're in, {list_name, evaluations}; each evaluation is a criterion with the reasoning, a verdict (satisfied 'yes', 'no' or 'unclear', or a numeric score where 7 and up is met) and http(s) references. Criteria run about 2KB per person, so ask for them on a narrow read (a q, one bucket, or a small limit) or from run_code. A list where all of the person's rows are rejected is left out unless the read includes rejected people.

To count people per group, pass group_by alone. To list one group's people, pass group_by plus a bucket key taken from those counts. Otherwise you get everyone, sorted by name. Page until next_cursor is null by passing it back as cursor. A direct call returns 25 rows by default; for a wide pull, call this from run_code with limit up to 200 (nothing truncates there) and print only the fields you need. A dict. A group_by without a bucket returns group_counts, a list of {key, count} with the largest group first and the '' group last ("degree" keeps closest-first order; "connector" entries add label), and total, the matching people each counted once. Every other call returns results (rows shaped as above) and next_cursor, plus total (every matching person) when group_by is omitted. Every call also returns filtered_out_count: how many people this same call matches once a "verdict" filter on 'rejected' is added to filters, with the same q, group_by and segment_group_id and no bucket, each person counted once. Only under the same search, filters and grouping as the user's People table does it equal the number that table shows as "didn't match".

Input Schema

TableJSON Schema

Name	Required	Description
`q`	No	A substring matched against name, title, headline and company.
`limit`	No	Rows per page (default 25, max 200).
`bucket`	No	One key from `group_counts` for the same `group_by`; returns that group's people. Needs `group_by`.
`cursor`	No	The `next_cursor` from the previous page; omit for the first page.
`filters`	No	Clauses that must all match. For "degree", "outreach_stage", "list" or "source", use {"column_key": <dimension>, "operator": "is_any_of", "values": [keys]} with keys as group_counts returns them ('' matches no value). For "segment", use the same shape with the segment keys above. For "verdict", use the same shape with any of 'rejected' (the people the user's default view filters out, labelled "Didn't match" in their table), 'qualified' and 'unclear'; it matches each person's `verdict`, or with group_by="list" their verdict on each list, and 'rejected' brings the rejected people in without `include_rejected`. For "run", use the same shape with run ids from `query_search_runs` as strings; it matches the people those search runs found, rejected ones included. When those runs all saved to one list and group_by isn't "list", a "verdict" filter reads that list alone, as on its group_by="list" bucket page. For "name", "title", "headline", "company" or "location", use {"column_key": <column>, "operator": "contains", "text": <substring>}.
`agent_id`	Yes	The agent whose People tab to read.
`group_by`	No	The dimension to count or to pick a bucket from. "degree" keys are '1', '2', '3', 'out_of_network'; "connector" keys are a connector's provider_id (else their identifier or name) and carry the connector's name as `label`; "outreach_stage" keys are funnel buckets; "list" and "source" keys are list names and discovery tools; "segment" keys are tag names in `segment_group_id`'s group, plus 'No match' for people the classifier couldn't place; "title", "company" and "location" key on the person's own value. A '' key is the group with no value (for "segment", people the group hasn't classified). A person with several lists, sources, connectors or tags counts in each.
`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.
`include_criteria`	No	Also return each row's `criteria`. Default False.
`include_rejected`	No	Also return (and count) the people left out as rejected. Default False.
`segment_group_id`	No	The segment group (from list_segment_groups or get_segment_funnel) a "segment" filter or group_by reads. With it, each row also carries `segment`, its tag names in that group.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

changedInput schema / properties / group_by / anyOf

Previous value: -[
-  {
-    "enum": [
-      "title",
-      "company",
-      "location",
-      "outreach_stage",
-      "list",
-      "source",
-      "degree",
-      "connector",
-      "segment"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "A dimension to group people by.",
+    "enum": [
+      "title",
+      "company",
+      "location",
+      "outreach_stage",
+      "list",
+      "source",
+      "degree",
+      "connector",
+      "segment"
+    ],
+    "title": "PersonGroupBy",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

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."
+}

Changed1 schema field changedOct 14, 2026

changedInput schema / properties / filters / description

Previous value: -"Clauses that must all match. For \"degree\", \"outreach_stage\", \"list\" or\n\"source\", use {\"column_key\": <dimension>, \"operator\": \"is_any_of\", \"values\": [keys]}\nwith keys as group_counts returns them ('' matches no value). For \"segment\", use the\nsame shape with the segment keys above. For \"verdict\", use the same shape with any\nof 'rejected' (the people the user's default view filters out), 'qualified' and\n'unclear'; it matches each person's `verdict`, or with group_by=\"list\" their verdict\non each list, and 'rejected' brings the rejected people in without\n`include_rejected`. For \"run\", use the same shape with run ids from\n`query_search_runs` as strings; it matches the people those search runs found,\nrejected ones included. When those runs all saved to one list and group_by isn't\n\"list\", a \"verdict\" filter reads that list alone, as on its group_by=\"list\" bucket page.\nFor \"name\", \"title\", \"headline\", \"company\" or \"location\", use\n{\"column_key\": <column>, \"operator\": \"contains\", \"text\": <substring>}."New value: +"Clauses that must all match. For \"degree\", \"outreach_stage\", \"list\" or\n\"source\", use {\"column_key\": <dimension>, \"operator\": \"is_any_of\", \"values\": [keys]}\nwith keys as group_counts returns them ('' matches no value). For \"segment\", use the\nsame shape with the segment keys above. For \"verdict\", use the same shape with any\nof 'rejected' (the people the user's default view filters out, labelled \"Didn't\nmatch\" in their table), 'qualified' and 'unclear'; it matches each person's\n`verdict`, or with group_by=\"list\" their verdict on each list, and 'rejected' brings\nthe rejected people in without\n`include_rejected`. For \"run\", use the same shape with run ids from\n`query_search_runs` as strings; it matches the people those search runs found,\nrejected ones included. When those runs all saved to one list and group_by isn't\n\"list\", a \"verdict\" filter reads that list alone, as on its group_by=\"list\" bucket page.\nFor \"name\", \"title\", \"headline\", \"company\" or \"location\", use\n{\"column_key\": <column>, \"operator\": \"contains\", \"text\": <substring>}."

Changed1 schema field changedOct 14, 2026

changedInput schema / properties / filters / description

Previous value: -"Clauses that must all match. For \"degree\", \"outreach_stage\", \"list\" or\n\"source\", use {\"column_key\": <dimension>, \"operator\": \"is_any_of\", \"values\": [keys]}\nwith keys as group_counts returns them ('' matches no value). For \"segment\", use the\nsame shape with the segment keys above. For \"verdict\", use the same shape with any\nof 'rejected' (the people the user's default view filters out), 'qualified' and\n'unclear'; it matches each person's `verdict`, or with group_by=\"list\" their verdict\non each list, and 'rejected' brings the rejected people in without\n`include_rejected`. For \"run\", use the same shape with run ids from\n`query_search_runs` as strings; it matches the people those search runs found,\nrejected ones included. For \"name\", \"title\", \"headline\", \"company\" or \"location\", use\n{\"column_key\": <column>, \"operator\": \"contains\", \"text\": <substring>}."New value: +"Clauses that must all match. For \"degree\", \"outreach_stage\", \"list\" or\n\"source\", use {\"column_key\": <dimension>, \"operator\": \"is_any_of\", \"values\": [keys]}\nwith keys as group_counts returns them ('' matches no value). For \"segment\", use the\nsame shape with the segment keys above. For \"verdict\", use the same shape with any\nof 'rejected' (the people the user's default view filters out), 'qualified' and\n'unclear'; it matches each person's `verdict`, or with group_by=\"list\" their verdict\non each list, and 'rejected' brings the rejected people in without\n`include_rejected`. For \"run\", use the same shape with run ids from\n`query_search_runs` as strings; it matches the people those search runs found,\nrejected ones included. When those runs all saved to one list and group_by isn't\n\"list\", a \"verdict\" filter reads that list alone, as on its group_by=\"list\" bucket page.\nFor \"name\", \"title\", \"headline\", \"company\" or \"location\", use\n{\"column_key\": <column>, \"operator\": \"contains\", \"text\": <substring>}."

Changed1 schema field changedOct 8, 2026

changedInput schema / properties / filters / description

Previous value: -"Clauses that must all match. For \"degree\", \"outreach_stage\", \"list\" or\n\"source\", use {\"column_key\": <dimension>, \"operator\": \"is_any_of\", \"values\": [keys]}\nwith keys as group_counts returns them ('' matches no value). For \"segment\", use the\nsame shape with the segment keys above. For \"verdict\", use the same shape with any\nof 'rejected' (the people the user's default view filters out), 'qualified' and\n'unclear'; it matches each person's `verdict`, or with group_by=\"list\" their verdict\non each list, and 'rejected' brings the rejected people in without\n`include_rejected`. For \"name\", \"title\", \"headline\", \"company\" or \"location\", use\n{\"column_key\": <column>, \"operator\": \"contains\", \"text\": <substring>}."New value: +"Clauses that must all match. For \"degree\", \"outreach_stage\", \"list\" or\n\"source\", use {\"column_key\": <dimension>, \"operator\": \"is_any_of\", \"values\": [keys]}\nwith keys as group_counts returns them ('' matches no value). For \"segment\", use the\nsame shape with the segment keys above. For \"verdict\", use the same shape with any\nof 'rejected' (the people the user's default view filters out), 'qualified' and\n'unclear'; it matches each person's `verdict`, or with group_by=\"list\" their verdict\non each list, and 'rejected' brings the rejected people in without\n`include_rejected`. For \"run\", use the same shape with run ids from\n`query_search_runs` as strings; it matches the people those search runs found,\nrejected ones included. For \"name\", \"title\", \"headline\", \"company\" or \"location\", use\n{\"column_key\": <column>, \"operator\": \"contains\", \"text\": <substring>}."

AddedOct 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With only readOnlyHint=true from annotations, the description carries the real behavioral burden and does so richly: the default view's exclusion of fully rejected people and how include_rejected/verdict/run filters override it, the ~2KB cost of include_criteria and the recommendation to narrow the read, the 25-row direct default vs 200 via run_code, and pagination until next_cursor is null. It also explains non-obvious derived semantics (filtered_out_count, rejected_on, verdict rollup rules) that an agent could not guess.

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?

Roughly a screen and a half of prose for an 11-parameter read is long, but it is front-loaded with a one-paragraph summary, then organized into per-field bullets and a separate returns block, and nearly every clause carries decision-relevant detail (degrees, intro state machine, verdict rules, pagination). It is dense rather than padded, though the row-field enumeration could be trimmed for a casual reader.

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?

No output schema exists, and the description fully compensates with a <returns> section covering group_counts shape and ordering, results/next_cursor/total, and the subtle filtered_out_count definition relative to the user's People table. Combined with the row-shape listing, an agent has everything needed to call it and interpret the response.

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

Parameters4/5

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

Schema description coverage is already 100%, so the baseline is 3, but the description adds real meaning beyond it: it ties group_by/bucket together as a two-step count-then-drill pattern, states the practical cost of include_criteria and the workaround (a q, one bucket, or a small limit, or run_code), and explains that include_rejected aligns with the user's default view. These are operational semantics the schema alone does not convey.

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?

States a specific verb and resource ('Read one agent's People tab: the people its searches found plus the prospects it tracks') and immediately names the sibling it overlaps with ('the person id query_people uses'). It also declares a unique capability ('the only read that carries each person's LinkedIn degree and warm-intro connectors'), which lets an agent distinguish it from query_people and query_segment_people without opening any 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?

Spells out the questions it answers ('who is 1st-degree, who can introduce the user to someone, how many people are in each list, source or outreach stage'), the alternative read for wide pulls ('call this from run_code with limit up to 200'), and the two calling modes ('pass group_by alone' to count vs 'group_by plus a bucket' to list a group). When-to-use and alternatives are explicit rather than inferred.

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?