A LinkedIn MCP With Nothing to Install

Most people arrive at this question the same way. You searched for a LinkedIn MCP server, landed on GitHub, opened the top repository, and the README started with a list of things to install. Somewhere below that was a section about finding a session cookie in your browser’s developer tools and pasting it into a config file. At that point a reasonable person closes the tab and asks whether there is a version that just works.

There is. It is worth understanding exactly what it removes, and being equally clear about what it asks of you in return.

What do I actually have to install to run a LinkedIn MCP server from GitHub?

MCP — the Model Context Protocol, an open standard for connecting AI assistants to outside tools — allows two shapes of server. A local one runs as a program on your own machine and talks to the AI app through your computer. A remote one runs on someone else’s servers and the AI app reaches it over the web. Almost everything you find on GitHub is the first kind.

A local server is a normal software project, so it carries a normal software project’s setup. The exact list varies, but the shape is consistent: clone the repository, install a runtime such as Python or Node (or install Docker so you do not have to), pull down the dependencies, create a configuration file, put your credentials into it, register the server in your AI app’s config, then start the process. When your machine restarts, the process is gone until you start it again. When the project updates, you pull the changes yourself.

And for LinkedIn specifically there is one extra step that is not like the others. Because LinkedIn does not hand out an easy key for reading profiles and feeds, the popular repositories work by borrowing your browser’s logged-in session — the cookie. You open your browser’s developer tools, find the string, and paste it in. The most-linked project of this kind states in its own README that it “does not publish or create posts on your behalf”, and warns that accounts “can be restricted or banned”. So the setup work does not even end at posting; that project is built for reading data, not writing it.

What does a hosted LinkedIn MCP server remove?

A hosted, or remote, server flips the arrangement. The code runs on the provider’s infrastructure. You paste one address into your AI app and sign in. Here is the removal list, item by item:

• No clone. There is no repository to download and no folder living on your disk.
• No runtime to install. No Python version to match, no Node, no Docker, no virtual environment (a self-contained folder that keeps one project’s libraries separate from another’s).
• No dependencies. Nothing to install, nothing to conflict with another project, nothing to break when your operating system updates.
• No configuration file. No JSON to hand-edit, no environment variables to set, no file path to get wrong.
• No cookie extraction. You never open developer tools. Sign-in happens on LinkedIn’s own page through OAuth — the standard permission screen you have used for “Sign in with Google” and similar.
• No process to keep running. Closing your laptop does not switch the tool off. Scheduled posts still go out at the time you picked, because the scheduling runs on the server, not on your machine.
• No updates to apply. Fixes and new features arrive at the URL. There is no pull, no rebuild, and no version drift between what the docs describe and what you are running.

The practical difference is measured in the failure modes you no longer have. Nobody debugs a dependency conflict in a URL.

What is the honest downside of using a hosted one?

Three things, and they are real. Anyone selling you a hosted service without naming them is not being straight with you.

You are trusting a backend with an encrypted LinkedIn token. When you approve the connection, LinkedIn issues an access token — a limited key tied to that one app and those named permissions. With a local server, that credential sits on your own disk. With a hosted one it sits in the provider’s database. It should be encrypted, and with Kalovio it is, but encrypted at someone else’s place is still someone else’s place. That is the core of the trade and there is no way to word it away.

You cannot read the source. Kalovio is not open source. There is no public repository to inspect and no code to audit line by line. It is a hosted service you connect to by address. If reading every line before you run it is your requirement, a hosted service cannot meet it, and you should use a self-hosted project instead — accepting the setup, and, for the cookie-based ones, the account risk their own documentation describes.

You depend on it staying up. A service you do not run is a service you cannot restart. If it has an outage, your scheduled post waits. If the provider shuts down, your connection stops working. Your published posts are safe — they live on LinkedIn, not on Kalovio — but the tooling around them is not under your control.

Hosted or self-hosted: what is the real difference?

What does Kalovio do to earn that trust?

Since you cannot inspect the code, the fair thing is to point at the parts you can verify from outside, and at the design decisions that limit the damage a mistake could do.

• Consent happens on LinkedIn’s own page. You are sent to linkedin.com, you see the permission being requested, and you approve it there. Kalovio never sees your LinkedIn password.
• You can revoke it in one click, any time. The connection appears in your LinkedIn settings under permitted services. Remove it there and access stops immediately, without changing your password or signing you out anywhere. A pasted cookie has no such entry — that is a check you can run yourself, on any tool.
• The scope is narrow. Posting uses w_member_social, which allows publishing on your behalf and nothing else. It cannot read your inbox, your connections, or your feed. LinkedIn enforces that limit at its end, not Kalovio’s.
• Tokens are encrypted and stay on the backend. They are envelope-encrypted with AES-256-GCM (a strong, standard encryption method), decrypted only in memory for the moment a request is made. They are never logged, never returned in a tool result, and never handed to the AI you are chatting with.
• Nothing publishes without your approval of the exact wording. 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. This is the practical defence against prompt injection — hidden instructions inside a web page or document the model reads.
• No scraping at all. No cookies, no browser automation, no session borrowing. Only LinkedIn’s official posting endpoints.

Is there anything I still have to do myself?

Yes, and it is short. LinkedIn member tokens for self-serve apps last about 60 days and there is no refresh token, so every couple of months you reconnect — one click through the same LinkedIn screen. Neither Claude nor ChatGPT can pass a chat image attachment through to a connector, so images and PDFs go through Kalovio’s upload panel or upload link instead. Kalovio cannot read posts that were not created through it, because the permission for that is closed to self-serve apps. Tagging a company page needs that page’s numeric organization id the first time, since LinkedIn gives self-serve apps no name lookup, though known companies then resolve by name from a shared directory. And multi-image and PDF posts go through LinkedIn’s newer versioned interface, which may be product-gated for a self-serve app — a refusal is reported clearly, so try it on your own account rather than assuming it works for everyone. PDF and document posts also cannot be scheduled yet — they publish immediately.

How do I set it up?

The whole thing is one address and one sign-in.

• In Claude: Settings → Connectors → Add custom connector, and paste https://kalovio.com/mcp. This works on the free plan.
• In ChatGPT: Developer Mode → Plugins → + → New Plugin, the same URL, authentication set to OAuth. Developer Mode is on the paid plans and is web only, and the connector has to be switched on per conversation from the tools menu.
• Then: approve the LinkedIn permission screen when it appears, and ask your assistant to write a post. It will show you a preview and wait for your yes before anything goes out.

Kalovio is in free public beta with no card required, and pricing may change later, which is worth saying up front. But the installation step is not coming back — that is the whole point of a hosted connector.