Skip to main content
Glama
This connector has been deprecated

Duplicate listing. The official PumpGTM connector is https://glama.ai/mcp/connectors/com.pumpgtm/mcp (same server, https://mcp.pumpgtm.com/mcp).

Check a people search

get_people_search
Read-onlyIdempotent

Read a people search without starting anything. With operationId: the progress or results of a search find_people started; poll it after a short wait until status is completed or failed, and never start a new request to check progress. When it completed, show the targeting from plan.targetingSummary, then every candidate neutrally in retrieval order with name, current title, company, LinkedIn URL and match reason; never rank, shortlist or silently drop anyone, record the customer's add and skip choices with review_people, and mention any companyResolution outcome of matched_several or unmatched in one line. With playId: a saved Play's complete targeting, so you can tell the customer in plain words what it looks for and they can say what to change (revise or rerun it with find_people). Read-only: spends no Energy, saves nothing and contacts no one. Returns the operation's status, plan, batch and candidates, or the Play's plan and whether the balance can run it.

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": "get_people_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
playIdNoA saved Play's ID from get_workspace or an earlier find_people result; reads its targeting.
operationIdNoThe operationId a find_people call returned; reads that search's progress or results.
workspaceIdNoA teammate's workspace you may manage: an active workspace ID from list_team_workspaces. Omit for your own workspace. Supply on every call for a teammate.

Output Schema

NameRequiredDescriptionDefault
listNoFounder list: which list was read.
nextNoThe suggested next call, or null.
planNoThe saved Play's plan.
playNoThe Play this call saved or read.
batchNoThe review batch of found people.
foundNoFounder list run: how many people were found.
energyNoWhen the balance falls short: Energy required, remaining and the step that gets more.
filterNoFounder list: the filters applied.
statusNoThe operation's status: queued, running, completed or failed (or a start status for a list or account list).
messageNoA line to relay to the customer.
optionsNoFounder list: the filter values to offer.
playUrlNoThe Play's page, where found people are reviewed.
accountsNoAccount list: the groups and companies.
matchingNoFounder list: how many founders match.
nextStepNoWhat to tell the customer next.
reviewInNoWhere and when found people appear for review.
searchedNoWhether this call searched for people.
companiesNoAccount list or template Play: the companies involved.
contactedNoAlways false: finding people never contacts anyone.
reviewUrlNoThe attached sequence's page.
candidatesNoFound people in retrieval order; show every one, never ranked or dropped.
enrollmentNoFounder list run: who was added to the sequence.
readyToRunNofalse when the balance cannot pay for a run; message and energy say why.
operationIdNoThe saved search operation; poll it with get_people_search.
wouldCreateNoTemplate Play preview: what confirmed=true would create.
companyResolutionNoHow each named company resolved: matched, matched_several or unmatched.
groupsWaitingForEnergyNoAccount list: groups not started because Energy ran short.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent/non-destructive annotations by stating that it spends no Energy, saves nothing and contacts no one, and by describing polling semantics and a hard rule not to re-issue searches. It also discloses the downstream display obligations (neutral retrieval order, no ranking or silent drops) and how to report companyResolution outcomes of matched_several or unmatched.

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?

A dense single block, but it is front-loaded with the core purpose and the mode split before the longer display instructions. The presentation rules are lengthy and could be tightened, yet each sentence carries operational guidance rather than repetition of the name or schema.

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?

Given an output schema exists, the description need not enumerate return fields, but it nonetheless summarises both return shapes and covers polling, presentation, downstream recording and the unmatched-company edge case. Nothing an agent needs to call this correctly across either mode is missing.

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 adds real meaning on top by explaining what each mode key returns and what the values are used for (operationId → live status/plan/batch/candidates, playId → the Play's full targeting plus balance check). It stops short of stating that the two are mutually exclusive or what happens if both are supplied.

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 a people search') and immediately splits the tool into its two distinct modes, operationId (a find_people operation's progress/results) and playId (a saved Play's targeting). An agent can tell this read tool apart from find_people, review_people and get_workspace from the description alone.

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?

Gives explicit when-to guidance for both modes: poll after a short wait, keep polling until status is completed or failed, and never start a new request to check progress. It also names the alternatives and the condition that selects them — review_people for recording add/skip choices, find_people to revise or rerun a Play.

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.

Resources