Skip to main content
Glama
Sign In

PeopleSearch.im

by im.peoplesearch
OverviewDiscussionsAdmin

Search people

people_search
Read-onlyIdempotent

Search a global professional database for people and get a sample of matches plus the true total match count. Ask with filters (recommended: state each part exactly, for example {"job_titles": ["M&A Associate", "Investment Banking Associate"], "locations": ["Frankfurt", "Munich"], "industries": ["Investment Banking"], "schools": ["University of Mannheim"]}) or with query, a plain-English sentence that is parsed for you (for example 'Heads of Marketing at Series B SaaS in New York'). Results are masked previews (a masked name, role, industry, company size and location) and each one carries an opaque token. Searching uses no credits: use it to check that the right people come back before revealing anyone, and refine the filters if they do not. To look up one named person, give first_name and last_name with their company or company domain when known. For a kind of employer no industry names exactly, use company_keywords (words its own description contains, for example ["hostel"] or ["SEO"] with industries ["Marketing Services"]). If nothing matches exactly, the search broadens itself: a job title is read more broadly first (broadenedRole gives the title as asked and as searched), then the least essential filters are dropped and broadenedBy names them; ignored lists any filter that could not be applied. To get a person's real name, LinkedIn and verified email, pass their token to reveal_profile, or use find_people with the same filters to unlock a batch in one call. It also works before a PeopleSearch.im account is connected: without one it returns up to 3 previews per search, up to 10 searches a day.

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

Input Schema

NameRequiredDescriptionDefault
limitNoHow many masked previews to return (1-25, default 10). This does not limit the reported total.
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
    • 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."
  2. 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."
  3. 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\")."
  4. 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"
+}
  5. 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."
  6. 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."
  7. 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."
  8. 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"
+}
  9. 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"
+}
  10. 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 are looking for, in plain English. Include role, seniority, industry, company stage/size, and location as needed."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"
-]
  11. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond readOnly/openWorld annotations, it discloses that results are masked previews carrying opaque tokens, that searching consumes no credits, that broadening happens in stages (broadenedRole, then dropped filters reported in broadenedBy, then ignored), and that without a connected account it caps at 3 previews and 10 searches a day. The broadening and quota behavior are exactly the facts an agent cannot infer from annotations or schema.

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 search-then-reveal workflow are front-loaded, and nearly every sentence carries operational content. It is still a single dense block with some duplication of schema field explanations, which costs it a point against a tighter structure.

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, yet the description explains the shape of results (masked name, role, industry, company size, location, token) and the metadata fields returned on broadening or ignored filters. Combined with the auth/quota notes, an agent has everything needed to call this and interpret the response.

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% and each nested filter is already documented, so much of the description's field talk is repetition (company_keywords, job_titles broadening). It still adds strategy the schema does not: a worked filters example, the rule that query degrades to a label when filters are present, and the advice to supply wording variants because values within a list are OR'd.

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 (search a global professional database for people) and what comes back (masked sample plus true total count). It clearly separates itself from reveal_profile and find_people by naming them as the routes to unmasked identities and batch unlocking.

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: filters vs query for discovery, first_name/last_name plus company for one named person, company_keywords for employer kinds no industry names, and reveal_profile / find_people for unlocking. It also tells the agent to search first and refine because searching costs no credits, which is a concrete when-to-use policy rather than an implication.

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