Skip to main content
Glama

Iridium: LinkedIn MCP Server

search_prospects

Search Prospects

The cheapest people search there is: ONE LinkedIn action, no profile opened, no badge checked. Reads only, drafts nothing.

It is not specific to any signal. It returns whoever matches the query and location — that is all it knows. hiring_only / open_to_work_only do NOT filter and do NOT confirm anything: they only REORDER the same results using hints in the headline and title text, which is a guess, not the badge. Someone with the real #hiring badge and a plain headline sorts last; someone who typed "hiring" in their headline and has no badge sorts first.

USE THIS to browse cheaply, or to get a long list to narrow by hand.

DO NOT USE when the answer has to be TRUE about a badge — "people who are actually hiring", "who is really open to work". This tool cannot know: the badge lives only on the full profile. Use find_prospects, which opens profiles and tells you which candidates it confirmed.

DO NOT USE when the user wants messages written. discover_prospects searches and drafts a connection note for each person in one call.

Results are read live from LinkedIn at the time of the call.

Args: hiring_only / open_to_work_only: the profile BADGE (is_hiring / is_open_to_work), not post text. The badge is never in a people-search result — it lives only on the full profile (SEARCH.md §7.1/§7.4) — so these do NOT filter; an earlier version faked the filter out of headline text and returned a near-empty list for almost every real query. Instead they SORT by how likely each result is to carry the badge, from free signals already in the search result (headline phrasing, an empty current work history). Nothing is ever dropped — see note in the response. This tool opens no profiles, so it never confirms a badge: cost 0 touches, certainty 0. To confirm, use find_prospects with max_touches (1 touch each). posted_recently: neither badge nor post text — an ACTIVITY filter ("posted at all in the past 30 days", regardless of what about). Free at search time, needs a Sales Navigator seat; on any other plan the search runs without it and tier_note says so. Default false. open_to_work: the profile BADGE, confirmed for free at search time by LinkedIn's own "Open to work" spotlight — applied before results come back, so 0 profile reads. Needs a full Recruiter seat (Recruiter Lite has no such spotlight); on any other plan the search runs without it and tier_note says so. Default false. Note this is the same badge as open_to_work_only above; the difference is that this one is CONFIRMED by LinkedIn and free, while that one is only a guess at the ordering.

Responses:

200: Successful Response (Success Response) Content-Type: application/json

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYes
locationYes
hiring_onlyNo
open_to_workNo
posted_recentlyNo
open_to_work_onlyNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: declares 'Reads only, drafts nothing', quantifies cost (ONE LinkedIn action, zero profile touches), discloses that results are read live at call time, and explains that hiring_only/open_to_work_only reorder rather than filter — including the prior buggy behavior. It also flags that posted_recently and open_to_work require Sales Navigator / full Recruiter seats and degrade gracefully with a `tier_note`.

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?

Well front-loaded — cost and read-only nature appear in the first two lines, and the USE/DO NOT USE blocks are easy to scan. But the 'the badge lives only on the full profile' point is restated at least four times across the header and Args section, inflating a definition that could be a third shorter without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No annotations and no output schema, yet the description covers safety, cost, tier gating, the sort-not-filter semantics, and even references response fields (`note`, `tier_note`). The remaining gap is on the mechanics of the required query/location strings and the `limit` cap, which an agent must guess.

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 0% and there are 7 params, so the description has to compensate — and it explains four of them in real depth, including the crucial distinction between open_to_work (LinkedIn-confirmed spotlight) and open_to_work_only (headline-based guess). However, query, location, and limit are never described (no syntax, no format, no pagination guidance), leaving three params undocumented.

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+resource ('search prospects') and immediately bounds its scope: matches on query and location only, no signal filtering, no profile opens. It explicitly distinguishes itself from find_prospects (profile-confirming) and discover_prospects (search + draft), so an agent can pick it without opening any 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?

Provides explicit 'USE THIS' and two 'DO NOT USE WHEN' clauses, each naming the alternative tool and the condition that selects it (badge truth → find_prospects; message drafting → discover_prospects). This is the textbook when/when-not/alternatives structure.

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