Skip to main content
Glama
744,998 tools. Updated 2026-11-05 02:13

"Finding people on LinkedIn by name" matching MCP tools:

  • Look up a NUCC provider taxonomy code (the specialty codes used on HIPAA transactions + NPI registrations) or search by keyword. Returns classification + type + optional specialization. Source: NUCC Health Care Provider Taxonomy Code Set (public; CMS-accepted). WHEN TO USE: Resolving a NUCC provider taxonomy code to its specialty description. WHEN NOT: For finding a provider by specialty in a region (not yet implemented).
    ConnectorNo auth
  • Returns the plain-language meaning and step-by-step fix for one Malinois finding. Use it while helping the user fix an issue reported by scan_app, or when they ask what a finding means. Pass the rule_id exactly as scan_app returned it. Read-only, no network, instant.
    ConnectorNo auth
  • <summary>Attach a file from the user's library to a queued outreach email or LinkedIn message. Only attach when the user explicitly asks to attach a specific file to someone's message — never on your own initiative. attachment_id comes from list_attachments. Name the queued message by exactly one handle: recipient_email for a queued email (pending or awaiting approval); target_provider_id for a queued LinkedIn message, or target_identifier for one whose profile is still resolving — both as shown on the row in manage_linkedin_invite_queue's status read. On LinkedIn only messages carry files, not connection requests or InMails, and LinkedIn takes fewer file types than email; a file the channel can't send is refused with the reason. The same file can be attached to several messages.</summary> <returns> <description>The attached file's name and every file now on that message, shaped `{'attached': True, 'filename', 'attachments': [{'id', 'filename', 'mime_type', 'size'}]}`.</description> </returns>
    ConnectorOAuth
  • Change a play's own knobs — name, goal, voice — its two switches, and the ACCOUNT's pacing (daily action cap, working hours: shared by every play on the LinkedIn account, not per play). `paused: true` is the human's stop button (nothing runs, nothing is sent); `paused: false` resumes. `status: 'active'` LAUNCHES a draft; `status: 'draft'` takes it back off the road. Seat rule, enforced server-side: no live LinkedIn seat ⇒ neither launch nor resume makes it active — it stays/falls back to draft and the note says so. Launching or resuming kicks the play's due lanes at once. Only launch, resume or raise the cap when the human asked for it in this conversation: an active play spends the month's lead quota and acts from the human's own LinkedIn account. Does not touch the autonomy ladder.
    Connector
    Destructive
    No auth
  • Rahul's contact details (email, LinkedIn, portfolio), with an option to email him directly. Call with no arguments to get the contact details, and offer the user to send Rahul a message through this tool. Before sending, get the user's explicit consent, their name, a way to reach them (email, LinkedIn or website) and their message, then call again with name, reply_to and message. Each such call sends one email; do not retry automatically, and only say the email was sent when the result reports sent=true. Args: name: The sender's name. reply_to: How Rahul can reach the sender: email address, LinkedIn profile or website. message: The message or introduction to send Rahul.
    ConnectorNo auth
  • Apply a post-hoc triage verdict to a finding that was previously recorded via record_finding. Used by the /reply-to-code-review flow to persist whether a finding is TRUE / FALSE / UNCERTAIN and the FIX / DEFER / IGNORE action taken. The finding is located only by the exact `finding_id` returned by list_pr_findings, on ANY lifecycle status (open, fixed, or dismissed — so verdicts still apply after a PR is merged and findings were swept to dismissed). Only findings recorded into the data layer (the aictrl-dev MCP path) can receive a verdict. Idempotent: re-applying overwrites the prior verdict. A not_found response is an application error; call list_pr_findings to refresh stale IDs and do not treat the write as successful. `judged_at_sha` is required: send the full 40-hex commit SHA of the code you actually read. A SHA that is neither the review SHA nor a later commit of the same PR is rejected with validation_error. `reasoning` is required too (#5364): a verdict whose reasoning cannot be audited later is not worth storing. Each write appends to the finding's judgment history; a re-judge from the same run at the same commit updates that run's own row rather than appending a duplicate. A FALSE verdict on an OPEN finding of severity MINOR or NIT (medium/low/info) also dismisses it as a false positive, with your `reason` as the note; on MAJOR or BLOCKER (high/critical) it stays a suggestion a person confirms. The result reports `autoDismissed` (and `autoDismissReason` when false). A dismissal is not reopened by this tool; a person can restore the finding from the pull-request page.
    Connector
    Destructive
    API key

Matching MCP Servers

  • A
    license
    A
    quality
    A
    maintenance
    MCP server for the Mamba Labs People Finder & Email Verifier actor on Apify. Give it a company domain, name or LinkedIn URL and it returns the people at that company who match your role, seniority and department filters, each as a structured contact record with an optional verified business email.
    1
    65 npm
    MIT
  • 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
    29 PyPI
    59
    MIT

Matching MCP Connectors

  • PeopleOAuth

    Pessoas, histórico e anotações dos seus clientes

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

  • Sets up a monitor: a check Manifold repeats on a schedule, keeping each result so it can report what changed. Urgent changes reach the user as an email alert. Show the monthly cost from preview first, then create it once the user agrees. Give it a description saying why the user wants it, so an agent reading its changes later knows what to do with them. Use when: "monitor this every week", "keep an eye on X", "tell me when Y changes", "check Z every hour", or the user ran the same check by hand before and wants it repeated. Not for: a one-off look, call the tool itself (reddit_search_posts, seo_get_page, seo_get_position, ads_get_advertiser_ads). Reading what a monitor found, use monitoring_get_changes. Returns: Record. monitor (monitor_id, name, description, preset, status, cadence, fields, est_credits_check, est_credits_month, next_check_at), created (false on preview). The first check runs within five minutes and records a starting point; changes are reported from the second check on. Fields by preset: mentions {keywords (up to 10), platforms (reddit, linkedin, instagram, tiktok, youtube; default reddit), communities (Reddit, every new post read in full), pages (1 to 3 per community per check)}, where Instagram searches each keyword as one hashtag ("acme crm" reads #acmecrm), so use a keyword people tag; social_accounts {accounts [{platform (twitter, linkedin, instagram, tiktok, youtube, facebook), account (handle, or URL for facebook and linkedin)}] (1 to 10)}; reviews {items [{source app_store or google_play, app_id} or {source google_maps, place_id or cid} or {source google_shopping, product_id, gid}] (1 to 5), stars, location}; website_changes {pages (1 to 10 URLs), mode (new_items: new links under the page and prices; any_change: new text), words}; ads {brands (1 to 5, a website works best), platforms (facebook, google, linkedin, tiktok)}; google_rankings {site, keywords (1 to 50), location}; ai_visibility {brand, aliases (other names for the brand, up to 5), domain (the brand's site, for citation share), questions (1 to 25; ones that name the brand are counted apart), competitors (up to 9), engines, samples (1 to 3), location, language}. cadence is hourly, daily or weekly; checks repeat from the first one. A bad field is InvalidTarget naming it. Cost: 0 credits to create. Each check charges for the calls it makes at their own prices, shown as est_credits_check and est_credits_month. Monitor checks read live data, never the cache. Example: {"preset": "mentions", "fields": {"keywords": ["acme crm"], "platforms": ["reddit", "linkedin"]}, "description": "Threads asking for a CRM, to answer while they are fresh.", "preview": true}
    ConnectorAPI key
  • Find people on LinkedIn by keywords and filters. The right tool when you have a name, role, or 'who is the X at Y' question without a profile URL. Pass keywords (free text: name, title, or both) and any of first_name, last_name, title, school, current_company, past_company. If keywords is omitted it is derived from the name or title filters; school or company filters alone are rejected with INVALID_INPUT, so include keywords with those. Company filters accept a company name, slug, numeric id, or URN. current_company names are matched by LinkedIn's own company search: typo-tolerant and fuzzy, so results can include people whose headline merely mentions the company; when you need exact filtering, pass the numeric id or URN (linkedin_get_company returns both). past_company names are resolved to an id for you. Costs 10 credits including the first 10 results; each further 10 results add 1 credit (limit max 30; trial keys max 10). A cursor page is a NEW call priced the same way by its own limit, so one limit=30 call is much cheaper than three limit=10 pages; prefer a larger limit over paginating. Do NOT combine a past_company NAME or a company-URL filter with limit=30: resolving those spends one of the call's three internal fetches, so that combination is rejected; keep limit<=20 with them or pass the numeric id. current_company names never spend a fetch, so they combine with any limit. Returns name, position, location, urn, public_identifier per result, a cursor for the next page, and total_matches. Results with is_anonymous=true are private profiles; do not pass them to linkedin_get_profile. For one known person with a URL/slug, call linkedin_get_profile directly instead.
    ConnectorOAuth
  • Send a one-off LinkedIn message to a specific saved contact outside any campaign. Prefer contact_id; Salesbot resolves the LinkedIn identifier internally. A random delay, daily/hourly limits, allowed hours and human approval are enforced. Refused with code DUPLICATE_RECENT_MESSAGE (and the campaign name + date) when a campaign of this LinkedIn account already messaged the person within the last 30 days; to continue an existing conversation use reply_to_chat.
    ConnectorAPI key
  • Delete EVERY object of one type from the user's graph, however many there are: what to reach for when they ask to clear out a whole category ('delete all my HubSpot contacts') rather than one record. Pass import_id instead to delete everything one import added (its contacts, companies, notes and files, the uploaded file and the import itself); imports are graph objects of type 'import_run'. Pass source 'linkedin_import' instead to delete every connection a LinkedIn export loaded and the people made from them. Deleting one object is delete_graph_object instead. This delete is permanent, and at this scale it is the only kind that helps: a synced portal can be millions of records. Use only when the user explicitly asked for these to go, never on your own initiative, and name one type, import or source per call. In chat this tool deletes nothing: it counts the records and returns what to tell the user, and their click starts the deletion.
    Connector
    Destructive
    No 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.
    ConnectorAPI key
  • Triage a SHORT list of people for North Carolina (NC) court cases. Built for the "here is a list of names, which ones have cases?" question — a CSV of applicants, tenants, or bond clients. **This server cannot accept file uploads:** read the file yourself and pass the names as an array. Returns COUNTS AND FACETS PER NAME, not case detail — `matched`, `case_count`, `counties`, `case_types`, `case_numbers` (first few), `portal_truncated`. That keeps a 5-name response readable. Once you know which names are interesting, call `search_cases_by_party` (full rows) or `lookup_court_case` (one case) on those. LIMITS, and why they are low: each name runs a LIVE portal search, and the upstream session token is shared by every user of this service — a wide fan-out risks blocking it for everyone. Max 5 names per call, 3 at a time. Split a longer list across calls. SLOW BY NATURE: measured ~60s for 3 names and ~2 minutes for 5. Tell the user you're checking and roughly how long it takes; don't retry on a slow response, and don't treat the wait as an error. If your client's timeout is tight, send fewer names. PARTIAL RESULTS ARE NORMAL: one name failing (portal hiccup, timeout) does not fail the batch — that entry comes back with an `error` and the rest still return. Report which names were checked and which weren't; never present a failed name as "no cases found", because those mean completely different things. `portal_truncated: true` on a name means the portal hit its statewide 200-case cap, so that person's count is a LOWER BOUND — narrow with `county`, `case_status`, or a filed date range and re-run that name. Dates: ISO `YYYY-MM-DD` or `MM/DD/YYYY` — both accepted. `file_date_*` bounds when the case was FILED, not when a hearing is scheduled. Matching is exact on last + first name (no soundex here — it broadens results and would make a screening list noisier). A common name will match multiple different people; `case_count` is "cases matching this name", NOT "cases belonging to one person". There is no DOB or identity confirmation in this tool — do not treat a hit as identifying a specific individual. Read-only. NC only. Public records. Informational, not legal advice.
    ConnectorNo auth
  • Look up one taxpayer by exact tax id, to confirm who it is. Use it to check a recipient's name before issuing against them. It takes the id exactly — punctuation is fine, but there is no search by name, by prefix or by state, and there will not be: the registry holds the names and addresses of real people. A 404 does not mean the company does not exist. The registry reloads monthly from the RFB's dump, so a recently registered CNPJ is simply not in it yet. Say that to the user rather than reporting the tax id as invalid, and never turn a 404 here into a validation rule.
    ConnectorNo auth
  • <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; loading a post Sliq hasn't tracked yet counts one against the user's daily LinkedIn post-read budget. 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 person who engaged is saved as an `agent_search_results` person row, rendered in the agent's Output tab and queryable via `query_search_results`: `data.person` carries the name and headline, `linkedin_provider_id` and `linkedin_url` the LinkedIn handles, and `data.columns` the engagement (Engagement, Comment, Post, Post URL). Company pages that reacted or commented aren't people, and the user isn't a lead, so neither is saved; both stay in the engagement rows. Re-running updates existing rows rather than duplicating them. Pass `list_name` to name their list; absent, they land in the 'default' list. Each person new to the list is checked against `criteria`, one at a time, reading their headline and engagement, and saved with the verdict; the rejected ones are hidden from the list's default view and from `query_search_results`. The check adds about 20 seconds per hundred people. To keep everyone who engaged, write broad criteria, such as "Anyone who engaged with this post". A person already on the list keeps their verdict, so to screen a post's engagers against new criteria, pass a new `list_name`. After this returns, read the saved people with the `query_search_results` call in `next_step`, which is scoped to this post: one list can hold several posts' engagers. Judge anyone the check kept as `unclear` or left without a verdict yourself, then queue outreach for the people who fit with one batched `queue_linkedin_outreach` call passing each row's `linkedin_provider_id` as `provider_id` and its `linkedin_url` as `linkedin_url`. Send-time resolution skips anyone already connected, so they don't need pre-filtering here. Every engager, the rejected ones included, also stays queryable with `query_linkedin_post_engagements` using `post_id = <post_analytics_id>`.</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 engagers, unchecked], 'next_step': str, 'list'?: {'list_name', 'created', 'updated', 'total', 'rejected'}}. `unique_engagers` counts company pages too; `list.total` counts only the people saved, rejected ones included, so it can be lower. `list.created` and `list.updated` count the people the list shows, and `list.rejected` the ones the check turned down. `budget` is today's LinkedIn post-read budget. On failure, {'success': False, 'error': str} when the post isn't visible to the user's account, the daily LinkedIn post-read budget is spent, or LinkedIn actions are paused after a rate limit.</description> </returns>
    ConnectorOAuth
  • <summary>Add and/or remove watched people or company pages on an existing `list`-mode LinkedIn monitor, incrementally — you pass only the profiles that are changing, never the whole list. `add` and `remove` are LinkedIn profile URLs or vanity slugs for people, and full `linkedin.com/company/...` URLs for company pages (a bare company name or slug is read as a person's slug). A swap is one call (`add=[new]`, `remove=[old]`). Both forms of one profile (full URL and bare slug) collapse to a single watched member, so re-adding someone already watched is a no-op. The change takes effect on the monitor's next scheduled run. Use this instead of re-running `set_up_linkedin_monitoring` whenever the user just wants to tweak who's watched ("also watch Bob", "drop Alice"): setup would force re-passing every existing member, and since each watched profile is billed per run, one dropped URL on the re-echo silently stops watching that person. To change schedule, voice, or the action flags, use `set_up_linkedin_monitoring` (members are preserved there when omitted); adding the very first members or resetting the whole list is setup too.</summary> <returns> <description>Dict with status ('active'), name, members_count, added, removed, unresolved, and message.</description> </returns>
    ConnectorOAuth
  • SPENDS CREDITS, AND BY DEFAULT METERED EMAIL VERIFICATION. Adds people from the Lead Finder contact database to a campaign as leads, revealing their contact details, in the background. Pass refs (from search_lead_finder results; up to 1,000 different people by default) to add exactly those people, or pass filters and count (1 to 5,000 by default) to add count people matching the filters who are not in the workspace yet. A filters add always walks the matches from the top and skips anyone already a lead, free and not counted, so repeating the same add adds the NEXT count people and charges again. Never repeat an add to retry: after an error or a timeout, call list_lead_finder_imports to see whether it started. A filters add stops early when the audience runs out or once it has looked at five people for every one requested (at least 1,000). People already added count toward that limit even though skipping them is free, so after an add of more than about 1,000 people a small follow-up can stop with nobody added. Every person a filters add looks at, added or skipped, also uses the account's daily allowance for filters adds (25,000 people by default). Each person added costs 1 credit ($0.033 at list), reported as creditsPerProspect; the response reports estimatedCredits, the most the add can cost in credits, and the wallet must hold that much for it to start. People already in the workspace, blocklisted, without a usable address, on a personal mailbox when the campaign only takes business addresses, or marked invalid by verification are skipped and cost no credits. verifyEmails (on by default) checks every screened address with the paid email verification waterfall, including the ones it marks invalid: one or two checks per address, billed as metered usage on the next invoice (price per check: GET /email-verification/rates in the REST API), within the account's monthly verification spend limit. Catch-all and unconfirmed addresses are added and charged, and so is every address once that limit is reached; verification.limitReached and verification.unknown on get_lead_finder_import count them. Leads added to a running or paused campaign get their emails at once (a paused campaign sends them when resumed); adding to a completed campaign resumes it, so it starts sending again; in a draft campaign the emails are created at launch. At most 3 adds run at once in a workspace. A refusal names its reason, and a 429 also says when to retry (reason running_imports, daily_import_limit, daily_budget, monthly_budget or fair_use_floor). Poll get_lead_finder_import with the importId until finishedAt is set. Check get_credit_balance first; buy credits with purchase_credits.
    ConnectorNo auth
  • Merge a duplicate CRM company into another one (e.g. 'Škoda JS' into 'Škoda Group'). All people move to keep_crm_company_id, empty details are filled from the duplicate, account notes are joined, the duplicate's name is remembered as an alias so future leads with that name land in the kept company, and the duplicate is deleted. Cannot be undone — only merge when both records are clearly the same organisation (check with get_crm_company), and confirm with the user when unsure. Prefer keeping the company imported from LinkedIn.
    Connector
    Destructive
    API key
  • Re-check a fix without a full scan. With opportunity_id, re-checks an inbox readiness task; the result updates the task. With check_id, re-checks that open finding on its affected pages. Returns pending with the re-check's id; follow it with get_operation or get_readiness_finding's check_request_id. Cost: by opportunity_id free, once every 10 minutes; by check_id one of the plan's monthly re-checks.
    ConnectorOAuth
  • Search the user's Google Contacts (saved contacts + Google's auto-collected "other contacts") across all connected Google accounts, by name (or partial name/email). Returns each match's name, primary email, full email list (for people with several addresses), and source ('contact' = saved, 'other' = auto-collected). Use this to resolve a person's NAME to an email address before composing/sending a message — on 0 matches, fall back to searching past message history or ask the user directly; on multiple matches, ask the user which one before proceeding. Accounts without the contacts scope are skipped and reported in `errors` with a reconnect hint. Call list_accounts to learn account labels. Read-only — no contact writes.
    ConnectorOAuth
  • People matching title, seniority and company filters. No email. Use when: "find heads of marketing at fintech startups", building a target list by role, prospecting by ICP. Not for: someone to email at a specific website about a link, use leads_get_domain_emails (keyed by domain). One person's full record, use leads_get_person. An email for a named person, use leads_get_email. Returns: List. rows[]: id (the LinkedIn profile URL; null when the person has no profile, so look them up by name and domain), first_name, last_name, headline, title, title_start (YYYY-MM, so time in the role), company, company_domain, company_id, company_linkedin_url, company_employees, company_industry, location, linkedin_url. rows_available is the provider's total. Give at least one of titles, seniority, company_domains, industries, locations or keywords. A page holds at most 100 rows whatever the limit; page on with meta.cursor. Cost: 12 credits per 100 rows asked for (limit), rounded up. Default 12 credits. Cached 7 days. Example: {"titles": ["head of marketing"], "industries": ["fintech"], "locations": ["London"], "limit": 50}
    ConnectorAPI key
  • TikTok videos matching a keyword, ranked by the platform's own search. Use when: "what is TikTok saying about X", finding creators in a category, watching a product or a brand name. Not for: one account's own videos, use tiktok_get_videos. A complete window of everything posted (TikTok search is ranked and never complete). Returns: List, ranked. rows[]: videos with author and author_followers, created_at, text (cut at 2000 characters), likes, comments, shares, saves, views, media, duration_s, links, transcript and top_comments[]. saves is how many people saved it, music the sound, and author_followers sizes each creator without another call. null or empty = the platform does not publish it. Cost: 1 credit per page. Cached 6 hours. Example: {"query": "creatine gummies", "since": "month", "sort": "popular"}
    ConnectorAPI key