Skip to main content
Glama

Search people

search_people
Destructive

Pull LinkedIn people matching a filter set — each person returns name, current title & company, headline, location, industry, the LinkedIn profile URL, providerId (feed to get_recent_posts to personalize), salesNavLeadUrl (the InMail-ready URL — pass it, or {profileUrl, providerId}, to add_message_targets on an InMail campaign), openProfile (true = accepts InMail for free), connectionDegree, sharedConnectionsCount (warm-intro signal), tenureInRole/tenureInCompany (a SHORT tenure means newly in seat — a timing signal for outreach), and pendingInvitation (true = already invited, skip it). Feed the URLs to enrich_linkedin_urls / enrich_profiles for verified emails, or create_leads_bulk to add them to a campaign. COSTS LinkedNav credits per person returned (0.02 each; counting is free). ALWAYS size first with count_people, then call this with confirm:false to see the exact credit cost, get the user's yes, THEN confirm:true. Never pull more than the balance covers. Same filters as count_people (including the company revenue band — check revenueScope.complete), plus limit (default 25, max 100). BUILD A BIG LIST: to go past 100, pass the returned nextCursor back in as cursor (same filters, confirm:true) to pull the next batch — repeat until hasMore is false. For a large list, set format:"csv" to get an export-ready CSV block. Present results as a compact table (name / title / company / location) and, when the set is large, offer to (a) keep paging, (b) export to CSV, or (c) pull direct dials + emails via enrich_linkedin_urls.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax people to return THIS call (1–100, default 25). To exceed 100 total, page with cursor.
cursorNoPagination cursor from a previous search_people call's nextCursor — pass it back exactly as returned (it lasts 24 hours). Pass it with confirm:true to pull the NEXT batch — this is how you build a list larger than the 100/call cap. The cursor carries its search's filters, so pass the SAME filters or none. Omit for the first page.
formatNotable (default) = structured rows to render as a table. csv = also return an export-ready CSV string (columns: Name, Title, Company, Location, Industry, Shared Connections, Tenure in Role, LinkedIn URL) — use for large lists the user wants to save/hand off.table
titlesNoJob titles, e.g. ["Chief Technology Officer","VP of Engineering"]. Matched as OR'd keywords — pass variants to go broad.
confirmNofalse (default) = return the credit-cost estimate only (nothing charged). true = pull the people and charge credits after the user agreed. Continuation pages (with cursor) should pass confirm:true.
keywordsNoFree-text keywords searched across all profile fields (title, headline, about, company).
companiesNoCurrent companies by name, e.g. ["Google","Stripe"]. Each name is looked up and the top match used — when you already have LinkedIn company ids (find_companies / list_funding_signals return companyId), pass companyIds instead.
functionsNoJob functions/departments, e.g. ["Engineering","Sales","Marketing"].
locationsNoPerson locations in plain English, e.g. ["United States","London"]. Resolved to LinkedIn regions automatically.
companyIdsNoCurrent companies by LinkedIn company id — the companyId values find_companies / list_funding_signals return (up to 100). Exact: no name lookup, so no same-name mix-ups. Combine with seniorities and changedJobs / postedOnLinkedIn to get the decision-makers at signal companies who just moved / are posting.
industriesNoCompany industries in plain English, e.g. ["Software","Financial Services"].
changedJobsNoOnly people who recently changed jobs (buying signal).
senioritiesNoSeniority levels, e.g. ["CXO","VP","Director","Manager"] (owner/partner, cxo, vice_president, director, experienced_manager, entry_level_manager, strategic, senior, entry_level, in_training).
revenueCurrencyNoISO currency of the revenue band, e.g. "USD" (default), "EUR", "GBP".
postedOnLinkedInNoOnly people who recently posted on LinkedIn (active/reachable signal).
companyHeadcountsNoCompany size bands. Valid: self-employed, 1-10, 11-50, 51-200, 201-500, 501-1000, 1001-5000, 5001-10000, 10001+.
companyMaxRevenueMillionsNoOnly people at companies with at most this annual revenue, in millions (e.g. 100 = up to $100M). Same brackets as companyMinRevenueMillions.
companyMinRevenueMillionsNoOnly people at companies with at least this annual revenue, in millions (e.g. 10 = $10M+) — use it to target companies that can afford the user's price. LinkedIn uses fixed brackets (0, 0.2, 1, 2.5, 5, 10, 20, 50, 100, 500, 1000); other values widen to the nearest one. The companies are matched on the same industries / companyHeadcounts / locations (as HQ location). Revenue is LinkedIn's estimate — companies without one are left out.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations, which only declare readOnly=false, openWorld=true, destructive=true. The description quantifies the cost (0.02/person), states counting is free, warns to never exceed balance, explains the confirm-gating workflow, cursor lifetime, and CSV export behavior — rich behavioral context an agent cannot infer from annotations alone.

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 purpose and return fields, then cost, then the confirm workflow, then pagination — a sensible priority order. It is long, but given 18 parameters, credit spend, and a multi-step workflow, nearly every sentence earns its place; only mild redundancy with the schema.

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 tool with 18 parameters, no output schema, and a credit cost, the description covers the return fields, cost model, confirmation gate, and paging strategy. Nothing an agent needs to invoke it correctly and safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents limit, cursor, format, confirm and all filters in detail. The description restates defaults, maxes, and the pagination contract but adds little semantic detail the schema does not already carry. Baseline 3 is appropriate.

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 ('Pull LinkedIn people matching a filter set') and enumerates exactly what each person record contains. It also distinguishes itself from siblings by naming count_people as the sizing step and enrich_linkedin_urls / create_leads_bulk as downstream consumers, so an agent can place it precisely in the workflow.

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 an explicit, mandatory sequence: ALWAYS size first with count_people, then call with confirm:false to see cost, get the user's yes, THEN confirm:true. It also states when to page (cursor), when to use format:"csv" (large lists), and names the alternative tools for enrichment and campaign adds.

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.