A LinkedIn MCP That Is Not a Scraper

If you searched for a LinkedIn MCP server, the first result you found was almost certainly a scraper. That is not a criticism — it is simply what most of the popular open-source projects in this space do, and several of them do it well. But it means a lot of people arrive at these tools wanting to publish posts and end up installing something built to read profiles, which is a different job with a very different risk profile.

This article explains the two mechanisms plainly, says what each is genuinely good at, and helps you pick the right one. MCP — the Model Context Protocol, an open standard that lets AI assistants like Claude or ChatGPT call outside tools — says nothing at all about how a tool should log in. That choice is left entirely to the builder, and it is the choice that decides everything else.

What does it mean for a LinkedIn MCP server to be a scraper?

A scraper does not talk to an official interface. It loads the ordinary LinkedIn web pages that a person would see, and reads the information out of the page markup. To do that while signed in as you, it needs your session — usually a session cookie (the small string your browser stores after you log in, which proves to LinkedIn that this browser is already you) pasted into a configuration file, or a full browser it drives in the background.

The upside is obvious and real: a scraper can see anything you can see. Profiles, company pages, job listings, search results, your own feed. No permission needs granting, because from LinkedIn’s point of view nothing unusual is happening — it looks like you, browsing.

The downside comes from exactly the same fact. A session is not divided into permissions. It carries your whole account: messages, connections, settings, saved items. There is no version of it that means “reading only”, and no way to hand over a slice of it.

Is stickerdaniel/linkedin-mcp-server worth using?

For reading, it is a genuinely good project. It is the top Google result for “linkedin mcp”, it is actively maintained, it is straightforward to install, and it does a real job that no official self-serve API will do for you. If your work involves pulling profile or company information into an AI assistant, it is the obvious place to start.

It is also unusually honest, which is worth crediting. Two lines in its own README settle most of the confusion people have about it. On what it does, the README states it “does not publish or create posts on your behalf”. On what it costs you, it warns that accounts “can be restricted or banned”.

Read those together and the picture is clear. It is the right tool for reading and, by its own description, not a tool for publishing at all. People who install it hoping their assistant will start writing their LinkedIn posts are not hitting a bug or a missing feature — they are using the wrong category of tool.

Cookie session or OAuth scope: what actually changes for you?

OAuth is the flow you have used many times without naming it: the “Continue with LinkedIn” screen where LinkedIn itself asks whether you approve. Instead of handing over your session, you approve a named permission — a scope — and the tool receives a limited key called an access token. For posting, that scope is w_member_social, which allows publishing on your behalf and nothing else.

Four practical differences follow, and they matter more than any feature list.

Revocability is the difference people notice first. An OAuth grant appears in your LinkedIn settings under permitted services, and removing it stops that one tool immediately, without touching your password or logging you out on your phone. A pasted cookie has no entry to remove. Your only lever is the blunt one: change your password, which ends every session you have everywhere.

Scope limits are the difference that matters most day to day. A token issued for w_member_social cannot open your inbox, cannot list your connections, cannot change your settings. Not because the tool politely declines, but because LinkedIn refuses the request at its own end. You are not relying on the builder’s good behaviour.

Breach is where the gap becomes uncomfortable. Ask what an attacker gets if the tool’s database or logs leak. From a scraper, they get a live session and are logged in as you until it lapses — messages included. From an API tool, they get a key that can post and nothing more. Both are bad. Only one of them is bad in a way you can contain.

Visibility is the quiet one. Because a session looks like ordinary browsing, LinkedIn has no way to tell a well-behaved research tool from an account behaving oddly. That is the mechanism behind the ban warnings, and it is why the honest scrapers put the warning in the README rather than the small print.

What if I do need to read profiles?

Then use the scraper, and go in with your eyes open. There is no polite alternative to recommend, because none exists at the self-serve tier. LinkedIn’s permission for reading a member’s own wider post history, r_member_social, is closed to self-serve applications, and reading other people’s profiles is not on offer at all. Anything that reads profiles is reading them some other way. Any tool claiming otherwise while calling itself official is worth a hard look.

Which LinkedIn MCP servers post without scraping?

The posting side of this market is thinner than the reading side, which is why the search results skew the way they do.

• Apify and Bright Data offer LinkedIn MCP endpoints, but for data extraction rather than posting. Different job again.
• Zapier’s LinkedIn MCP exposes only about two actions. Fine if one of them is what you need.
• Taplio has an MCP server, and its own page states it is “text-only... you cannot upload images, video, or PDF carousels”.
• ContentIn does not have one yet — its page says the server is currently in build, with a waitlist.
• Postiv and Carly are paid or trial-only posting tools.
• Kalovio is free in public beta, hosted, and built on the official API.

One thing worth noticing across the whole set: none of the four ranking software pages names a single OAuth scope or API endpoint. That is not proof of anything, but a tool that genuinely posts through the API can always tell you which permission it holds and where it sends the request. It is a fair question to ask any of them.

How does Kalovio publish without scraping?

Kalovio is the other kind of tool: no cookies, no browser automation, no session borrowing, nothing read from a page. Here is the whole mechanism.

• You approve it on LinkedIn’s own screen. Signing in with LinkedIn creates your account and grants w_member_social in one step. You can remove that grant from your LinkedIn settings whenever you like.
• It posts through documented endpoints. Text, single-image and article posts go through POST /v2/ugcPosts. Multi-image and document posts use LinkedIn’s newer versioned /rest/posts route — which may not be switched on for every self-serve app, so a refusal there comes back as a clear message and it is worth testing on your own account before you rely on it. Document posts publish immediately only; scheduling them is not wired up yet.
• Your LinkedIn token never leaves the backend. It is envelope-encrypted with AES-256-GCM (strong, standard encryption) in the database, decrypted only in memory at the moment of a request. It is never logged, never returned in a tool result, and never visible to the assistant you are chatting with.
• Two sign-ins that are never bridged. Your AI app signs in to Kalovio with OAuth 2.1. Kalovio signs in to LinkedIn separately with OAuth 2.0. Neither token is passed to the other side.
• Nothing publishes without your word. Publishing, scheduling, queueing and deleting are two-step. The first call returns a preview plus a signed token covering the exact content. Nothing is sent until a second call arrives with your confirmation and a matching token — which is what stops hidden instructions inside content the model reads from posting on your behalf.

The honest cost of that design is the mirror image of the scraper’s. Kalovio cannot read posts it did not create, cannot show you engagement analytics (that needs LinkedIn’s partner-gated Community Management API), cannot send messages or connection requests, and cannot collect leads. Your LinkedIn token also expires after roughly sixty days, because self-serve applications do not get refresh tokens, so you reconnect through a link the tool gives you.

Is API posting definitely allowed?

So which one should you pick?

Pick by the job, not by the search ranking. If you want an assistant that can look up profiles and companies, use one of the scraper projects, read its warnings, and accept the risk it documents openly. If you want an assistant that writes and publishes your own posts, a scraper will not do it — the leading one says so in its README — and you want an API tool with a named scope, a named endpoint, and a confirmation step before anything is published. The two are complements, not competitors.