Skip to main content
Glama

Iridium: LinkedIn MCP Server

discover_prospects

Discover Prospects

Search for people, read their profiles, and generate connection note drafts. Up to 3 people come back right here, in about 10 to 40 seconds. More than 3 run in the background: you get a job_id at once, drafts appear in list_drafts and get_job as each is written, and the user is emailed when it finishes or pauses. Returns draft handles ready to approve or skip. Complement to run_outreach_pipeline, which works from the user's saved targets.

CHOOSING BETWEEN discover_prospects AND find_person The deciding question: does the user NAME a specific person, or DESCRIBE a kind of person?

USE find_person when the user names someone (a first and last name), however much else they say about them:

  • "Message Jane Doe, she used to be at Acme."

  • "Is this the John Smith who was at Acme?"

  • "Find Pat Lee at Globex and connect." Returns who they are plus proof (e.g. Acme, 2018-2024). Cost: 1 search plus up to 2 profile reads. Drafts nothing. To write to them afterwards, pass the handle to schedule_dm_to_person.

USE discover_prospects when the user describes a GROUP by role, place or topic and wants connection notes written for whoever is found:

  • "Find 5 ML engineers in San Francisco and draft notes to them."

  • "Reach out to heads of growth in Austin." Searches by query and location, reads each person's profile AND posts, and drafts a note per person. Cost: 1 search plus 2 reads per person (about 11 actions for 5 people). Nothing sends; drafts land in list_drafts. Use it only when the user wants drafts.

NEITHER (use find_prospects or search_prospects) when the user wants a list to browse, or to check a badge such as #hiring, with no notes wanted.

NEVER use discover_prospects to look up a named person: it cannot filter by name or former employer, it returns strangers, and it spends about 11 actions doing so. NEVER use find_person to build a list: it returns at most 2 people.

AMBIGUOUS: "Find me Acme alumni named Jane." This could mean one specific Jane (find_person) or any number of Janes who used to work at Acme, with notes drafted (discover_prospects). A first name only, or a plural, is a group. DO NOT GUESS: the two cost very different amounts and discover_prospects drafts messages. Ask the user one question before calling either, for example: "Do you mean one specific person (give me their full name), or should I find several people matching this and draft notes to them?" Then call exactly one tool.

If the user gave a full name plus any context, choose find_person without asking. Ask only when the request could fit both.

Data accuracy: profile names, companies, and headlines are fetched live from LinkedIn and reflect real, current information. Notes reference actual post content when available; when no posts are found, notes are conservative and based only on verifiable headline/company data.

suggested_send_at is a suggestion only. Nothing sends until approve_draft is explicitly called. Drafts remain in pending_review indefinitely.

Each draft includes a profile field with: about, current_role, past_companies, education, certifications, skills, follower_count, recent_posts. Display this alongside the note so the user understands who was found.

Args: query: Search query e.g. "ML engineer at Series B startup" location: Location filter e.g. "San Francisco Bay Area" limit: Max prospects to process (1-10, default 5) hiring_only: the profile BADGE (is_hiring), not post text. This tool opens every candidate's full profile anyway, so the badge is genuinely CONFIRMED here rather than guessed — the filter is applied after that fetch and costs nothing extra. Use it for "find me hiring managers to connect with". Default false (no filter). For "who POSTED about hiring", use search_posts_by_topic: different question, different people, and free. open_to_work_only: same, for the is_open_to_work BADGE. If both this and hiring_only are true, a candidate matching either badge is kept.

Responses:

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

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYes
locationYes
hiring_onlyNo
open_to_work_onlyNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.9/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: 10-40s synchronous path vs background job with job_id, notification by email on finish/pause, cost in actions (~11 for 5 people), and the critical safety fact that nothing sends until approve_draft and drafts persist indefinitely in pending_review. These are exactly the traits an agent can't infer from the 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?

Headings and front-loading are strong and the cost/behavior facts are placed where an agent needs them. It is longer than necessary in places, repeating the group-vs-named distinction and restating the action cost in two sections, which costs it the top score.

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?

There is no output schema, so return values must be in prose — and they are: up to 3 results inline, otherwise a job_id with drafts surfaced via list_drafts and get_job, plus the full profile field list to display next to the note. Nothing needed to call or interpret results is missing.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate and it does: query and location get example formats, limit gets its range and default, hiring_only is defined as the profile badge rather than post text with its application point (after profile fetch, no extra cost) and a pointer to search_posts_by_topic for the post-text question, and open_to_work_only's OR interaction with hiring_only is spelled out.

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?

Opens with specific verbs and resources ("Search for people, read their profiles, and generate connection note drafts") and then explicitly separates itself from find_person, find_prospects/search_prospects, search_posts_by_topic and run_outreach_pipeline. An agent can classify a request against this tool 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 an explicit decision rule (named person vs described group), worked example utterances for each branch, an explicit NEVER list for both directions, and a disambiguation protocol for the ambiguous case that says to ask one question rather than guess. This is about as complete as usage guidance gets.

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