Sliq

Query Task People

query_task_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 null, with the reason from the latest row carrying it; on a group_by='list' bucket page, 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 a group_by='list' bucket page. A person rejected on every row is left out unless a "verdict" filter asks for 'rejected' 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 only 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). 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, the number of rows a read filtered on verdict 'rejected' alone returns across the whole agent, whatever q and filters: people, or with group_by="list" person-list pairs, so a person rejected on two lists counts twice.

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 'rejected' (the people the user's default view filters out) and/or 'qualified'; 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 "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.
`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.

Changed2 schema fields changedSep 30, 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.\nFor \"name\", \"title\", \"headline\", \"company\" or \"location\", use {\"column_key\":\n<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\n'rejected' (the people the user's default view filters out) and/or 'qualified'; it\nmatches each person's `verdict`, or with group_by=\"list\" their verdict on each list,\nand 'rejected' brings the rejected people in without `include_rejected`. For \"name\",\n\"title\", \"headline\", \"company\" or \"location\", use {\"column_key\": <column>,\n\"operator\": \"contains\", \"text\": <substring>}."

addedInput schema / properties / include_rejected

Added value: +{
+  "default": false,
+  "description": "Also return (and count) the people left out as rejected. Default False.",
+  "type": "boolean"
+}

Changed4 schema fields changedSep 29, 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 \"name\", \"title\",\n\"headline\", \"company\" or \"location\", use {\"column_key\": <column>, \"operator\":\n\"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.\nFor \"name\", \"title\", \"headline\", \"company\" or \"location\", use {\"column_key\":\n<column>, \"operator\": \"contains\", \"text\": <substring>}."

changedInput schema / properties / group_by / anyOf

Previous value: -[
-  {
-    "enum": [
-      "title",
-      "company",
-      "location",
-      "outreach_stage",
-      "list",
-      "source",
-      "degree",
-      "connector"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "title",
+      "company",
+      "location",
+      "outreach_stage",
+      "list",
+      "source",
+      "degree",
+      "connector",
+      "segment"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / group_by / description

Previous value: -"The dimension to count or to pick a bucket from. \"degree\" keys are '1', '2',\n'3', 'out_of_network'; \"connector\" keys are a connector's provider_id (else their\nidentifier or name) and carry the connector's name as `label`; \"outreach_stage\"\nkeys are funnel buckets; \"list\" and \"source\" keys are list names and discovery tools; \"title\", \"company\" and \"location\"\nkey on the person's own value. A '' key is the group with no value. A person with\nseveral lists, sources or connectors counts in each."New value: +"The dimension to count or to pick a bucket from. \"degree\" keys are '1', '2',\n'3', 'out_of_network'; \"connector\" keys are a connector's provider_id (else their\nidentifier or name) and carry the connector's name as `label`; \"outreach_stage\"\nkeys are funnel buckets; \"list\" and \"source\" keys are list names and discovery tools;\n\"segment\" keys are tag names in `segment_group_id`'s group, plus 'No match' for people\nthe classifier couldn't place; \"title\", \"company\" and \"location\" key on the person's\nown value. A '' key is the group with no value (for \"segment\", people the group hasn't\nclassified). A person with several lists, sources, connectors or tags counts in each."

addedInput schema / properties / segment_group_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The segment group (from list_segment_groups or get_segment_funnel) a\n\"segment\" filter or group_by reads. With it, each row also carries `segment`, its tag\nnames in that group."
+}

Changed1 schema field changedSep 25, 2026

addedInput schema / properties / include_criteria

Added value: +{
+  "default": false,
+  "description": "Also return each row's `criteria`. Default False.",
+  "type": "boolean"
+}

Changed2 schema fields changedSep 25, 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 \"name\", \"title\",\n\"company\" or \"location\", use {\"column_key\": <column>, \"operator\": \"contains\",\n\"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 \"name\", \"title\",\n\"headline\", \"company\" or \"location\", use {\"column_key\": <column>, \"operator\":\n\"contains\", \"text\": <substring>}."

changedInput schema / properties / q / description

Previous value: -"A substring matched against name, title and company."New value: +"A substring matched against name, title, headline and company."

AddedSep 24, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With only readOnlyHint=true available from annotations, the description carries the behavioral load and does so richly: default 25 rows, limit up to 200 with 'nothing truncates' in run_code, page-until-next_cursor-null semantics, the ~2KB per-person cost of criteria, and the rejection-filtering rule that matches the user's default view (with tracked prospects always shown). This is far beyond what the annotation states.

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?

Dense but front-loaded and well organized: the summary states the resource, the field list explains each row key, and usage/pagination guidance closes it out. Given 10 parameters and a non-trivial output shape, the length is largely earned, though the row-field enumeration is verbose enough to slow scanning.

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?

There is no formal output schema, so the description must document returns, and it does so thoroughly via the <returns> block (group_counts vs results/next_cursor/total, and filter_counts semantics) alongside the per-row field breakdown. An agent has everything needed to call and interpret this tool correctly.

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 100%, so the baseline is 3, but the description adds genuine meaning the schema does not: the group_by/bucket dependency, the cost warning on include_criteria, the escaped '' key semantics, and the run_code-wide-pull advice. It stops short of restating every parameter's shape, but the supplemental semantics are real.

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 opens with a precise verb+resource ('Read one agent's People tab: the people its searches found plus the prospects it tracks, one row per person') and explicitly claims a unique capability ('the only read that carries each person's LinkedIn degree and warm-intro connectors'). This lets an agent distinguish it from siblings like query_people, query_prospects 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 Guidelines4/5

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

It gives concrete usage context ('use it for questions about who is 1st-degree, who can introduce the user to someone, how many people are in each list') and operational guidance for group_by/bucket and pagination. It does not name an explicit alternative to use instead, so the routing is implied rather than stated, keeping this below a 5.

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?