LinkedIn MCP servers, compared
By Ryan Melling, founder of WordPush
· 6 min read
There are four kinds of LinkedIn MCP server and only one is safe for an account you care about. How to tell them apart, and which to avoid.
Search for a LinkedIn MCP server and you will get four genuinely different kinds of product in one undifferentiated list. They have different capabilities, different setup, and very different consequences for your account. Picking the wrong category is a more expensive mistake than picking the wrong product within one.
This is a guide to telling them apart. We make one of these, which we will flag plainly when we get to it.
First, the dividing question: how does it authenticate?
Before capabilities, before price, before anything: does it send you to LinkedIn’s own login, or does it ask you for a cookie?
That one question separates the safe half of this market from the risky half, and you can answer it from the setup instructions in about ten seconds.
OAuth (send you to a login page). You click connect, LinkedIn’s own page opens, you approve a named set of permissions, and LinkedIn issues a token scoped to those. The tool can do those things and nothing else. You can revoke it from LinkedIn’s settings whenever you like. This is the approved route and it is what the API exists for.
Session cookie (asks you to paste li_at). You open your browser’s developer tools, find the cookie LinkedIn set when you logged in, and paste it in. That cookie is your whole session. It is not scoped to anything — a tool holding it can read your messages, browse profiles as you, and do anything else you could do. LinkedIn treats automated access on a session cookie as a terms violation, and enforcement is by account restriction.
If a README tells you to get your li_at cookie, you now know what category you are in. That is not a judgement about the developer — the cookie approach exists because the official API genuinely does not offer what those tools do — but it is a judgement you should be making consciously.
The four categories
1. Publishers on the official API
What they do: draft, schedule and publish posts to your profile or company page. Some add images, native carousels and analytics.
How they authenticate: OAuth, always. It is the only way to get publishing rights legitimately.
What they cannot do: read your inbox, search profiles, export connections, automate engagement. The API does not grant those and no amount of product work changes it.
Who they are for: anyone whose goal is to post consistently without the tab-switching. This is the category most people searching for this actually want.
Examples in this space include WordPush (ours — see the disclosure below), and several other hosted publishing products that have added MCP servers over the last year, among them ContentIn, Postiz, Postiv and DemandBird. Capabilities and pricing in this category move quickly enough that it is worth checking each vendor’s own current page rather than trusting any roundup’s numbers, including this one.
2. Scrapers
What they do: read profiles, companies, jobs, search results and sometimes messages. Genuinely useful for research, lead lists and competitive work.
How they authenticate: session cookie, essentially always, because the official API will not give them this data.
The trade: real capability, real risk. LinkedIn restricts accounts for automated access, and an account restriction on the profile you have spent years building is an expensive way to save time on research.
This is where most of the popular open-source LinkedIn MCP repositories sit. They are often well-built. The risk is not in the code quality.
3. Outreach automation
What they do: auto-connect, auto-like, auto-comment, auto-DM at volume.
Status: explicitly against LinkedIn’s user agreement. Not a grey area.
There is no version of this that is safe for an account you care about, and the ones that describe themselves as “safe” or “undetectable” are describing their evasion, not their compliance. If growth through volume outreach is the goal, that is a decision to take with clear eyes about what it costs when it goes wrong.
4. Prompt packs dressed as integrations
What they do: give your assistant instructions — a “skill”, a prompt library, a set of templates — for writing LinkedIn content well.
What they do not do: touch LinkedIn. There is no connection, no authorisation and no publishing. You still copy the output into LinkedIn yourself.
This is worth flagging because the marketing can be genuinely confusing. A page headed “LinkedIn skills for Claude” can look identical to one headed “LinkedIn connector for Claude” while doing something completely different. Prompt packs are useful — a good writing prompt is a good writing prompt — but if you expected the post to be scheduled at the end of it, you will be disappointed. Check whether there is an authorisation step. No login, no integration.
Hosted or self-hosted?
A practical split that cuts across the categories.
Hosted servers are run by the vendor. You paste a URL, sign in, done. They work from Claude on your phone, from ChatGPT on the web, from anywhere, because the server is always up.
Self-hosted servers run on your own machine. You install dependencies, keep them updated, and hold the credentials yourself. They are unreachable when the machine is off — which also means they will not work with ChatGPT or Claude’s web app at all, since those connect over remote HTTPS to something publicly addressable.
Most open-source options are self-hosted. If “add it to ChatGPT on my phone” is part of your plan, that rules them out on mechanics before you get to anything else.
What to actually ask a vendor
Five questions that sort this out quickly:
- Do you publish through LinkedIn’s official API? A yes with detail is good; evasion is an answer.
- What is the authorisation flow? OAuth login, or cookie paste.
- What tools does the server expose? A vendor that cannot show you the list has not thought hard about permissions.
- Can I set permissions per tool? Most of the control lives in the client, but the server has to expose tools granularly enough for it to matter. A single do-everything tool cannot be partly allowed.
- Can it publish native document carousels? A good proxy for whether the product understands LinkedIn or treats it as a generic text destination.
Our disclosure
WordPush is ours, so treat what follows as a description rather than a recommendation.
It sits in the first category: a hosted MCP server, OAuth only, publishing through LinkedIn’s official API to profiles and company pages. It exposes nine tools covering context, drafting, images, native carousels, scheduling and publishing, each separately permissioned — the full list and what each costs is on the tool reference. It deliberately does not scrape, auto-connect or auto-message.
The thing that makes it different from the others in category one is less about MCP and more about what is behind it: it generates drafts using a voice model built from an interview at signup rather than from the assistant, and it sources what to post about from your industry nightly. Whether that matters to you depends on whether your bottleneck is publishing or deciding.
The honest bottom line
Most people searching for a LinkedIn MCP server want category one and do not know the other three exist. If that is you, the shortlist is short: find a hosted publisher on the official API, check it can do carousels, connect it with OAuth, and set publishing to ask-first.
If you want profile data, you are shopping in category two and should price in the account risk rather than discovering it later.
And if a setup guide asks for your session cookie, you have your answer about which half of the market you are in.
Setup guides for the WordPush connector: Claude, ChatGPT, Claude Code, Cursor. Background on the standard itself is in what is MCP.