LinkedIn MCP Server on GitHub: What Is Actually Out There

Search GitHub for a LinkedIn MCP server and you get a decent list of repositories. Read past the titles, though, and a pattern shows up fast: almost all of them are built to read LinkedIn — profiles, jobs, company pages, search results — and almost none of them are built to post. That is not laziness on anyone’s part. It is a direct result of how LinkedIn hands out access, and it is worth understanding before you clone anything.

MCP, for anyone arriving cold, is the Model Context Protocol — an open standard that lets an AI assistant such as Claude or ChatGPT talk to an outside tool through a defined set of actions. An “MCP server” is just the small program on the other end of that connection. The standard says nothing about how the server should sign in to whatever service it controls, and that gap is exactly where the LinkedIn projects diverge.

What LinkedIn MCP servers are actually on GitHub?

The honest summary is that the open-source space is a reading space. The clearest example is also the best known one.

stickerdaniel/linkedin-mcp-server is the top Google result for “linkedin mcp”, so it is the first thing most people find. It is a scraper: it drives a browser session using your logged-in cookie — the small piece of data your browser holds that proves you are already signed in — and pulls profile, company and job information out of the pages. Its README is unusually straightforward about the two things people most need to know. It says the project “does not publish or create posts on your behalf”, and it warns that accounts “can be restricted or banned”. Whatever you decide about it, that is a project telling you plainly what it is.

Alongside the community repositories sit the commercial data platforms. Apify and Bright Data both expose LinkedIn MCP endpoints, and both are aimed at data extraction — pulling records out of LinkedIn at scale. They are not posting tools and do not present themselves as such.

Zapier approaches it from the automation side. Its LinkedIn MCP surface exposes only about two actions. That is fine as one step inside a wider workflow, but it is not a LinkedIn workspace, and it is not what someone means when they ask for an assistant that can write, schedule and publish.

One more thing worth stating outright, because people often assume otherwise: LinkedIn publishes no official MCP server. There is no first-party repository to look for. Everything on GitHub is somebody else’s project.

Why do the open-source ones read instead of post?

This is the whole story in two paragraphs, so it is worth reading slowly.

Reading LinkedIn can be scraped. If you already have a signed-in browser session, nothing in the code stops a program from loading the same pages you can load and lifting the text off them. No registration, no approval, no keys. That means one developer can publish a working read-only LinkedIn MCP server in a weekend, and several have.

Posting cannot be done that way — at least not in a way anyone wants to put their name on. Publishing through LinkedIn’s own interface means calling its API (application programming interface, the official way software talks to LinkedIn), and that requires a registered application holding the w_member_social permission from the “Share on LinkedIn” product. Registration is free and self-serve, so money is not the obstacle. The obstacle is structural: an OAuth application has a client id and a client secret that belong to one registered app. You cannot ship those in a public repository, because publishing a secret is the same as deleting it.

So a self-hosted posting server means every single user registering their own LinkedIn developer application, requesting the products, copying two secrets into a config file and keeping the server running. That is a genuine option for a developer, and some people want exactly that. For everyone else it is a wall. The result is the pattern you see on GitHub: reading is open source, posting is a hosted service.

What is the difference between the options?

Should I clone a scraper or not?

That is your call, and it deserves a straight answer rather than a scare. Cloning a read-only scraper is a normal developer thing to do, the code is right there to inspect, and you control where it runs. Three points are worth weighing honestly before you paste a cookie into anything.

• A session cookie is not scoped. It is not a “reading key”. It carries your whole account — inbox, connections, settings — because it is the same proof of identity your browser uses. Nothing narrows it down to reading.
• You cannot revoke one tool. There is no entry in LinkedIn settings for a copied cookie. Switching it off means changing your password or signing out of every session on every device.
• The maintainer’s own warning stands. Accounts “can be restricted or banned”. That is the project’s wording, not a rival’s characterisation, which is precisely why it deserves weight.

None of that makes the project bad or its author careless — quite the opposite, since it is documented up front where most tools stay quiet. It just means the trade is real, and you should make it deliberately rather than by accident.

What if I just want posting to work?

Then the GitHub route is the long way round, and it is fair to say so. Registering a developer application, requesting products, storing a client secret, keeping a server alive and refreshing a token every couple of months is a project in itself. Some people want that project. Most people wanted to write a post.

Kalovio is the hosted route for the second group. You add one address, https://kalovio.com/mcp, as a custom connector in Claude or in ChatGPT’s Developer Mode, sign in to LinkedIn once on LinkedIn’s own consent screen, and start writing. There is nothing to clone, no cookie to paste, no secret to store and no server to run.

What that gets you, in plain terms:

• Real OAuth, not a cookie. You approve on linkedin.com, the connection is listed in your LinkedIn settings, and you can revoke it there whenever you like. The permission is w_member_social — publish on your behalf, and nothing else.
• Your token never leaves the backend. It is envelope-encrypted with AES-256-GCM (strong, standard encryption), decrypted only in memory at the moment a request is made, never logged and never handed to the AI you are chatting with.
• Nothing is scraped. No cookies, no browser automation, no session borrowing.
• A two-step confirm gate. Publishing, scheduling, queueing and deleting each return a preview plus a signed token covering the exact content first. Nothing happens until a second call arrives with your confirmation and a matching token — which is what stops a hidden instruction buried in a web page the model read from posting on your behalf.
• 26 tools covering drafts, publishing, scheduling, a posting queue, an image and PDF library, a writing voice profile and link-click counts.

What are the honest limits?

The same structural walls that shape GitHub shape Kalovio too, and skipping them would be the wrong way to end an article about being straight with people.

• It cannot read posts it did not create. The permission for reading your history, r_member_social, is closed to self-serve applications. No amount of engineering opens that door.
• Tokens expire after about 60 days. Self-serve applications get no refresh token, so you reconnect. It is one click, but it is not nothing.
• Tagging a company needs its numeric organisation id. There is no name lookup for self-serve apps. Kalovio keeps a shared directory so a company tagged once resolves by name afterwards, but the first time may need the number.
• There are no engagement analytics. Likes, comments and impressions need the partner-gated Community Management API. Link-click tracking is offered instead, and that is a different, smaller thing.
• Multi-image and PDF posts use LinkedIn’s newer versioned interface, which may be product-gated for a self-serve app. A refusal is reported clearly rather than hidden. Try it on your own account — do not assume it works for everyone.
• PDF and document posts cannot be scheduled yet, only published immediately.
• It is a free public beta, no card required. Pricing may change later.
• It cannot send messages, connection requests or gather leads. That is not a missing feature; it is outside what the permission allows.

Is any of this against LinkedIn’s rules?

So which should you pick?

If you want to read LinkedIn data and you are comfortable running a scraper with a session cookie, GitHub has working projects and the leading one documents its trade-offs candidly. If you want an assistant that writes and publishes your own posts, the open-source shelf is close to empty — and that is a consequence of how LinkedIn issues posting access, not a gap that someone simply forgot to fill. A hosted OAuth service is the shorter road, on the clear understanding that you are connecting to it rather than inspecting it.