Self-Hosted vs Hosted LinkedIn MCP: Which Should You Pick?
Search “LinkedIn MCP” and the first thing you meet is a GitHub repository. Clone it, add a config file, restart your AI app, done. That is one real option. The other is a hosted server: you paste a web address into your AI app’s connector settings and never install anything. Both are legitimate. They are built for different jobs, and picking the wrong one wastes a weekend.
MCP — the Model Context Protocol, an open standard that lets AI assistants like Claude or ChatGPT talk to outside tools — deliberately supports both shapes. A server can run locally on your own machine, or remotely on someone else’s. This page is the decision, laid out honestly, including the parts where the hosted option is the weaker one.
What does self-hosting a LinkedIn MCP server actually mean?
It means you run the software. In practice that looks like this: install a runtime (Python or Node), clone the repository, install its dependencies, supply your LinkedIn credentials, then point your AI app at the local process. Most desktop AI apps launch that process for you through a small JSON config file (a plain settings file), so once it is set up it starts with the app.
The important detail is not the install steps. It is how the software signs in to LinkedIn. The popular self-hosted projects — the most visible being stickerdaniel/linkedin-mcp-server, the top Google result for “linkedin mcp” — are scrapers. They drive a browser session using your session cookie (the string your browser holds to prove you are already signed in), then read pages the way you would. That is what makes them powerful: they reach profile, company and job data that LinkedIn’s free self-serve developer products never expose.
It is also what makes them risky, and the project says so itself. Its README states plainly that it “does not publish or create posts on your behalf”, and it warns that accounts “can be restricted or banned”. That is not a rival’s criticism — it is the maintainer being straight with you, and you should take it at face value.
What does a hosted LinkedIn MCP server do differently?
A hosted server already runs somewhere. You add its web address as a connector, sign in once, and it shows up as a set of tools inside your AI chat. There is no clone, no runtime, no config file, and no process on your laptop that has to stay alive for the tools to work.
The sign-in is the other half of the difference. A hosted posting server generally uses OAuth — the “Continue with LinkedIn” screen you have used before. You approve on linkedin.com, LinkedIn issues a scoped key (a limited permission slip, not your login), and the connection appears in your LinkedIn settings where you can switch it off. Nothing is scraped, because the tool is asking LinkedIn’s own posting interface instead of reading pages.
The trade is real, and it cuts against the hosted option: that scoped key is genuinely narrow. The posting permission, w_member_social, lets an app publish for you and does nothing else. It cannot read your feed, your messages, or anyone’s profile. So a hosted OAuth server simply cannot do the research work the scrapers do, and no amount of shopping around will change that.
Self-hosted vs hosted: how do they actually compare?
| Self-hosted (clone a repo) | Hosted (paste a URL) | |
|---|---|---|
| Setup effort | Install a runtime, clone, install dependencies, edit a config file, restart the app | Add the address in connector settings, approve once |
| What you must supply | Usually your LinkedIn session cookie, or your login inside a controlled browser | An OAuth approval on linkedin.com — no cookie, no password shared |
| Who stores the credential | You do, on your own machine or server | The provider does, on its backend |
| Can LinkedIn see the connection? | No — it looks like your own browser | Yes — a listed grant you can revoke |
| Read profiles, companies, jobs | Yes — the main reason to use one | No — the self-serve permissions do not allow it |
| Publish posts | Often not — the leading project states it does not post | Yes — that is what it is built for |
| Media support | Not applicable when it does not post | Images, multi-image and PDF documents, depending on the provider |
| Scheduling | You would build it yourself | Built in, if the provider offers it |
| Who maintains it | You, plus whoever maintains the repo | The provider, without you redeploying |
| Cost | The code is free; you pay in your own time and any hosting you choose | Depends on the provider — Kalovio is free during its public beta |
| When LinkedIn changes something | Scraping breaks quietly; you wait for a fix or write one | The provider patches it; you usually notice nothing |
| Account risk documented | Yes — restriction and bans, per the project’s own README | Sanctioned API access, but read the honest note below |
| Can you read the source? | Yes | Only if the provider publishes it — Kalovio does not |
Who stores the token, and does that matter?
This is the trade people argue about most, so it is worth being precise rather than tribal.
Self-hosted keeps the credential on your machine. Nobody else’s database holds it. That is a genuine advantage, and for some people it decides the question on its own. But the credential involved is usually a session cookie, and a session cookie is not scoped — it carries your whole account, inbox and connections included. It sits in a config file or an environment variable on a laptop that also runs everything else you run. Local is not automatically safer; it moves the responsibility to you.
Hosted keeps the credential on a backend. You are trusting the provider, so ask what they do with it. For Kalovio the answer is: the LinkedIn token is envelope-encrypted with AES-256-GCM (strong, standard encryption), stored in the database, decrypted only in memory at the moment a request goes out, never written to a log, never returned in a tool result, and never handed to the AI model you are chatting with. The token is also scoped to posting only, so even in the worst case it cannot read your inbox — LinkedIn refuses that request, not the app.
The honest position on LinkedIn’s rules. LinkedIn’s API Terms of Use, section 3.1(26), restricts using the APIs “to automate posting on the LinkedIn Services”, with no written exception for member-approved posting. So no posting tool, hosted or self-built, can honestly tell you there is no risk at all. The defensible framing for the API route is narrower: the permission is open and self-serve, consent is given on LinkedIn’s own screen, you approve the exact wording of every post before it goes out, nothing is scraped, and you can revoke access whenever you like. The scraping route raises a different question — one for the LinkedIn User Agreement rather than the API Terms — and the projects themselves warn that accounts can be restricted or banned.
Can a self-hosted LinkedIn MCP server publish posts?
Usually not, and this surprises people who assumed the open option does more. The best-known project says outright that it does not publish or create posts. If you want posting from a self-hosted server, you have two paths: automate the browser yourself, which is the approach carrying the ban warnings, or register your own LinkedIn developer app, get the free “Share on LinkedIn” product approved, and build the OAuth flow and the posting calls yourself.
That second path is entirely doable — the products are free and self-serve, and approval is a review rather than a payment — but it is a project, not an afternoon. You will handle the OAuth handshake, encrypted token storage, the roughly 60-day token expiry with no refresh token for self-serve apps, the separate upload steps for images and documents, and LinkedIn’s versioned interface with its dated headers. If you want to learn all of that, self-hosting is a good teacher. If you want a post to go out on Tuesday, it is a detour.
What happens when LinkedIn changes something?
LinkedIn changes things without telling you. A scraper feels this immediately and quietly: a selector stops matching, a page renders differently, and your tool returns empty results that look like real results. You then wait for a maintainer, or fix it yourself. An API-based tool feels it differently: an endpoint version sunsets, a response shape shifts, a feature turns out to be gated for self-serve apps. With a hosted service, someone else deploys the patch and you carry on. With your own build, that is your Tuesday evening.
Neither side is magic here. The real question is whether you want to own that maintenance or hand it to someone else.
Pick self-hosted if…
- You want to read LinkedIn data — profiles, company pages, job listings, search results. Hosted OAuth tools cannot do this, because the reading permission is closed to self-serve apps.
- You want full control of the code and the credential, and you are willing to actually review what you run.
- You are comfortable running a service — installing a runtime, reading logs, updating dependencies, repairing a break when a page layout shifts.
- You accept the account risk the projects document. Restriction and banning are stated outcomes in their own README, not hypotheticals invented by competitors.
- You are building something custom and want a base to fork rather than a finished product.
Pick hosted if…
- Your actual goal is publishing — drafting posts with an AI assistant, attaching an image or a PDF carousel, scheduling, keeping a queue. One caveat on media: multi-image carousels and PDF document posts go through LinkedIn’s newer versioned interface, which may be product-gated for a self-serve app, so try it on your own account rather than assuming it works for everyone. Document posts also cannot be scheduled yet — they publish immediately.
- You do not want to run anything. No install, no process to keep alive, no laptop that must be awake for a scheduled post to go out.
- You would rather approve on LinkedIn’s page than paste a cookie, and you want a connection you can revoke from LinkedIn settings in one click.
- You want a human approval step before anything publishes. Kalovio’s publish, schedule, queue and delete tools are two-step: the first call returns a preview plus a signed token covering the exact content, and nothing happens until a second call confirms with a matching token. That is the practical defence against prompt injection — hidden instructions buried in a web page or document the model reads.
- You are on a work laptop where installing a developer toolchain is awkward, slow, or not permitted.
Can I use both at once?
Yes, and for some people that is the right answer. AI apps let you connect several MCP servers side by side. Run a self-hosted reader for research, connect a hosted publisher for output, and let the assistant reach for whichever tool fits the request. You still carry the reader’s account risk, so read its warnings before deciding — but the two are not mutually exclusive, and connecting one does not block the other.
Is Kalovio open source, and can I self-host it?
No on both counts, and it is better to say that plainly than to leave you hunting for a repository that does not exist. Kalovio’s source code is not public and there is no GitHub repository to clone. It is a hosted service you connect to by web address: add https://kalovio.com/mcp in your AI app’s connector settings, sign in with LinkedIn once, and start posting. Nothing to install, no cookie to paste, no server of your own to keep running.
That is the honest shape of the choice. If reading the code matters more to you than anything above, the self-hosted scrapers are open and you can go and read them — along with the warnings they carry. If what you want is to publish from a chat window without maintaining anything, hosted is the shorter road.
Questions people ask
Can I self-host a LinkedIn MCP server that posts?
Not with the popular open projects — the leading one states it does not publish or create posts. To self-host posting you would register your own LinkedIn developer app, get the free “Share on LinkedIn” product with the w_member_social permission, then build the OAuth flow, encrypted token storage and the posting calls yourself. It is possible, but it is a build project rather than a config change.
Is self-hosting a LinkedIn MCP server safer than a hosted one?
Not automatically. Self-hosting keeps the credential on your machine, which is a real benefit. But that credential is usually a session cookie, which covers your entire account and cannot be revoked on its own. A hosted OAuth server holds a token limited to posting that you can switch off from LinkedIn settings. Which is safer depends on which risk you care about more.
Do I need to keep my computer on for a self-hosted MCP server?
Yes, if it runs locally. The tools only exist while the process is running, so anything time-based — a scheduled post, for example — needs the machine awake. A hosted server runs on someone else’s infrastructure, so scheduled work happens whether your laptop is open or not.
Does Kalovio have a GitHub repository I can clone?
No. Kalovio is not open source and there is no public repository. It is a hosted service you add as a connector using the address https://kalovio.com/mcp. That is the whole install: no clone, no dependencies, no local process.
Which should I pick if I only want to write and publish posts?
Hosted. Publishing is what the OAuth route is built for, and the self-hosted scrapers largely do not post at all. If your work is research — pulling profile, company or job data — that is the case for self-hosting, and it is a genuinely different job.
What breaks first, a self-hosted scraper or a hosted API tool?
A scraper usually breaks sooner and more quietly, because it depends on page layouts that change without notice. An API tool breaks less often but more visibly, typically when a version sunsets or a feature turns out to be gated. With a hosted service the provider handles that; with your own copy, you do.
Sources
Try Kalovio free
Run your LinkedIn from a chat with Claude or ChatGPT. Add this as a custom connector — free while in beta, and you approve every post before it goes live.
https://kalovio.com/mcpHow to connect