LinkedIn MCP server for Claude: what they are, which need your session cookie, and how to run outreach

Search linkedin mcp server and the top result is an open-source GitHub repo with roughly 2,900 stars: stickerdaniel's server, the one most developers wire into Claude first. It works. But the moment you connect it, it wants your live LinkedIn session cookie, and from then on every one of its tools, from a single profile lookup to a connection request, runs as you, from your machine. Ask Claude to find two hundred heads of RevOps and start connecting, and it will try, on your account, at a cadence no human types at. That is the detail the search results bury: the question is not what these servers can do, it is what they do to your account the second you plug them in.

So this is the developer's version of the answer. First, what a LinkedIn MCP server is and why Claude specifically makes it useful. Then the piece the SERP skips: a table of the servers that exist and which ones need your live session cookie to do anything. Then a worked transcript of running real prospecting, find to qualify to draft to approve, inside Claude, on a server built so that the finding and drafting never touch a cookie at all.

What a LinkedIn MCP server actually is

MCP, the Model Context Protocol, is the open protocol Anthropic introduced in late 2024 to let an AI model call external tools through a standard interface. An MCP server exposes a set of typed tools, an MCP client like Claude discovers them, and the model can then call them mid-conversation. Think of it as a shared socket between the model and whatever the server can do.

A LinkedIn MCP server, then, is any MCP server whose tools reach LinkedIn data or actions. Ask Claude "find me heads of RevOps at Series B SaaS companies" and, with a LinkedIn MCP server connected, the model can actually go do it and hand back structured results instead of guessing. The appeal is obvious. The catch is that "reach LinkedIn data" hides an enormous range of how, and the how is where your account risk lives.

The LinkedIn MCP servers that exist, and which need your session cookie

Here is the single most useful thing to know before you install any of them. The servers on the SERP split cleanly by one question: what do you have to hand the server, and when does your own account get exposed. This is the table to read twice.

The open-source repos are the ones most people find first, because they are on GitHub and they are free. They are also the ones that want your session cookie up front. The most popular of them, stickerdaniel's server, is explicit about it: it either opens a browser for you to log in, imports cookies from your existing Chrome or Brave or Edge session, or saves a persistent authenticated profile, and then drives that session across its full toolset (server README on GitHub, as of 2026). Profile lookups, people search, messaging, connection requests, the feed, all of it runs as you.

That is a legitimate design and it works. It is also the design with the most account exposure, because there is no lane in it that is not your account. There is no "just find some people" that does not touch your session, which means the low-risk research half of the job carries the same exposure as the high-risk sending half. The exposure is not only behavioral: a session cookie committed by accident to a public config or repo hands over full account access, and LinkedIn session tokens do not rotate quickly, so the mistake stays live for a while.

The two servers that advertise a "LinkedIn API," felipfr's and quinnjr's, are worth a second look for a different reason. There is no public LinkedIn API that lets an outside developer search arbitrary people or message strangers, so a server offering those through "the LinkedIn API" is either using partner scopes it cannot actually grant you or reaching an undocumented endpoint behind the label. Read the auth step before you trust the noun: if it ends up asking for your credentials or a session token, it is your account on the line, API or not.

The session-cookie question is the whole ballgame

Why does the cookie column matter more than the tool count? Because your LinkedIn account is the asset, and every tool that runs through your session spends that asset's safety budget.

There is no official third-party API that reads arbitrary profiles, runs people search, or messages strangers. We wrote the full map of what LinkedIn's partner API does and does not expose in the piece on LinkedIn API endpoints without approval, and the short version is that every one of those capabilities is off-limits to outside developers. So any LinkedIn MCP server that offers them is reaching them some other way, and there are only two other ways: read public pages the way a browser does, or replay a logged-in session.

Those two ways are not equally risky. Reading a public page from a server operates no account, so there is no account to expose. Replaying your session means your account is now active from an IP that is not yours, on a cadence you did not set, and that mismatch is one of the more legible automation signals LinkedIn has. A server that needs your cookie to do everything is spending your account's safety on tasks, finding and qualifying, that never needed it.

Running LinkedIn prospecting inside Claude with BeReach

BeReach is built around that split rather than against it. The find, qualify and draft workflow runs entirely on public data, with nothing connected. A LinkedIn session is required at exactly one point, the real outreach send, and not one step before it. We call it cookieless until outreach: where the open-source servers make the cookie the very first line of their config, BeReach never asks for one until you have a drafted batch you want to actually send, and even then it arrives through a connect step in the app, not a token pasted into a JSON file.

The connector is a hosted MCP server at mcp.bereach.ai that runs inside Claude.ai and Claude Cowork over Streamable HTTP, with OAuth 2.1 so there is no key to paste into a config file. Getting it running is four steps:

1. In Claude, add a custom connector pointing at mcp.bereach.ai/mcp.
2. Claude opens the OAuth consent screen; sign in to BeReach and approve.
3. The 33-tool surface loads. You can immediately find, qualify and draft, with nothing else connected.
4. When you are ready to actually send, and only then, connect a LinkedIn account in BeReach so the send tools can act.

The full walkthrough, including Claude Cowork, lives in the docs for running BeReach from Claude. Under the connector there are 135 API operations behind a BEREACH_API_KEY if you would rather call the REST layer directly.

The 33-tool surface, grouped by what it touches

The connector's tools sort into the same lanes as the workflow. The grouping that matters is which ones need a connected account and which do not.

Roughly two thirds of the surface, everything up to the send, runs with no cookie in play. The complete typed reference, with every tool and its arguments, is in the MCP tool reference.

A worked transcript: find, qualify, draft, approve

Here is what the four-step loop looks like as an actual Claude conversation, with nothing connected until the last line. The prompts are yours; the bracketed notes describe what BeReach does when Claude calls the tool.

You: Find founders and heads of growth at seed-to-Series-A B2B SaaS companies who posted about hiring their first SDR in the last month.

Claude: [calls find posts and find people on public data] I found 41 people matching that. They are founders and growth leads whose recent public posts mention hiring a first sales rep. Want me to qualify them against a profile?

You: Yes. Qualify for a fit with a tool that helps small teams run outbound without a full SDR desk. Drop anyone who already has a large sales org.

Claude: [calls profile check and qualify tools, still public data] 27 of the 41 are a clear fit. I dropped 14 with existing sales teams over ten people or a non-B2B model. The 27 are stored as contacts with a fit note on each.

You: Draft a first-touch connection note for each of the 27. Reference the hiring post, keep it under 300 characters, no pitch in the note itself.

Claude: [calls draft dm for each contact] Drafted 27 notes. Each opens on the person's own hiring post and asks a question rather than pitching. They are sitting in drafts for your review; nothing has been sent.

You: Show me the first five, then I will approve.

Claude: [returns the drafts] Here are five. Edit any of them inline, or tell me to approve the batch.

You: Approve all 27. Send at the paced rate.

Claude: [this is the first step that needs a session; if no account is connected, BeReach asks you to connect one] To send, connect the LinkedIn account you want these to go out from. Once connected, I will queue the 27 within your daily invitation budget and pace them under the safe weekly ceiling.

Notice where the cookie enters. The first four exchanges, the entire research and drafting effort, ran on public data with nothing connected. Only the final "approve and send" reaches for an account, and even then the sending is paced, not fired all at once. That pacing is not a marketing feature; it is the same rate discipline any careful operator applies. For basic accounts LinkedIn's widely reported safe ceiling is roughly 100 connection invitations per week (LinkedIn outreach community guidance, 2025), and the queue stays under it by spreading invites across days instead of firing a batch. The exact number LinkedIn enforces is undisclosed and shifts with account age and standing, which is the whole argument for staying well under the line rather than probing for the wall.

If you want the same loop as a hands-off background worker rather than a live chat, the same engine runs it unattended; that is the subject of the guide to an AI agent for LinkedIn outreach.

Which LinkedIn MCP server should you use

Match the server to the job, and the choice falls out of the cookie column above.

• You want to read and manage your own LinkedIn from Claude, and you accept that every call runs as you: an open-source browser-session server like stickerdaniel's does that, for free, in exchange for handing it your cookie.
• You want raw profile or company data at scale and you do not care about running an account: a hosted scraper like Apify's returns data for an Apify token, no LinkedIn cookie, though you are scraping and paying per run.
• You want to run actual prospecting, find, qualify, draft and approve, without spending your account's safety on the research half: that is the case BeReach is built for, with the session reserved for the send alone. It is the one paid option here rather than a free repo or a per-run scraper, so the trade is a flat subscription for a maintained public-data lane and paced sending; current plans are on the pricing page.

You can also just try the find step with nothing installed. The free LinkedIn people search tool runs on the same public lane the connector uses, in your browser, with no account connected and nothing to paste.

The short version

A LinkedIn MCP server lets Claude call LinkedIn tools mid-conversation. The ones you find first are open-source repos that need your live session cookie for every tool, which spends your account's safety on tasks that never needed it. The hosted options split further: scrapers take a token and return data, official connectors expose only LinkedIn's narrow sanctioned actions, and a public-first connector like BeReach keeps the whole find-qualify-draft loop cookieless and reserves your session for the one moment it truly matters, the send.