Skip to main content
Glama

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 is FREE and spends no credits: use it to check that the right people come back before you pay, 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.

Input Schema

TableJSON 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
    • 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 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"
-]
  8. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly/idempotent/openWorld/destructive=false) by disclosing that results are masked previews carrying an opaque token, that searching spends no credits, that the search auto-broadens (broadenedRole, broadenedBy, ignored), and that without an account it returns at most 3 previews across 10 searches a day. These are exactly the operational traits an agent needs before calling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the free-search constraint are front-loaded, which is good, but the body is a single dense paragraph mixing behavioral rules, examples and edge cases. The inline JSON and plain-English examples largely duplicate what the schema already shows, so several clauses do not fully earn their place.

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, the description must explain returns, and it does: masked name, role, industry, company size, location, an opaque token, and the total match count, plus the broadening/ignored reporting fields. Combined with the free/rate-limit and no-account details, an agent has everything needed to call and interpret this tool.

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 description coverage is 100%, so the baseline is 3, but the description adds strategy-level semantics: state each filter part exactly, prefer filters over query, and treat query as a label when filters are present, plus a worked filters example. Some of this overlaps the schema's own filters description, so it is reinforcement rather than wholly new meaning.

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') plus the output shape (sample of matches + true total match count). It also distinguishes itself from siblings by naming reveal_profile and find_people as the paid follow-up steps, so an agent can place it in the workflow without opening other schemas.

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: search is free and should be used to validate results before paying; reveal_profile is for one person's real name/LinkedIn/email; find_people unlocks a batch with the same filters. It also covers the named-person case (first_name + last_name with company) and the no-industry-name case (company_keywords), giving when-to-use and when-to-use-something-else.

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