Skip to main content
Glama
Sign In

PeopleSearch.im

by im.peoplesearch
OverviewDiscussionsAdmin

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. Set include_email to true when the user wants to contact them: each person's verified work email is looked up in the same call, 1 more credit each, refunded when none is found (lookups still running are collected free with fetch_email and the id). Without it, call fetch_email with each person's id later. WARNING for autonomous use: this can spend up to count credits in a single call (twice that with emails), so choose count deliberately and confirm with the user before large batches. Returns an out-of-credits error instead of overspending.

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

Input 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.
include_emailNoAlso look up each unlocked person's verified professional email (1 more credit each, refunded if none is found). Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / include_email
      Added value: +{
+  "description": "Also look up each unlocked person's verified professional email (1 more credit each, refunded if none is found). Default false.",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / filters / properties / company_domains / description
      Previous 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."New value: +"Current employers by website, e.g. [\"stripe.com\"]. Each website is searched as the company that owns it (its LinkedIn page), so a domain that also hosts other companies' pages (careers pages on workable.com, payment links on stripe.com) finds only the owner's staff. Some large companies' pages list another site (Amazon's lists aboutamazon.com): name those with company_ids."
  3. Changed1 schema field changed
    • changedInput schema / properties / filters / properties / companies / description
      Previous value: -"Current employers by name, e.g. [\"Stripe\"]."New value: +"Current employers by name, e.g. [\"Stripe\"]. A name written with a legal form or a listing's tagline (\"Stripe, Inc.\", \"Acme Pvt Ltd - Software House\") is searched without it; for an exact company use company_domains or company_ids."
  4. Changed2 schema fields changed
    • addedInput schema / properties / filters / properties / exclude_companies
      Added value: +{
+  "description": "Current employers to leave out, by name, e.g. [\"Stripe\"]. Needs another field to search by: with past_companies [\"Stripe\"] it finds former Stripe employees who no longer work there (11,810 of the 14,616 with Stripe in their past, measured 2026-10-19).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / filters / properties / past_companies / description
      Previous value: -"Former employers by name, e.g. [\"McKinsey\"] for ex-McKinsey people."New value: +"Former employers by name, e.g. [\"McKinsey\"] for ex-McKinsey people. Some people with a company in their past work there again or still: add the same names to exclude_companies for people who have left (\"former employees of Stripe\")."
  5. 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"
+}
  6. 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."
  7. 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."
  8. 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."
  9. 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"
+}
  10. 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"
+}
  11. 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"
-]
  12. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description discloses the credit model (1 per newly unlocked person, already-owned profiles free, +1 per email with refund when not found), the maximum possible spend, and that exceeding credits returns an error rather than overspending. This is a strong behavioral picture, though it leaves the atomicity/failure semantics if a batch partially fails unstated.

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 identity ("The list-building tool") then cost, then the email branch, with no filler sentences. It is dense and long, and the credit explanation is restated in both the body and the warning, costing a little tightness.

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 spending, nested-schema tool with no output schema, the description covers what comes back (name, title, company, location, LinkedIn URL, `id`, plus `broadenedBy`), how broadening is reported, and how to continue with fetch_email. Nothing an agent needs to invoke this safely 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 earns above that by tying `count` to credit spend and framing `include_email` in terms of cost, refunds, and an alternative follow-up path with fetch_email. It adds real economic meaning to the two non-obvious parameters without contradicting the schema's own wording.

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 list-building tool. Runs a people search exactly as people_search does ... and unlocks up to `count` full profiles in ONE atomic charge" states the verb (search + unlock), the resource (people), and the distinguishing scope against the search-only sibling. An agent can tell immediately that this is search-plus-purchase rather than a preview or a single-profile reveal.

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 routing: reuse the same `filters` you checked with people_search so you pay only for people you saw; set `include_email` when the user wants to contact them; otherwise call fetch_email later with the `id`. It also names the sibling alternatives (people_search, fetch_email) and the condition that selects each, plus an autonomous-use warning to confirm large batches with the user.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All PeopleSearch.im toolsInspect
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