This question already has five reasonable answers on the internet, and they agree with each other: there is no official LinkedIn connector, you use a third-party one, and mostly people use Claude to draft rather than to publish. All true. None of them mentions the clause that makes the whole arrangement awkward, so that is what this article is about.
Can Claude post to LinkedIn?
Quick answer
Yes, in three different ways. Through a custom remote MCP connector that publishes via LinkedIn's official API. Through Claude in Chrome or Cowork, driving the real LinkedIn interface in a browser. Or by drafting in the chat and posting by hand. There is no first-party LinkedIn connector in Anthropic's directory, so the first route always means someone else's server.
| Route | What it needs | The catch |
|---|---|---|
| Custom MCP connector | A publicly reachable server. Available on every plan including Free, which gets one connector | Runs into the API terms clause below, and dies every 60 days |
| Claude in Chrome or Cowork | Any paid plan. No server to build | Automating a logged-in browser session is what the User Agreement addresses |
| Draft in chat, post by hand | Nothing | None. This is the only route with no terms question at all |
That last row is not a joke answer. It is the option most people are actually using, it is free of every complication in this article, and no vendor has an incentive to recommend it.
The clause nobody quotes
LinkedIn's API Terms of Use is a separate document from the User Agreement you accepted as a member. It governs developers. Section 3.1 is a numbered list of restrictions, introduced by a line saying you agree not to do the following, except as expressly set out in the document itself. The final item, number 26, reads in full:
Use the Content or the APIs to automate posting on the LinkedIn Services.
· LinkedIn API Terms of Use, section 3.1, last revised 13 December 2022
The words that matter are or the APIs. This is not a scraping clause and not a browser-automation clause. It reaches the sanctioned OAuth path directly, and nothing else in the document expressly permits what it prohibits.
It is also not an old clause that nobody got around to removing. We compared archived captures of this document going back to 2015. The version in force from March 2019 does not contain the sentence. It appears for the first time in the 13 December 2022 revision and has been byte-identical in every capture since.
‼️ That timing is the part worth sitting with. The self-serve posting permission already existed well before December 2022. So LinkedIn did not add the permission and forget to update the terms. It added the prohibition while continuing to hand out the permission with no review at all, and published no changelog entry, developer note or diff announcing it.
‼️ We opened this document in a browser and read the clause ourselves rather than taking it from a summary, because it is the load-bearing fact in this article and it contradicts what almost everyone in this category writes. It sits as the last item of section 3.1, immediately before the heading Excluded Uses of the APIs.
Here is the part that surprised us. Of the eleven pages we read that rank for this question, not one quotes it. Several do gesture at rules, and they reach for the wrong document: the User Agreement's prohibition on crawlers and scraping, which is about harvesting data and which we covered separately in will a LinkedIn MCP get your account restricted. That clause is real and it matters, but it is not the one that speaks to publishing through an approved app.
A second place LinkedIn rules out scheduling
If clause 26 were a stray sentence from a 2022 legal review, you would expect LinkedIn's engineers to write as though it did not exist. They do not.
LinkedIn's own documentation for its messaging API states that a message must be associated with a specific member action, and then defines the boundary explicitly: member actions do not include an automated or scheduled event. That is a product document, not a legal one, and it draws exactly the line clause 26 implies.
That is not a passing remark. It sits in a list of seven requirements that together form a complete human-in-the-loop standard. A message must follow a specific member action. The member must opt in rather than opt out. If you show them a prepared draft they must be able to edit the subject, the body and the attachments. They must take an affirmative action to send. And the message must be posted at, or around the time, the member acted.
‼️ This is the strongest thing in the article, and it is an absence. LinkedIn plainly knows how to write an assisted-publishing standard, because it has written one. It specifies member initiation, an editable draft, affirmative consent and a timing rule. It has never written the equivalent for posts. Not in the API terms, not in the marketing terms, not in the posting documentation, not in the help centre. The distinction everyone in this category relies on, between a human approving content in advance and a machine posting unattended, exists in LinkedIn's documentation only for messages.
So there are two independent places where LinkedIn's own text treats scheduled, automated publishing as outside what it permits, and one place where it shows exactly how it would have carved out an exception if it wanted to.
What the scheduling partners have that you do not
The obvious objection is that LinkedIn publicly recommends third-party tools for scheduling posts, and those tools plainly exist. Both things are true, and the reconciliation is not published anywhere we can find.
The recommendation is real and it is on LinkedIn's own domain. A LinkedIn Pages blog post asks whether you can schedule posts on a company page and answers yes, with help from third-party tools that integrate through its community of marketing partners, then names ten of them. It was published on 6 October 2022, which is ten weeks before the clause was added.
The one mechanism in the document that could explain it is in section 1.2, which says the terms apply to any use of the APIs unless you have executed a separate signed partnership agreement. Partner agreements are not public. So the most likely explanation is that the large scheduling vendors sit on signed agreements that say something different from the public terms, and a self-serve developer does not.
We are labelling that as inference, not fact, and being precise about why. No public document says Hootsuite or Buffer hold such an agreement. The partner directory pages do not mention one, and the become-a-partner pages publish no criteria and no requirement for a signed contract. It is the only textual mechanism that could explain the coexistence, and there is no public evidence either way. That is an evidentiary hole, not a finding.
We also could not find any LinkedIn employee, anywhere public, addressing the clause. Not in the documentation, not on Microsoft Q and A, not in the docs repositories, not on the engineering blog. Every confident sentence in this category saying LinkedIn permits API automation traces back to a vendor rather than to LinkedIn. Anyone telling you the ban is really about unattended bulk posting is reasoning from the same absence we are, and presenting it as sourced.
What we can say plainly is that the self-serve grant of a posting permission is not a licence that overrides the clause. Those are two different documents doing two different jobs, and only one of them is a permission.
What Claude can actually publish
Setting the terms aside, the capability question has precise answers, and most guides are vague about the interesting half. Everything below is from LinkedIn's own API documentation.
| Possible? | Notes | |
|---|---|---|
| Text post | Yes | One API call |
| Post with an image | Yes | Three calls: start the upload, send the file, create the post |
| Multiple images | Yes | Two per image plus one. Organic only |
| Video | Yes | Four calls minimum, more for large files |
| Document, the creator carousel | Yes | A document upload. LinkedIn's own carousel type is ads-only |
| Poll | Yes | Organic only. Two to four options, 30 characters each |
| Long-form article | No | No endpoint exists. The article content type is a link card, not a body |
| Direct message | No | Approved partners only, and barred from automation |
| Post to a company page | No | Needs a reviewed approval and a page admin role |
| Scheduling | No | Nothing schedules. The only accepted state on creation is published |
| Comment or react | Unclear | Three LinkedIn pages name two different permissions for this |
Two of those deserve emphasis. There is no native scheduling of any kind, so every tool that offers it is holding your post in its own database and firing the call at the chosen moment, which is precisely the shape clause 26 describes. And mentions are close to unusable programmatically: they only render on an exact case-sensitive name match, and you need the target's internal identifier, which you cannot get self-serve for an arbitrary person.
There is also a ceiling. LinkedIn documents 150 requests per member per day for sharing. Since an image post costs three calls, that is roughly fifty image posts a day before you have read anything at all.
The connector most guides recommend cannot work on claude.ai
This is the most practically useful thing we found, and we have not seen it written anywhere.
Anthropic's documentation states that when you add a custom connector, Claude connects to your remote MCP server from Anthropic's cloud infrastructure rather than from your local device, and that this holds across every Claude client. Claude Code is the exception, because it runs on your machine.
‼️ Most open-source LinkedIn MCP servers are local. They drive a browser on your computer or read cookies from a file on it. Added as a custom connector, those cannot work on claude.ai, Cowork or mobile, because Anthropic's servers cannot reach your laptop. They do work in Claude Code, and in Claude Desktop if you configure them in its config file rather than through the connector interface. If you followed a tutorial, installed the most starred LinkedIn MCP server and could not get it to connect on claude.ai, this is why, and it is not your fault.
We went through which servers are local, which are hosted, and which credential each holds in which LinkedIn MCP servers stop working after 60 days.
Which plans, corrected
Two of the pages ranking for this question state that free Claude accounts cannot use custom remote MCP connectors. Anthropic's own support documentation says the opposite: custom connectors using remote MCP are available on Free, Pro, Max, Team and Enterprise, with free users limited to one.
- Free: one custom connector.
- Pro and Max: custom connectors, no documented limit on how many.
- Team and Enterprise: only workspace Owners can add a connector. Members then connect to it themselves, and admins can set a connector or an individual tool to require approval or block it outright.
- Claude Code: needs a paid plan or a Console account, and reaches servers on your own machine. Claude Desktop can too, but only through its config file, not through the connector interface.
- Claude in Chrome and Cowork: paid plans, and they drive the browser rather than calling an API.
Will Claude post something without asking?
Quick answer
Not on its own. A tool that writes should be annotated as destructive, and destructive tools always prompt before running, while read-only tools can run without per-call confirmation. A pure machine-to-machine credential grant is not supported, so every connection requires a person to consent.
The honest caveat is that those annotations are self-declared by whoever wrote the server. The protocol's own schema says the properties are hints, that they are not guaranteed to describe a tool's behaviour faithfully, and that clients should never make tool-use decisions based on annotations from untrusted servers. The defaults are cautious, so an author who annotates nothing gets the safe behaviour, but an author who mislabels a write tool as read-only gets the unsafe one.
The two things actually in your control: read what a tool does before you approve it, and be sparing with allow-always on anything that publishes.
Where we sit with this
Our MCP connector publishes to LinkedIn through the official API on the self-serve permission. That means clause 26 applies to us exactly as it applies to everyone else on that route, and when we publish on a schedule we are making the deferred automated call the clause describes. We would rather write that down than let you infer it.
It is a hosted server, so it works on claude.ai rather than only in Claude Code, and we never ask anyone for a session cookie. Our LinkedIn analytics do come from our own browser extension reading your own session, which is the separate exposure we set out in the terms article, and we say which half is which every time.
If none of that appeals, our Claude skills hold no credentials and call no API. Claude writes, you post. That is the third row of the table at the top, and it is genuinely the cleanest option available.
What to do next
- Decide whether you want Claude to draft or to publish. Drafting has no terms question, no expiry and no connector to maintain.
- If you want publishing, read clause 26 yourself rather than taking our word or anyone else's, and decide what you think about it.
- Check whether the server you are considering is hosted or local, because a local one will not work outside Claude Code.
- Put a reminder at day 55 for re-authorisation, because nothing will warn you.
- Discount any guide that quotes a restriction percentage. One ranking page gives a figure between 23 and 40 percent with no source behind it.
The question in the title is genuinely a yes. What nobody tells you is that the sanctioned route is the one with a clause pointed at it, the popular servers cannot reach the popular client, and the whole thing needs re-authorising every two months. None of that makes it a bad idea. It just makes the confident tutorials incomplete.
For the other platform, where access is metered rather than rationed, see what the Twitter API now costs. For what LinkedIn will and will not tell you about how your posts performed, see does LinkedIn have an analytics API.