Cookie-Based vs API-Based LinkedIn MCP: The Only Difference That Matters

Nearly every LinkedIn MCP server you will find belongs to one of two families. One asks you to copy a value out of your browser. The other sends you to LinkedIn to click Allow. They look similarly quick to set up, and people often pick whichever appears first in search results. The gap between them only becomes visible on the day something goes wrong.

MCP — the Model Context Protocol — is the open standard that lets an AI assistant such as Claude or ChatGPT talk to an outside service. It says nothing about how that service should authenticate you. So each LinkedIn MCP author picked their own method, and the two methods are not close to equivalent.

What actually happens in the cookie flow?

Here is the sequence, step by step.

• You log in to LinkedIn in your normal browser.
• You open developer tools (the built-in panel browsers ship for inspecting a page) and find the stored cookies for linkedin.com.
• You copy the value of a cookie usually named li_at. This is your session cookie — the small piece of text your browser sends on every request so LinkedIn knows it is still you.
• You paste that value into a config file or an environment variable on your machine, or into a hosted tool’s settings box.
• The tool now sends that cookie with its own requests. LinkedIn sees a request that looks exactly like it came from you, in your browser.

That last line is the whole story. The cookie is not a limited key issued for one job. It is your logged-in session. Anything you can do after logging in, the holder of that cookie can also do: read your inbox, send messages, send connection requests, browse profiles, view your settings pages.

Two more properties matter. First, the cookie expires on LinkedIn’s own schedule, which is not published and not predictable — it can be invalidated by a security check, a new device, or a routine rotation, and your tool simply stops working with a confusing error. Second, there is no per-app off switch. To kill a leaked cookie you change your LinkedIn password, which signs out your other sessions too.

Tool authors in this family are often honest about the risk. The most-starred open-source LinkedIn MCP server, stickerdaniel/linkedin-mcp-server, 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”. That is a fair warning from the author, and worth taking at face value.

What actually happens in the OAuth flow?

OAuth (an open standard for granting one app limited access to your account on another service) reverses who is in control. Step by step:

• You click Connect in the tool. It sends you to a page on linkedin.com — LinkedIn’s own consent screen, not a lookalike form inside the tool.
• You are already logged in there, or you log in there. Your password is typed into LinkedIn, and the tool never sees it.
• The screen lists the exact permissions being requested. For posting, that permission is called w_member_social — a scope (a named, limited slice of access) that allows creating posts as you, and nothing else.
• You approve or decline. If you approve, LinkedIn hands the tool an access token — a long random string that is only valid for the scopes on that screen.
• The tool uses the token against LinkedIn’s documented endpoints, such as POST /v2/ugcPosts. If it tries anything outside the granted scope, LinkedIn refuses.

The token is not your session. Someone holding it cannot open your inbox, cannot send a connection request, cannot see your settings, and cannot log in as you anywhere. It also does not silently outlive your intent: LinkedIn keeps a list of connected apps, and removing one there kills the token immediately, without touching your password or signing you out anywhere.

One honest caveat on the other side. LinkedIn member tokens for self-serve apps expire in about 60 days, and those apps do not get a refresh token, so you will need to reconnect from time to time. That is mildly annoying and it is also a feature: access that expires by default is access that cannot quietly linger for years.

Cookie or OAuth — how do they compare directly?

Where does Kalovio store my LinkedIn token?

Kalovio is in the OAuth family, and the token handling is worth stating plainly because “we use OAuth” says nothing about what happens after the token arrives.

• It is encrypted before it is stored. Kalovio uses envelope encryption with AES-256-GCM. In plain terms: the token is locked with a per-record key, and that key is itself locked with a master key held as a server secret. The stored row is useless on its own.
• It never leaves the backend. The token is decrypted in memory only at the moment a request is sent to LinkedIn. It is never written to logs, never returned in a tool result, and never included in an error message.
• The AI never sees it. This is the part people assume works the other way. Claude and ChatGPT never receive your LinkedIn token. There are two separate sign-ins: the AI app signs in to Kalovio, and Kalovio separately holds its own LinkedIn permission. The two are deliberately not bridged.
• Nothing is scraped. No cookies, no browser automation, no session borrowed from you. Kalovio can only see posts it created itself, because the permission to read your wider history is closed to self-serve apps.

There is one more layer worth knowing, because it guards against a different problem. Publishing, scheduling and deleting in Kalovio are two-step. The first call returns a preview plus a signed token covering the exact content — the text, image, timing and mentions. Nothing reaches LinkedIn until a second call confirms with a matching token. That means a hidden instruction buried in a web page or a document the assistant happens to read cannot make a post go out behind your back.

Does OAuth make automated posting risk-free?

No, and any tool telling you otherwise is overselling. LinkedIn’s API Terms of Use, section 3.1(26), restricts using the APIs “to automate posting on the LinkedIn Services”, and there is no written exception for member-approved posting. That clause exists regardless of how well a tool is built.

The defensible position is narrower and worth saying out loud: the access is granted through an open, self-serve permission that LinkedIn offers any developer; you give consent yourself on LinkedIn’s own screen; you approve the exact text of every single post before it publishes, so a human is behind each one; nothing is scraped; and you can revoke access at any moment. That is a meaningfully better position than a copied cookie, but it is not the same as a guarantee, and nobody can honestly offer one.

How do I tell which one a tool uses before signing up?

The test takes under a minute.

• Watch where the sign-in happens. If your browser goes to a real linkedin.com page with a consent screen, it is OAuth. If a box inside the tool asks you to paste a cookie, a token, or your password, it is not.
• Ask which scope it requests. A tool built on the official API can name it instantly — w_member_social for posting. A vague answer is an answer.
• Ask which endpoint it posts to. POST /v2/ugcPosts, or LinkedIn’s versioned /rest/posts for multi-image and document posts. Marketing pages that claim “official API, no scraping” while naming neither a scope nor an endpoint are asserting, not proving.
• Check your connected apps. After connecting, an OAuth tool appears in your LinkedIn settings. A cookie-based one never will, because as far as LinkedIn is concerned it was just you.

Both families have legitimate uses. If you need to pull profile or company data in bulk, the scraper repositories and data platforms are what exists, and their own documentation is clear about the account risk you are taking on. If what you want is to write and publish your own posts from a chat window, there is no reason to hand over a whole session for a job that one narrow permission already covers.