Skip to main content
Glama

Search people

search_people

PAID (needs a key) — 2 credits per page of up to 25 people, only for pages the database counts (a repeat within 30 days and an empty result cost nothing). Finds people in the B2B contact database by job title, seniority, department, place, industry, company size or company. The people go into a list in ListPlus (name, job title, company, domain, LinkedIn, place — no e-mail or phone: those are enrich_records, priced in options). Up to 4 pages per call, a cursor for the next ones (20 pages deep). Exact values from search_options; estimate:true shows the filters as understood and the price (free, no key).

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

Input Schema

NameRequiredDescriptionDefault
pagesNoPages of up to 25 to load in this call (default 1)
cursorNoFrom the last answer: the next pages of the same search into the same list
list_idNoAppend to this list of the workspace (default: a new list per search)
estimateNotrue = the filters as understood and the price, nothing runs (free, no key)
keywordsNoWords in the person's profile
languageNoLanguage of `tell_your_user` (default en)
companiesNoCompany names
has_emailNoOnly people the database holds a verified work e-mail for
headcountNoThe company's size class, e.g. 51-100 — values: search_options category headcount
list_nameNoThe new list's name
locationsNoWhere the PERSON is: cities, countries, territories (DACH, EMEA)
has_mobileNoOnly people the database holds a verified mobile number for
industriesNoThe company's industries; everyday words like saas or fintech are understood — values: search_options category industries
job_titlesNoMatched as CONTAINS unless exact_titles
departmentsNoDepartments, e.g. Marketing, Sales — values: search_options category departments
max_creditsNoThe most this call may cost; it loads fewer pages / refuses rather than spend more
senioritiesNoSeniorities, e.g. Director, VP, C-Suite — values: search_options category seniorities
exact_titlesNotrue = job titles match exactly, not as "contains"
company_domainsNoCompany domains, e.g. acme.com (more exact than names)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior3/5

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

Goes well beyond the annotations by disclosing the credit model (2 credits per page of up to 25 people, repeats within 30 days and empty results are free) and the max_credits refusal behaviour. It also explains that results are written into a ListPlus list and that no e-mail or phone is returned, which is meaningful given readOnlyHint=false. The annotation is consistent with the described write-to-list side effect.

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?

Front-loads the cost model, which is the thing an agent most needs before calling, and every clause carries information. The single dense paragraph with nested parentheses and dashes is harder to parse than it needs to be, but nothing is redundant.

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?

For a 19-parameter, side-effecting search with no output schema, it covers cost, pagination depth, output fields, list behaviour, the free preview path, and where the enum values come from. Nothing an agent needs in order to call it correctly 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 already 100%, so the baseline is 3. The description still adds real meaning on top: page size and credit cost tied to `pages`, the 20-page cursor depth, the free/price-check semantics of `estimate`, and the note that `list_id` appends while the default creates a new list per search.

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 ("Finds people in the B2B contact database") and enumerates the filter dimensions (job title, seniority, department, place, industry, company size, company). It also distinguishes itself from enrich_records by naming it as the path for e-mail and phone data.

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?

Gives clear operating guidance: exact values come from search_options, estimate:true is the free dry run, up to 4 pages per call with a cursor for the rest (20 pages deep). It does not distinguish itself from the sibling find_person, so the agent must infer which of the two to use for a single-person lookup.

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