There are now several long, careful comparisons of LinkedIn MCP servers. They sort by stars, tool count, authentication method and terms risk, and the good ones are genuinely useful. Not one of them mentions the thing most likely to break your setup, which is that the compliant option has a two-month shelf life.
Why 60 days, and why it cannot renew itself
Quick answer
LinkedIn issues access tokens with a 60-day lifespan and states plainly that it does not generate long-lived tokens to protect members' data. Programmatic refresh tokens exist, but LinkedIn restricts them to a limited set of partners. An ordinary self-serve application therefore has no way to renew a token without the member returning and logging in.
There is a refresh mechanism, and it is worth understanding precisely, because it is the reason people believe this is handled when it is not. LinkedIn will re-issue a token without showing the consent screen, but only if two conditions hold at the moment you ask: the member is still logged in to linkedin.com in that browser, and the current token has not yet expired.
‼️ Read those conditions again. The silent renewal only works while the token is still alive. Once it lapses, LinkedIn sends the member through the full authorisation flow again. So the mechanism that sounds like automatic renewal is actually a way to extend a token you were already using, and it does nothing for a connector that has been sitting idle for two months.
One more detail that catches people out: if a server later asks for a different scope than the one you granted, LinkedIn invalidates all the previous access tokens. Adding a feature can log every existing user out.
Which servers this actually kills
We went through the field. The answer is narrower than we expected, and the shape of it is the story.
| Server | State | What expiry means for it |
|---|---|---|
| souravdasbiswas/linkedin-mcp-server | Maintained, last commit March 2026, 15 tools | The most capable official-API server in the field, and almost unknown at 7 stars. Dies at 60 days like the rest |
| fredericbarthelet/linkedin-mcp-server | Frozen since March 2025, no licence | Two tools only. Built on the Community Management API, so it also needs an approval most readers will not have |
| Dishant27/linkedin-mcp-server | Frozen since April 2025 despite a recent push date | Carries an open, uncommented issue about the OAuth client secret being passed as a URL query parameter |
| southleft/linkedin-mcp | Last commit March 2026, hybrid | Uses OAuth for some paths and cookies for others, so it half-expires and half-does-not |
| MCPBundles LinkedIn bundle | Hosted, live | The only hosted server demonstrably on genuine LinkedIn OAuth. Organisation and ads scopes rather than member posting |
That is the entire list. Every other LinkedIn MCP server we examined, including the most popular one by a wide margin, does not expire at 60 days because it never touched LinkedIn's OAuth in the first place.
The uncomfortable pattern: the servers that use the sanctioned route are mostly the abandoned ones. Two of the five have not been touched since early 2025. The best-maintained official-API server in the field has seven stars, so nobody sorting a comparison table by popularity will ever see it.
Two of those repos also carry a detail worth knowing before you adopt them: they ship with no licence at all. That is a legal problem separate from any of this, and it is easy to miss when you are reading a feature list.
Why the popular servers never expire
Because they hold something else. Instead of an OAuth token they use your LinkedIn session, either by driving a browser you log into or by taking the cookie pair directly. That has no 60-day problem. It has a different set of problems, and they are not smaller.
| Session cookie | OAuth token | |
|---|---|---|
| Documented lifetime | One year | 60 days |
| What it permits | Everything you can do on LinkedIn | Only the scopes you consented to |
| Revoke one integration | Not possible. Sign out of sessions or change your password | Yes, in Permitted Services |
| Named in the user agreement | Yes, copying cookies is listed under prohibited use | No, it is the sanctioned path |
| Daily ceiling | Whatever LinkedIn's abuse systems tolerate | 150 member requests, documented |
The one-year figure is not our estimate. It is the duration LinkedIn publishes in its own cookie table for the authentication cookie. So when a tool asks you to paste that value, you are handing over a year-long credential with no scope boundary, and your only way to withdraw it is to end every session on your account or change your password with a box ticked that is not ticked by default.
LinkedIn's user agreement also names this directly. Section 8.2 prohibits using another's account, and the example it gives in parentheses is sharing log-in credentials or copying cookies. We wrote at length about where that clause lands, including on our own product, in will a LinkedIn MCP get your account restricted.
The ceiling nobody mentions either
If you do take the sanctioned route, there is a second limit that shapes what you can build on it. LinkedIn documents a throttle of 150 requests per member per day for sharing, against 100,000 per day for the application as a whole.
For one person posting a few times a day that is irrelevant. For an assistant that reads before it writes, checks state, retries on failure and posts a thread, 150 is closer than it sounds. Combined with the 60-day expiry, that is the full envelope of the compliant path, and it goes a long way to explaining why so much of this category drifted to cookies instead.
The most honest tool name in the category
One hosted server, MCPBundles, runs on genuine LinkedIn OAuth. Looking through its tool list turned up something we have not seen anywhere else: a tool whose entire purpose is to report that the gated product has not been granted to your workspace.
It is a stub named for exactly that condition, and it fires when Community Management access is missing. We would rather see that than a tool that fails vaguely, and it is the clearest single artefact in this whole research set for the point we made in does LinkedIn have an analytics API: the official path is real, and it is rationed. Somebody had to write a tool to say so out loud.
How to tell which kind you are running
- Look at what it asked you for at setup. A LinkedIn consent screen means OAuth and a 60-day clock. A field wanting a long string starting with the letters li, or your LinkedIn email and password, means a session credential.
- Check whether the vendor appears in your Permitted Services list on LinkedIn. If it does not appear there, it is not using OAuth, whatever the marketing page says.
- If the setup involved a browser opening somewhere that is not your machine, the vendor is operating a session on your behalf from their infrastructure.
- Search the repository or docs for the words refresh token. Silence usually means the author has not hit day 61 yet.
- If it offers post impressions or profile views for a personal profile, it is not reading them from LinkedIn's official member analytics endpoint unless it also tells you it holds Community Management approval. Almost nobody does.
That last test is a strong one, and it is worth applying to us as much as to anyone. Every impression figure on offer in this category comes from a browser session reading the page or the internal endpoints behind it, not from LinkedIn's official analytics API.
What to do about the 60 days
- Treat re-authorisation as a scheduled task, not an incident. Put it in a calendar at day 55 rather than discovering it when a post does not appear.
- Prefer a connector that tells you the token is close to expiry. Most do not.
- Do not assume a scheduled post failed because of your content. A silent auth expiry looks identical from the outside.
- If you are building, ask for every scope you will ever need at the first consent, because adding one later invalidates the tokens you already hold.
- If you need something that genuinely never expires, understand you are choosing a year-long unscoped credential and the clause that names it. That is a real trade, not a free upgrade.
Where our own connector sits
Our MCP connector posts to LinkedIn over OAuth, so it is in the group this article is about. We hit the 60-day expiry like everyone else on that route, and we would rather say so than let you find out on day 61. We do not ask anyone for a session cookie, and there is no field in our product where you could paste one.
The honest asterisk, the same one we put on every article in this cluster: our LinkedIn analytics do not come from the official API, because we do not hold that approval. They come from our own browser extension reading your own session, which is the credential type described above with all of its consequences. Our posting is on the sanctioned path. Our analytics are not.
If none of this appeals, there is a route with no credential at all. Our Claude skills are plain files you drop into an assistant. They hold no token, no cookie and no session, so there is nothing to expire and nothing to revoke. They change how the model writes rather than what it can reach.
The other platform charges money instead of rationing access, which turns out to be a different kind of problem entirely. We worked through that in what the Twitter API now costs.
The summary is short. If your LinkedIn MCP server still works six months after you set it up, that is worth knowing about rather than celebrating, because it tells you which credential it is holding.