Skip to main content
Glama
605,358 tools. Updated 2026-09-24 00:06

"Finding people on LinkedIn using their names" matching MCP tools:

  • Enrich existing contacts with their full LinkedIn profile data via the connected LinkedIn account (Unipile) — headline, location, current company & position, full experience, education and skills are scraped from each contact's profile URL and saved onto the contact (and merged into profile_data). Use after search_google_xray to flesh out lightly-saved leads. Each contact is a real LinkedIn profile view, so keep batches small; max 8 per call. Returns per-contact enrichment status.
    ConnectorNo auth
  • <summary>Search LinkedIn for people — by name, by a specific person's connections, or by profile filters — and return the matching profiles. Provide `keywords` (a name or search term) or a scope filter (`connections_of` / `advanced_keywords`). One call runs one query, returning ~10 matches by default (one page). To go deeper on a single query — "find people in my network matching my ICP" — pass `max_results` (up to 100): the tool pages through the matches for you, each ~10-profile page counting as one search against the daily budget. To search *different* people — a list of names, or one filter per company — loop this tool inside a `run_code` block, one call per name or company (that's breadth; `max_results` is depth on one query). Searches are paced a few seconds apart and serialized across this user's LinkedIn work, so a deep search or a long loop can take a couple of minutes; tell the user to expect a short wait before a large run. If a search comes back paused or rate-limited, stop and tell the user which searches remain — the account is paused and further calls won't run until it lifts. Scope filters combine with `keywords` and can be used alone for a single filtered search: - `connections_of` — restrict to the first-degree connections of specific people, passed as their `provider_id`s (as returned by an earlier search or profile lookup). To work up to a buyer through someone the user just connected with, pass that person in `connections_of` and the target company in `advanced_keywords={'company': 'Acme Corp'}` to surface who they know there. `network_distance` is a separate filter on the user's *own* degree and combines with this — add [2] to keep just the connections the user isn't already directly linked to. - `advanced_keywords` — native LinkedIn keyword sub-filters: a dict with any of `first_name`, `last_name`, `title`, `company`, `school` (each a string). - `profile_language` — ISO 639-1 codes (e.g. ['en']) that narrow any of the above to profiles written in those languages. A refinement, not a search on its own — pair it with keywords or another filter. When this runs in an agent, the matches are saved and linked to the workspace Output tab automatically (deduped by profile). Pass `list_name` (a short slug) to name their list — a discovery search, the people connected to someone, prospects to work through; reuse the same slug across a loop or follow-up searches to gather everything into one list. Absent a slug, matches land in the 'default' list. Outside an agent, results are returned only. Returns up to `max_results` matching profiles with provider_id, name, headline, network_distance, location, and profile_url — each match's `headline` shows their current role and company (e.g. to see which companies 2nd-degree matches work at). `total_count` is LinkedIn's full match count for the query when it returns one, but LinkedIn now omits it on most Classic searches (so it's often null): only say "showing N of ~M" when it's a number exceeding the profiles returned, and never invent a total. Use `has_more` — True when more results exist beyond those returned — to decide whether to offer to pull more. Present the results to the user so they can pick the right person. An `error` about being "heavily queued" is transient pacing back-pressure — retry shortly rather than reporting it as not found. That field list is the whole of it — a search result carries no connection count, follower count, or employment history. Present what comes back as it is; a search the user wanted to look at is finished at that point. When the ask genuinely needs one of the missing fields — a connection-count threshold, employment history to personalize from — pass the matches' profile URLs to `enrich_linkedin_profiles`, which returns them for the whole list in one paid call (`connections_count` is the field a connection-count filter reads) and spends no LinkedIn account budget. When the decision also turns on whether the user is already connected to them, use `setup_linkedin_sequence(action_type='resolve')` instead; connection status is the one thing enrichment cannot answer. Rate-limited — shares one daily LinkedIn search budget with all other LinkedIn people searches.</summary> <returns> <description>On success, a dict `{'success': True, 'profiles': [...], 'total_count': int | None, 'has_more': bool, 'searches_remaining_today': int}`. `profiles` holds up to `max_results` matches; `total_count` is the query's full match count when LinkedIn returns one (often null since its Aug-2026 Classic Search change), so lean on `has_more` for whether more results exist; and `searches_remaining_today` is the post-search budget, so you can size a follow-up loop without re-checking. In an agent, also `saved_to_list` (the list the matches were saved to) and `saved_count`; outside an agent, a passed `list_name` yields a null `saved_to_list` with a `persist_note`. If the account tripped its pause partway through paging, the (still valid) partial results come back with `paused: True` and a `note` — surface it: further searches won't run until the pause lifts. On a failed search: `{'success': False, 'profiles': [], 'error': ..., 'searches_remaining_today': int}`. On a pre-flight refusal (daily limit reached or account paused), `searches_remaining_today` is omitted: `{'success': False, 'error': ...}`.</description> </returns>
    ConnectorOAuth
  • Get available criteria and their supported values (names and IDs) for target group creation/updates. USE FOR: "what targeting criteria are available?", "what options for [criteria type]?", "supported values for industries/seniority/job functions", "how to search job titles/interests/member groups?", validate criteria before creating target group, get valid IDs for create_target_group. CRITERIA TYPES: 1. LIST-BASED (returns predefined options): - age-ranges: Age range options - company-categories: Company classifications - company-growth-rates: Growth rate ranges - revenues: Revenue ranges - employees: Employee count ranges - industry-taxonomy: Industry codes/names - jobFunctions: Job function categories - seniority: Seniority levels - followed-companies: Company follow options - locations: Geographic data (MANDATORY as FIRST criteria for LinkedIn) - use search_terms for filtering 2. SEARCH-BASED (use search_terms): - job-title: Search job titles (reference_type: LINKEDIN_JOB_TITLES) - member-groups: Search LinkedIn groups (reference_type: LINKEDIN_MEMBER_GROUPS) - member-skills: Search professional skills - interests: Search interests (reference_type: LINKEDIN_INTERESTS) - traits: Search behaviors (reference_type: LINKEDIN_TRAITS) 3. NUMERIC: years-of-experience (0-12, not retrieved via this tool) OPERATION MODES: - List: search_target_group_criteria(channel="LINKEDIN", criteria_type="seniority") - Search: search_target_group_criteria(channel="LINKEDIN", criteria_type="job-title", search_terms=["engineer"], exact_match=false) - Direct: search_target_group_criteria(channel="LINKEDIN", reference_type="LINKEDIN_JOB_TITLES", search_terms=["engineer"]) RESPONSE: Array of {externalId, name}. Use externalId in target group config, show name to users. CHANNEL: Only LINKEDIN supported.
    ConnectorAPI key
  • Make a LinkedIn or Google account the user already connected available in another of their workspaces, so that workspace can send from it. Call this after campaignstack_create_workspace when the user wants the new workspace to run on an account they already use elsewhere; read the accountId from campaignstack_list_accounts on a workspace that has it. The first LinkedIn account linked becomes the workspace's default sender. Nothing is sent and nothing is re-authenticated. The account must be the user's own and they must belong to the target workspace. Free accounts have an identity cap per workspace; the error says so when it bites. To connect a NEW account use campaignstack_request_connect_link.
    ConnectorAPI key
  • Search LinkedIn people. RECOMMENDED FOR PROSPECTING: set decisionMakers:true, provide company, departments and limit 20-30. Salesbot resolves the company, performs ONE company-scoped provider search (Sales Navigator also applies seniority), then ranks the returned senior employees locally by department. This is broader and safer than retrying exact titles. Use title/titles only when an exact role is required. EXISTING CONNECTIONS reads only the local cache and consumes zero search quota. The workspace setting selects Standard/Classic or Sales Navigator automatically. Respect retry_after; never immediately retry a protected or timed-out request. On LINKEDIN_PROVIDER_TIMEOUT use search_google_xray, then retry LinkedIn only after the stated delay.
    ConnectorNo auth
  • List multi-step email sequences and how many people are currently in each, with the id each one is enrolled by. Newest first, at most 100 per call; while has_more is true, next_cursor passed back as cursor returns the next page. A 'paused' automation holds its people on their current step rather than ending their sequence: they stay 'active' and continue from that step once it is active again. list_automation_enrollments lists who is on one, and who left and why.
    ConnectorNo auth

Matching MCP Servers

  • A
    license
    A
    quality
    A
    maintenance
    Local-first memory for AI agents about the people in your life. MCP server + CLI on SQLite. Never phones home.
    41
    55
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Open MCP server for AI agents to discover people, jobs, collaborators and projects through semantic search over human-published context.
    MIT

Matching MCP Connectors

  • LinkedIn: The LinkedIn Data API offers access to detailed information on individuals, companies.

  • LinkedIn data for AI agents: search, profiles, companies, posts. Free key, self-minted, no signup.

  • Read a company's LinkedIn People page on one of the workspace's connected accounts (up to 1000 profiles, LinkedIn's own display ceiling; optionally filtered by job titles). Call this when the user asks who works at a company, or wants a company's people turned into leads. Employees land as shared leads tied to the company - re-running updates them, never duplicates. They are NOT added to any lead list; read them with campaignstack_list_company_employees and act with campaignstack_add_leads_to_list. The job runs in the background; one extraction per company at a time. Use campaignstack_list_companies to find company IDs.
    ConnectorAPI key
  • Turn a LinkedIn account's connection watcher, message watcher or own-posts watcher on or off. The first enable creates the agent and its template workflow (welcome messages, reply drafts or engager follow-ups, review-first); later calls resume or pause it. The own-posts watcher finds the account's new posts on LinkedIn every hour, published through CampaignStack or not, and tracks who reacts and comments. Call this when the user names an account and kind to turn on or off; say both before calling, since enabling starts drafting outbound the workspace did not have before. One watcher per kind per account across all workspaces (DUPLICATE_*_EXTERNAL otherwise); needs a live session (AGENT_ACCOUNT_UNAVAILABLE otherwise). Not for other targets: campaignstack_create_signal_agent covers those.
    ConnectorAPI key
  • Search a global professional database in plain English (for example 'Heads of Marketing at Series B SaaS in New York') and get a sample of matching people plus the true total match count. 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 validate that the right people exist before you pay. To get a person's real name, LinkedIn and verified email, pass their token to reveal_profile, or use find_people to unlock a batch in one call.
    ConnectorNo auth
  • Synchronize one provider-safe page (at most 500) of the API-key owner's 1st-degree LinkedIn relations into the local workspace cache. This is a provider read, not a LinkedIn people search, and does not consume the search quota. The server persists continuation state and atomically enforces a 15–20 minute delay, four-page hourly cap, and twelve-page daily cap across UI and MCP. Respect RELATIONS_SYNC_PROTECTED retry_after_seconds before continuing.
    ConnectorNo auth
  • <summary>Check LinkedIn usage limits and invite queue counts. Call this before sending multiple LinkedIn messages, InMails, or connection requests to get a fresh read of today's headroom (limits, remaining, ramp-up) plus the current queue counts — re-call it after queueing or approving sends, which leave the in-context figures out of date. For the per-contact queue (names, scheduled times, messages), use manage_linkedin_invite_queue with action='status'.</summary> <returns> <description>Dict with usage counts, limits, queue counts, and `configurable_limits` — per action the standard `default`, the tier-aware `ceiling` (the max the user can raise it to), and the user's current `custom` cap (None = using the default). Quote `ceiling` when the user asks how high they can set a cap.</description> </returns>
    ConnectorOAuth
  • <summary>Find phone numbers for one or more people from their LinkedIn URLs, via Airscale. Pass a list of LinkedIn profile URLs — one entry for a single person, all of them at once for a batch (they are looked up in parallel, costing one tool call against the loop guard, not N). Returns one result per URL in the same order. Airscale brokers providers like RocketReach. Persists nothing — use the returned numbers however the agent needs them (e.g. tell the user, or stash them on prospects via `update_prospect`). A LinkedIn profile URL is the only accepted input — this tool cannot look a person up by email or name. When a record (a HubSpot/CRM contact, a prospect row, a spreadsheet line) has no LinkedIn URL but does have the person's email, first call `find_linkedin_url(email=...)` to resolve one, then pass that URL here. Apply this resolve-then-lookup step to every record, not just the first; skip the phone lookup for any person you cannot get a URL for. Costs 8 Sliq credits per number found, when run on Sliq's shared Airscale account. Misses (no number on file) and upstream failures are free. A worst-case check runs up front on the Sliq path: the whole batch is refused unless the balance covers 8 credits per URL (any URL *could* be a hit). So no API call is ever spent on a lookup that can't be billed, and a user low on credits is told to top up or connect their own key. If the user has connected their own Airscale key (BYO, via the integrations page), lookups run against that account instead — no Sliq credit gate and no Sliq credit charge.</summary> <returns> <description>A list of result dicts in input order. Per hit: `{status: 'success', found: True, phone_number, phone_numbers, provider, linkedin_url, credits_charged: 8}` (0 on the BYO path) — `phone_number` is the first number, `phone_numbers` the full list. Per miss: `{..., found: False, phone_number: None, phone_numbers: [], credits_charged: 0}`. A malformed (non-LinkedIn) URL or an upstream failure on one URL becomes a per-item `{found: False, error, credits_charged: 0}` in that slot — it never aborts the rest of the batch. If the up-front worst-case credit check fails, it raises `InsufficientCreditsError` (no lookups are attempted).</description> </returns>
    ConnectorOAuth
  • Update the LinkedIn channel settings of an existing DRAFT wizard campaign: native objective, bidding optimization goal (including Reach), bid strategy with manual bid amount, and the LinkedIn conversion actions the campaign optimizes toward. These are the settings the platform UI shows in the LinkedIn channel drawer of the campaign draft page (Native Objective, Bidding Optimization Goal, Bid, Conversion Actions). The campaign MUST already have its LinkedIn channel enabled (via create_campaign / add_and_edit_campaign_elements with a `linkedin` block). WARNING: DRAFT-ONLY: the platform rejects these edits once the campaign is Launching/Launched. KEYWORDS: linkedin, linkedin campaign, linkedin settings, campaign settings, draft campaign, objective, native objective, brand awareness, website visits, engagement, video views, bidding optimization goal, optimization goal, reach, impressions, landing page clicks, engagement clicks, bid, bid strategy, auto bid, manual bid, maximum delivery, conversion, conversions, conversion actions, conversion tracking, insight tag, settings WHEN TO USE: - Set the LinkedIn native objective (e.g. Brand Awareness instead of the default Engagement) - Optimize a Brand Awareness campaign for REACH instead of IMPRESSIONS - Switch between auto bid (LinkedIn maximum delivery) and a manual bid - Pick which LinkedIn conversion actions the campaign optimizes toward and reports on PARAMETERS (campaign_id required; everything else optional, and an unspecified setting keeps its current value on the channel): - campaign_id: the wizard campaign ID - objective: BRAND_AWARENESS | WEBSITE_VISIT | ENGAGEMENT | VIDEO_VIEW, the LinkedIn native objective. Only selectable on Brand Awareness (CTR) campaigns: a Lead Gen (CPL) campaign derives it from its offer at launch (lead-gen form -> LEAD_GENERATION, landing page -> WEBSITE_CONVERSION). The platform default for a new LinkedIn channel is ENGAGEMENT. Every ad already on the channel must be supported by the objective (VIDEO_VIEW is video-only, MESSAGE ads only fit WEBSITE_VISIT, DOCUMENT ads lock the objective, a video-only channel accepts only ENGAGEMENT or VIDEO_VIEW). A channel holding CTV ads is always Brand Awareness / Reach at launch and cannot be changed here. Changing the objective also resets the cost type and the bidding optimization goal to the objective's default (BRAND_AWARENESS -> IMPRESSIONS, WEBSITE_VISIT -> LANDING_PAGE_CLICKS, ENGAGEMENT -> ENGAGEMENT_CLICKS, VIDEO_VIEW -> VIDEO_VIEWS), so pass bidding_optimization_goal in the same call when you want something else. - bidding_optimization_goal: what LinkedIn optimizes delivery for. Allowed per objective: BRAND_AWARENESS -> IMPRESSIONS | REACH; WEBSITE_VISIT -> LANDING_PAGE_CLICKS | IMPRESSIONS; ENGAGEMENT -> ENGAGEMENT_CLICKS | IMPRESSIONS; VIDEO_VIEW -> VIDEO_VIEWS | IMPRESSIONS. Conversation and Message ads are always IMPRESSIONS. CTR campaigns only. - bid_strategy: AUTO_BID (LinkedIn "maximum delivery", what the campaign builder applies by default) or MANUAL_BID (needs bid_amount). CTV ads REQUIRE AUTO_BID; Spotlight and Text ads REQUIRE MANUAL_BID. - bid_amount: manual bid in the account currency, used only with MANUAL_BID. - conversion_action_ids: ids of LinkedIn conversion actions (from list_linkedin_conversions) the campaign should optimize toward and count as conversions: website visits, URL-rule page views, lead form fills. REPLACES the current selection; pass [] to clear it (the campaign then falls back to the account's default Insight Tag URL match). Every id must exist and be enabled on the connected LinkedIn account, or launch validation fails. NOTE: the platform UI only shows this picker for campaigns with landing-page offers and an objective other than Brand Awareness; ids stored outside that case are still sent to LinkedIn at launch, but that path is not exercised by the UI. NOT SETTABLE ANYWHERE IN THE PLATFORM (say so instead of promising them): LinkedIn Audience Network on/off and its category exclusions, audience expansion (campaigns always launch with expansion OFF), frequency caps, Thought Leader ads. LinkedIn geo targeting is not a channel setting either: it lives on the audience / target group. EXAMPLES: Brand Awareness optimized for Reach on auto bid: update_linkedin_channel_settings({"campaign_id": 12345, "objective": "BRAND_AWARENESS", "bidding_optimization_goal": "REACH", "bid_strategy": "AUTO_BID"}) Track two conversion actions on a Website Visits campaign: update_linkedin_channel_settings({"campaign_id": 12345, "conversion_action_ids": ["123456", "234567"]}) RESPONSE: {success, campaign_id, channel_id, campaign_status, campaign_goal, channel_ad_types, applied:{...}, errors?}. `applied` echoes exactly what was pushed to the platform. INTEGRATION WITH OTHER TOOLS: - list_linkedin_conversions lists the conversion actions available on the account - search_campaigns_by_names / get_campaign_by_wizard_id to find the campaign - The LinkedIn channel is enabled by create_campaign or add_and_edit_campaign_elements - check_campaign_launch_readiness validates the result before launch
    Connector
    Destructive
    API key
  • Check whether LinkedIn Ads is connected to this AdPlug account. IMPORTANT: Call this tool FIRST before using any other tools on this server. If LinkedIn Ads is not connected, surface the action_required steps so the user can connect it before you attempt platform-specific operations. Also reports write_access (read_write or read_only). read_only ('View only' in the dashboard) is a team setting: write tools are hidden and any write call is rejected, so do not attempt changes.
    ConnectorOAuth
  • A link the user clicks to connect a NEW LinkedIn or Google account. Connecting is a browser step by design: LinkedIn needs a session the extension captures, Google needs its consent screen, and neither a cookie nor a password should ever be pasted into a chat. For LinkedIn the link is the accounts page (with the extension the connect is one click; without it, an email and password or a session cookie entered on that page). For Google the link is a consent URL minted for this user, valid ten minutes. Send the link, then poll campaignstack_list_accounts until the account appears, and link it to the right workspace with campaignstack_link_account_to_workspace if it is not there already. Never ask the user for their credentials.
    ConnectorAPI key
  • Composite snapshot of a specific user's activity on a project. Returns an identity block (visitorId, userEmail, userName, firstSeen, lastSeen), total pageviews, total custom events, session count, top pages this user visited, their most-fired event names, and their 20 most recent events with props. Use this for 'how is dancleary54@gmail.com using my app?' style questions — one call, full picture. For ad-hoc drill-down (just a count, just recent events) pass `user` to the individual tools instead. Default window is the last 7 days.
    ConnectorNo auth
  • General-purpose Google search — returns organic results for any query. Unlike search_google_xray (LinkedIn-only), this searches the entire web. Useful for finding job postings on portals (jobs.cz, prace.cz, profesia.sk, indeed.com), company info, news, or any other web content. Results are NOT saved to contacts — use this for research and discovery. Capped at 4 calls per minute to protect the Serper/Google budget.
    ConnectorNo auth
  • Creates a Zeekeo LinkedIn campaign: sends a connection invite using invite_template_id, and optionally — if followup_template_id is given — waits for the invite to be accepted, then sends a follow-up message using that template. Create templates first with zeekeo_create_template. Provide exactly one of filter_url (a LinkedIn search results URL) or profile_urls (specific profiles) as the target. This starts REAL LinkedIn automation once the campaign has profiles in it — confirm with the user before calling. Requires the user to have connected their own Zeekeo Launchpad account. Direct them to rankparse.com/dashboard/integrations to connect it.
    ConnectorNo auth
  • Search leads in a workspace by name, email, LinkedIn URL or company. Returns paginated results; follow nextCursor for the next page. Omit query and companyId to page through every lead. Covers both shared leads and workspace-private (CSV-imported) ones. Platform presence (LinkedIn URL, follower counts, and so on) is under each lead's `profiles` key (e.g. profiles.linkedin.url); the top-level linkedInUrl is a legacy alias. Use returned leadId values with campaignstack_get_lead or campaignstack_add_leads_to_list. Call this when the user names a person, company, or LinkedIn URL to find. It does not return ICP fit or job positions: campaignstack_get_lead does, once you have a leadId. Results are one page. When pagination reports more, say so rather than presenting the page as the whole set, and page through before counting anything.
    ConnectorAPI key
  • Get a company by ID. Accepts a shared (global) company id or an imported workspace-scoped company id; the response's companySource field says which one matched. Returns industry, employee range, and contact info. Platform presence (LinkedIn URL, follower/staff counts, tagline) is under the `profiles` key (e.g. profiles.linkedin.url); top-level LinkedIn fields are legacy aliases. The `watch` key carries the workspace's intelligence post watch on this company (id, status, post count) when one exists. The `siteFacts` key carries what the company's own website says (who it sells to, whether pricing is public, product stage), read from the pages we track; a null field means we could not tell, not no. Its `tech` list names the technologies their pages state they run, read by code; what is missing there was not seen, which is not the same as not used. Call this when the user names one company and asks about it, or before editing it. It does not list which leads work there, campaignstack_search_leads does. If the company is not found, use campaignstack_list_companies to find valid company IDs.
    ConnectorAPI key
  • <summary>Fetch the people who reacted to or commented on a LinkedIn post — the user's own post or anyone else's — and store them as queryable engagement rows. Use when the user wants to turn a post's engagers into leads ("everyone who liked this post", "who commented on her launch post"). Visibility follows the user's LinkedIn account: any post it can view works, and private or deleted posts return a plain error. The list is capped at 500 reactions + 500 comments per post; on a bigger post the return flags the cut-off. Data fetched within the last 6 hours is served from the database at no cost; a real fetch counts one action against the shared daily engagement-fetch budget and paces its LinkedIn requests, so a post with hundreds of engagers takes around half a minute — set that expectation with the user before calling this on a big post. When this runs in an agent, every engager is materialized as a reviewable `agent_search_results` row (entity_type='person', data carries headline, reaction_value, comment_text, provider_id, source_post_url), rendered in the agent's Output tab and queryable via `query_search_results`. Re-running updates existing rows rather than duplicating them. Pass `list_name` to name their list; absent, they land in the 'default' list. By default the full unfiltered list materializes — to act on only a subset (ICP fit, founders only, a specific role), qualify the stored rows first (headline triage via query_linkedin_post_engagements) and queue outreach on just the keepers. After this returns, filter and slice the full list with `query_linkedin_post_engagements` using `post_id = <post_analytics_id>`, then queue outreach with one batched `setup_linkedin_sequence` call passing each person's `provider_id`. Send-time resolution skips anyone already connected, so they don't need pre-filtering here.</summary> <returns> <description>On success, a dict {'success': True, 'post_analytics_id': int, 'author_name': str, 'is_own_post': bool, 'post_text_snippet': str, 'from_cache': bool, 'reactions_stored': int, 'comments_stored': int, 'unique_engagers': int, 'truncated': bool, 'budget': {'used_today': int, 'limit': int}, 'engagers_preview': [first 10 people], 'next_step': str, 'list'?: {'list_name', 'created', 'updated', 'total'}}. On failure, {'success': False, 'error': str} when the post isn't visible to the user's account, the daily budget is exhausted, or LinkedIn actions are paused after a rate limit.</description> </returns>
    ConnectorOAuth