Skip to main content
Glama

Get People Search Status

people-search-status
Read-only

Status, progress, and cost of one People Search task, plus a page of the people found so far: name, handle, url, platform, audience, location, fit score, why they matched, contacts, and links. Free: it reads a search you already started and runs no new search. Cost fields are reserved_cost_usd and, once the search ended, final_cost_usd. People come from public profiles and posts on the search's platform, with only the contacts they list publicly. People arrive while the search runs: pass the returned next_cursor as cursor on the next call to get only the people found since then. When done is true and has_more is false you have everyone the search found. An ended task has completion_reason (why it stopped), coverage_limited: true when a budget stopped it before count (more people may match), and warnings such as partial_enrichment (some profiles could not be read, so those people were scored on the search hit; they show enrichment: failed). Each person has fully_verified (every criterion confirmed by their own profile or posts) and unverified_criteria (criteria that are unknown or not met, or a disqualifier that applies). These are information only: the person still qualified.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "task_id": "<task_id>"
    },
    "name": "people-search-status"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoPeople per page (1-100, default 25).
cursorNonext_cursor from the previous people-search-status call. Omit to start from the first person.
task_idYestask_id returned by people-search, example: '3f1c2b9e-8d4a-4c1e-9b7a-2e5f6a7b8c9d'
include_peopleNoSet false to read only the status, progress, and cost.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly annotation it discloses cost fields, incremental pagination via next_cursor, completion_reason, coverage_limited when a budget stopped the search early, and partial_enrichment warnings with how affected people appear. It also clarifies that fully_verified and unverified_criteria are informational only and do not disqualify a person, which an agent could easily misread.

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?

Purpose and the free read-only nature are front-loaded, and nearly every sentence carries operational detail (costs, cursors, completion, warnings). It is a single dense block though, and the verification semantics at the end would scan better as separated sentences or bullets.

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 compensates by enumerating the returned person fields, the cost fields, the pagination envelope, and the terminal-state flags. An agent can both call it correctly and interpret the response without further documentation.

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 coverage is 100%, so the baseline is 3; the description earns more by explaining the cursor contract (pass the returned next_cursor to get only people found since then) and implying the status-only read path. It doesn't add anything about limit, but that is already fully documented.

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: status, progress, and cost of one People Search task, plus a page of people found. The listed return fields (name, handle, url, platform, fit score, contacts) make it unmistakable against siblings like people-search-tasks or people-search.

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?

Explicitly says it reads a search already started and runs no new search, which implicitly routes agents away from people-search for starting work, and gives the exact completion condition (done true + has_more false). It never names a sibling tool such as people-search-tasks, so the exclusion is inferred rather than stated.

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.