Skip to main content
Glama

PeopleSearch.im

Find & unlock a batch of people

find_people
Idempotent

The list-building tool. Runs a people search exactly as people_search does (the same filters or query, including its automatic broadening, reported in broadenedBy) and unlocks up to count full profiles in ONE atomic charge: 1 credit per newly unlocked person, and anyone you already own is free. Pass the same filters you checked with people_search, so you pay for the people you saw. Returns each person's real name, title, company, location, LinkedIn URL and an id. Emails are NOT fetched here (that is a separate credit): after unlocking, call fetch_email with each person's id to get their verified work email. WARNING for autonomous use: this can spend up to count credits in a single call, so choose count deliberately and confirm with the user before large batches. Returns an out-of-credits error instead of overspending.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoHow many people to unlock, 1-100 (default 25). Spends up to this many credits.
queryNoWho you are looking for, in plain English (role, seniority, industry, company, company size, location). Parsed for you. A company's website identifies it exactly, alone or in brackets after its name ('Head of Growth at Linear (linear.app)'). Optional when `filters` is given, where it is only a label.
filtersNoExact filters, recommended for AI agents and programs: state each part of the request instead of a sentence. Values inside one list are alternatives (OR); different fields must all match (AND). Give a few variants where people word things differently (titles: ["M&A Associate", "Investment Banking Associate"]). When filters are given, `query` is only a label and is not parsed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / filters / properties / company_ids
      Added value: +{
      +  "description": "Current employers by their LinkedIn company page, the most exact way to name a company: the page's URL or its name in the URL, e.g. [\"https://www.linkedin.com/company/google\"] or [\"google\"], or LinkedIn's numeric company id. Use it for large companies, whose website often misses them (Google's page lists a short link, Amazon's lists aboutamazon.com).",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / filters / properties / company_domains / description
      Previous value: -"Current employers by website domain, the most exact way to name a company, e.g. [\"stripe.com\"]."New value: +"Current employers by the website their LinkedIn company page lists, e.g. [\"stripe.com\"]. Exact for most companies, but some large ones list another site (Amazon's page lists aboutamazon.com, so amazon.com finds AWS staff), and a domain that hosts other organisations' pages (google.com) matches those organisations: check the company of the people returned."
  3. Changed1 schema field changed
    • changedInput schema / properties / filters / properties / job_titles / description
      Previous value: -"Current job titles, matched as case-insensitive substrings (\"Account Executive\" also finds \"Senior Account Executive\"). Include the variants people use: [\"VP Sales\", \"Vice President of Sales\", \"Head of Sales\"]."New value: +"Current job titles, matched as case-insensitive whole words (\"Account Executive\" also finds \"Senior Account Executive\"). Each is also searched in its other spellings (\"CEO\" and \"Chief Executive Officer\", \"VP Sales\" and \"Vice President of Sales\"). A bare \"President\" or \"Owner\" means the top job: Vice Presidents and Product Owners are left out unless you list such a title too. When nobody holds the titles, the same job under other titles is searched first (the company's President or Owner for \"CEO\"), reported in broadenedRole."
  4. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Who you are looking for, in plain English (role, seniority, industry, company, company size, location). Parsed for you. Optional when `filters` is given, where it is only a label."New value: +"Who you are looking for, in plain English (role, seniority, industry, company, company size, location). Parsed for you. A company's website identifies it exactly, alone or in brackets after its name ('Head of Growth at Linear (linear.app)'). Optional when `filters` is given, where it is only a label."
  5. Changed2 schema fields changed
    • addedInput schema / properties / filters / properties / first_name
      Added value: +{
      +  "description": "To find one named person: their first name, with the variants they may use, e.g. [\"Timothy\", \"Tim\"]. Use with last_name, and add companies or company_domains when known (\"Anqi Dai at Memorial Sloan Kettering\" finds the one person).",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / filters / properties / last_name
      Added value: +{
      +  "description": "To find one named person: their last name, e.g. [\"Dai\"]. If the name with the employer finds nobody, the search tries the last name at the employer, then the full name anywhere.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  6. Changed1 schema field changed
    • addedInput schema / properties / filters / properties / company_keywords
      Added value: +{
      +  "description": "Words the current employer's own description should contain, for a KIND of employer no industry names exactly, e.g. [\"hostel\"], [\"coffee\"] (founders of coffee roasteries), [\"SEO\"] (with industries [\"Marketing Services\"] for SEO agencies), [\"community college\"].",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  7. Changed3 schema fields changed
    • addedInput schema / properties / filters
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "Exact filters, recommended for AI agents and programs: state each part of the request instead of a sentence. Values inside one list are alternatives (OR); different fields must all match (AND). Give a few variants where people word things differently (titles: [\"M&A Associate\", \"Investment Banking Associate\"]). When filters are given, `query` is only a label and is not parsed.",
      +  "properties": {
      +    "companies": {
      +      "description": "Current employers by name, e.g. [\"Stripe\"].",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "company_domains": {
      +      "description": "Current employers by website domain, the most exact way to name a company, e.g. [\"stripe.com\"].",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "company_size_max": {
      +      "description": "Maximum employees at the current employer.",
      +      "minimum": 1,
      +      "type": "integer"
      +    },
      +    "company_size_min": {
      +      "description": "Minimum employees at the current employer.",
      +      "minimum": 1,
      +      "type": "integer"
      +    },
      +    "exclude_job_titles": {
      +      "description": "Titles to leave out, e.g. [\"Intern\", \"Recruiter\"].",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "industries": {
      +      "description": "Industry of the current employer, as LinkedIn names it, e.g. [\"Investment Banking\"], [\"Software Development\"], [\"Hospitals and Health Care\"], [\"Venture Capital and Private Equity Principals\"], [\"Staffing and Recruiting\"]. Common older names are mapped; a name that is not an industry is reported in `ignored` and not applied.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "job_titles": {
      +      "description": "Current job titles, matched as case-insensitive substrings (\"Account Executive\" also finds \"Senior Account Executive\"). Include the variants people use: [\"VP Sales\", \"Vice President of Sales\", \"Head of Sales\"].",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "keywords": {
      +      "description": "Words to find anywhere on the profile (headline, descriptions, past roles), for what no other field covers.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "languages": {
      +      "description": "Languages the person speaks, e.g. [\"German\"] or [\"DE\"].",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "locations": {
      +      "description": "Where the person lives or works: cities, states, countries or regions, e.g. [\"Frankfurt\", \"Munich\"], [\"Germany\"], [\"DACH\"], [\"Texas\"]. Use \"City, Country\" to tell same-named places apart (\"Paris, France\"). Country names are safest; ISO codes are converted.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "past_companies": {
      +      "description": "Former employers by name, e.g. [\"McKinsey\"] for ex-McKinsey people.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "past_job_titles": {
      +      "description": "Titles the person held before their current job.",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "schools": {
      +      "description": "Schools the person attended, matched as substrings; add the local-language name too, e.g. [\"University of Mannheim\", \"Universität Mannheim\"].",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "skills": {
      +      "description": "Skills listed on the profile, e.g. [\"Python\", \"Kubernetes\"].",
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "years_experience_max": {
      +      "description": "Maximum total years of professional experience.",
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    "years_experience_min": {
      +      "description": "Minimum total years of professional experience.",
      +      "minimum": 0,
      +      "type": "integer"
      +    }
      +  },
      +  "type": "object"
      +}
    • changedInput schema / properties / query / description
      Previous value: -"Who you want, in plain English (same grammar as people_search)."New value: +"Who you are looking for, in plain English (role, seniority, industry, company, company size, location). Parsed for you. Optional when `filters` is given, where it is only a label."
    • removedInput schema / required
      Removed value: -[
      -  "query"
      -]
  8. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations give the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds materially beyond them: the exact credit model (1 credit per newly unlocked person, already-owned people free, up to `count` credits in ONE atomic charge), the out-of-credits error instead of overspending, and an explicit warning telling an autonomous agent to pick `count` deliberately and confirm large batches. This is exactly the kind of cost/consequence disclosure annotations cannot carry.

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-loaded with the one-line identity of the tool, then cost model, then return values, then the credit warning. Every sentence carries information, but there is minor redundancy between the opening 'unlocks up to count... 1 credit per newly unlocked person' and the later 'spends up to count credits', and the warning could sit closer to the cost sentence.

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?

With no output schema and a complex, nested-filter, credit-spending tool, the description still covers what is returned (real name, title, company, location, LinkedIn URL, `id`), what is not returned (emails), the broadening signal (`broadenedBy`), the failure mode (out-of-credits error), and the next tool to call. An agent has everything needed to invoke it 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 coverage is 100%, so the baseline is 3. The description adds meaning over the schema by tying `count` directly to spend ('choose `count` deliberately', 'spends up to count credits') and by explaining that `filters` and `query` are interchangeable in the same way as people_search, including the automatic broadening reported in `broadenedBy`. That is real added framing, though most field-level detail remains in the schema.

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?

Opens with a clear positioning statement ('The list-building tool') and states a specific action pair: it searches exactly like people_search and unlocks up to `count` full profiles in one atomic charge. It distinguishes itself from the closest siblings (people_search for searching, fetch_email for emails) without the agent needing to open either 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?

Explicit routing: pass the same filters you checked with people_search so you pay only for people you saw, and call fetch_email afterwards with each `id` for emails. When-not-to-use is also stated ('Emails are NOT fetched here'). Nothing is left to inference.

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