How to Connect Claude (or ChatGPT) to LinkedIn: 4 Methods, Honestly Rated

You have Claude drafting your LinkedIn posts. Or ChatGPT. Either way the last mile is identical: copy the text, switch tabs, paste it into LinkedIn, fix the line breaks that came across wrong, hit publish. Which raises the obvious question — why can't the assistant just do that part too?

It can. But not through anything Anthropic or OpenAI built. Neither Claude nor ChatGPT ships a LinkedIn connector, LinkedIn publishes no server of its own, and every method that works today is third-party. There are exactly four of them, and they differ far less in what they can do than in what they cost you in account risk.

This page covers all four, rated honestly, plus what changes if you're on ChatGPT rather than Claude. (Facts verified 2026-07-28. This landscape changes monthly — check the date before trusting any guide on this topic, including this one.)

Key takeaways

• Neither Claude nor ChatGPT has a native LinkedIn connector, and LinkedIn ships no first-party MCP server. Everything that works is third-party.

• Four routes exist: a hosted MCP server from a LinkedIn tool, an open-source MCP server from GitHub, an automation bridge like Zapier or Composio, or no integration at all.

• The routes are close on capability and far apart on risk. The one question that separates them: does it act through LinkedIn's API with your authorization, or does it drive your logged-in session with your browser cookie?

• ChatGPT connects to remote MCP servers only, behind a developer-mode toggle. Claude connects to both remote and local servers. That single difference rules out most open-source options for ChatGPT users.

• Never give a publish-capable tool to an assistant that also reads untrusted documents, unless publishing is gated behind a confirmation that echoes the exact text.

• Connecting the assistant doesn't make it write like you. That's a separate problem, and it's the one that actually determines whether the posts are worth publishing.

Why neither Claude nor ChatGPT connects to LinkedIn out of the box

Both assistants have connector ecosystems, and neither includes LinkedIn. Anthropic's reviewed connector directory has no LinkedIn entry. OpenAI's first-party connectors cover Gmail, Google Calendar, Drive, Outlook, SharePoint, Dropbox, Box and Teams — productivity and storage, not social platforms.

This isn't an oversight in the plumbing. It's a consequence of how LinkedIn gates its API. Only two products are free and self-serve for any developer: Sign In with LinkedIn, and Share on LinkedIn. Share on LinkedIn grants the w_member_social permission, which LinkedIn's own documentation describes as "Post, comment and like posts on behalf of an authenticated member." That's the whole self-serve surface. Reading your own feed, pulling per-post analytics, touching anything about other members — all of that sits behind LinkedIn's Partner Program and an approval process.

So the asymmetry that shapes every route below: publishing to your own feed through the API is legitimate and available; almost everything else is not. Which is why the tools that do more than publish tend to do it by driving your logged-in browser session with a scraped cookie instead of calling an API — and why LinkedIn's User Agreement, which prohibits automated access outside approved interfaces, is the document that decides how much risk you're taking.

The four routes at a glance

Route 1: a hosted MCP server from a LinkedIn tool

Effort: low. Risk: low. Capability: high, but vendor-shaped.

A LinkedIn content tool runs an MCP server on its own infrastructure and gives you a URL. You add that URL to Claude or ChatGPT, authenticate against your account with that vendor, and the assistant gets a set of tools — typically draft, schedule, publish, list your posts, read your analytics. The vendor holds the LinkedIn connection; your assistant never sees a LinkedIn credential.

This is the lowest-friction route, and the safest one, because the vendor is acting through approved API access with authorization you granted — the same posture as using their web app, just driven from a conversation instead of a browser tab. Taplio ships a server like this today and it works from both Claude and ChatGPT, which makes it the live reference point for what this route looks like in practice. (We compare tools properly on our Taplio alternatives page.)

The honest limitation is structural. A hosted server is a remote control for that vendor's product. If the vendor's writing is generic, connecting it to Claude gets you generic writing faster. You inherit their scheduler, their analytics depth, their content model, and their subscription.

One disclosure, because it's relevant and you'd find out anyway: the ContentIn LinkedIn MCP server is not live yet. It's in build, with a waitlist. Everything in this section describing hosted servers describes a category that exists today; ours isn't part of it yet. Where we compare against tools you can install right now, we say so. If you want the setup detail for ours specifically when it opens, that lives in our pre-launch getting-started guide.

Route 2: an open-source MCP server from GitHub

Effort: medium. Risk: high. Capability: broad, in one specific direction.

Search "linkedin mcp server" and the top result is a GitHub repository, not a product. The best-known is stickerdaniel/linkedin-mcp-server, and looking at what it actually exposes is instructive. Its tools have included get_person_profile, search_jobs, get_job_details, get_company_profile, search_companies, get_company_employees, get_inbox, get_conversation, get_feed, and search_posts. This project ships frequent releases, so treat this as a snapshot rather than a fixed list — check the current README before relying on any specific tool being present or read-only.

Mostly missing, historically: publishing your own posts. These are largely research and prospecting tools, not writing tools. That's not a design accident — it's the API asymmetry from earlier, in reverse. Publishing has a self-serve API, so anyone can build it cleanly. Reading other people's profiles and your own feed does not, so the only way to build it is to drive a logged-in session. Worth noting: newer versions of this project have started adding limited write actions of their own, like sending connection requests — so "read-only" isn't guaranteed going forward either.

Which is exactly how it authenticates: the server runs locally and uses a browser session, either imported automatically from a browser you're already logged into or created with a manual login, then stored on your machine. The README is admirably direct about the consequence, and we'll quote it rather than paraphrase: "LinkedIn's User Agreement prohibits automated access, and accounts using automated tools can be restricted or banned. Use at your own risk; there is no guarantee of account safety."

People still choose this route, and the reasons are real ones. It's free, the code is readable so you can see exactly what it does with your session, it runs on your machine with no vendor in the middle, and it does things no API-backed server can offer because LinkedIn won't grant the access. For one-off research from a personal account, that's a defensible trade.

It's a bad trade for the account you make a living from. Restriction risk isn't proportional to how careful you are — detection keys on patterns of automated access, not on intentions. Weigh it as: free tool, uninsured downside on the asset the tool exists to grow.

Route 3: an automation bridge (Zapier, Composio)

Effort: low. Risk: low. Capability: narrow but real, metered per action.

Automation platforms have shipped their own MCP servers, which turns their existing app catalogue into tools your assistant can call. Zapier MCP connects Claude, ChatGPT, Cursor and others to thousands of apps using credentials you've already authorized; it runs on your existing Zapier task quota, with each MCP call consuming two tasks. On the LinkedIn side, Zapier's actions are Create Share Update and Create Company Update — publishing, and not much more.

Composio's LinkedIn toolkit goes deeper. It authenticates over OAuth2 and exposes roughly twenty tools, including creating a post, creating a comment, deleting a post, getting your own info and network size, retrieving a person's profile, uploading images, and reading share statistics — impressions, clicks, likes, comments and shares.

Both are low-risk in the way that matters: OAuth against approved API access, no cookie, revocable from your LinkedIn settings. And both fit well when LinkedIn is one node in a larger workflow — a blog post publishes, an assistant summarizes it, the summary goes out as a LinkedIn post.

They fit badly when LinkedIn is the workflow. A bridge is transport plus an app catalogue: no drafting intelligence, no queue of your own, no notion of your voice, no memory of what you posted last month. And per-action metering makes an iterative writing loop — draft, revise, revise again, schedule — quietly expensive in a way a flat subscription isn't.

Route 4: no integration at all

Effort: zero. Risk: zero. Capability: limited — and for a lot of founders, still the right answer.

We'll say this plainly, because most articles on this topic won't. If you post three times a week, the copy-paste step costs you roughly ninety seconds a week. An integration buys back those ninety seconds. It does not make the post better, it does not make you post more often, and it does not tell you what to write. If what's actually stopping you is deciding what to say, or looking at a draft and thinking "this doesn't sound like me," an integration is solving a problem you don't have.

Route 4 also has an advantage nobody lists: a human reads the exact final text every time, immediately before it becomes public. That's a real safety property, and the other three routes have to work to reproduce it — which is the subject of the safety rule further down.

Where an integration genuinely earns its place: you post daily, you work in long assistant sessions, you want scheduling and analytics in the same conversation as the drafting, and tab-switching is measurably breaking your rhythm. That's a real profile. It's just not everyone's.

What about ChatGPT?

Most guides on this topic are written for Claude and then quietly assume ChatGPT works the same way. It doesn't, and the differences change which routes are actually open to you.

What ChatGPT supports today

ChatGPT is a full MCP client, with two important constraints.

First, remote servers only. OpenAI's documentation requires that the server "is available at a public HTTPS endpoint" and that "the endpoint supports streamable HTTP, typically at /mcp." There is no equivalent of running a local process on your own machine and letting the client talk to it over stdio.

Second, custom servers sit behind developer mode. To connect one, per OpenAI's own instructions: "Open Settings. Select Security and login. Turn on Developer mode." Then you add the server from ChatGPT's plugins panel — the plus button, a user-facing name and description, and the public MCP server URL including the /mcp path. Developer mode is "available to Pro, Plus, Business, Enterprise, and Education accounts on the web."

Once it's on, write actions are supported: OpenAI states that "ChatGPT developer mode provides full Model Context Protocol (MCP) client support for all tools, both read and write," and that "write actions by default require confirmation." This is worth flagging because a lot of older advice says ChatGPT can only read. That was true of one specific integration path — deep research connectors, which require a server to implement exactly two read-only tools, search and fetch. Developer mode is a different door, and it opens onto the full tool surface.

OpenAI is blunt about the trade, and so are we: the documentation flags "elevated risk," including "model mistakes on write actions that could destroy data," prompt injections, and "malicious MCPs that attempt to steal information."

How the four routes map to ChatGPT

Route 1 works, provided the vendor runs a genuinely remote server. Hosted LinkedIn MCPs are built this way, so a URL you can paste into Claude is generally a URL you can paste into ChatGPT.

Route 2 mostly doesn't. Open-source LinkedIn MCP servers are local processes that read a browser profile sitting on your own machine. ChatGPT can't launch or reach them. You could host one on a public server to make it remote — but that means putting your LinkedIn session cookie on an internet-facing box, which takes an already-risky option and makes it materially worse. Don't.

Route 3 works well, and is arguably the most natural fit for ChatGPT. Zapier and Composio are remote-first by design and explicitly support ChatGPT alongside Claude.

Route 4 works everywhere, obviously, and remains the honest default for most people.

What differs from Claude in practice

Claude's connector story is broader. Custom connectors using remote MCP are available across Claude, Cowork and Claude Desktop, on Pro, Max, Team and Enterprise plans. Free accounts don't currently get custom remote MCP connectors, though Claude Desktop lets free users run local desktop extensions. Pro and Max users add a connector under Customize > Connectors; on Team and Enterprise an owner adds the server at the organization level and members connect individually. On top of that, Claude Desktop can run local servers configured in claude_desktop_config.json, and Claude Code can run local stdio servers from the command line.

The practical consequence: your choice of assistant narrows your options more than your choice of LinkedIn tool does. On a paid Claude plan, all four routes are open. On ChatGPT, it's realistically three — and the one that drops out is the free-to-run one (Route 2). If you're looking for a no-cost LinkedIn integration on either assistant, the honest answer is that the free route is the riskiest one, and the safer remaining choices are a vendor subscription or per-action metering.

How you actually wire an MCP server into a client

Nothing in this part is LinkedIn-specific, which is the point — the pattern is identical for every MCP server, so it stays true as the LinkedIn options change.

Three moves, always: point the client at a server, authenticate, let the client discover the tools. A remote server is a URL plus an auth header or an OAuth flow. When the client connects, it asks the server what tools it offers and what arguments each takes; those tools appear in the client's menu and become callable mid-conversation. You never write per-tool configuration — that discovery step is the whole reason the protocol exists.

In Claude Code, adding a remote server is one command:

claude mcp add --transport http <name> <url>

With a token, if the server uses API-key auth rather than OAuth:

claude mcp add --transport http <name> <url> --header "Authorization: Bearer your-token"

Then /mcp inside a session lists your servers, shows the tool count for each, and handles OAuth sign-in where the server supports it.

In Claude Desktop or Claude on the web, it's Customize > Connectors > add a custom connector, paste the server URL, and complete the OAuth flow if there is one. Local servers on Desktop go in claude_desktop_config.json instead, under an mcpServers key, and need a full restart of the app to appear.

In ChatGPT, it's developer mode, then the plugins panel, then the URL — as described above, including the /mcp path.

One configuration detail that catches people out when they copy a JSON snippet from a server's docs: an entry with a url but no type is a configuration error, because the client reads a type-less entry as a local command-line server. The MCP specification calls the transport streamable-http; Claude Code accepts that as an alias for http, so snippets copied from server documentation generally work unchanged.

What the assistant can and can't do once it's connected — and the one safety rule

With a well-built hosted server connected, the assistant can draft a post in the thread, publish it, schedule or reschedule it, list what's queued and what's live, and read the analytics on posts you've already published — assuming the vendor has the API access for that last one, which not all do.

It generally can't handle images, carousels or video from the conversation; media upload is multi-step and most servers leave it in the product's own interface. It can't read other people's analytics or private data through an API-backed server, because that access doesn't exist to grant. And it can't see anything about how your posts performed unless the server explicitly exposes that.

There's also a quiet ceiling worth knowing about: LinkedIn doesn't publish a standard rate limit for the Share API — each app's limit is set per app and visible only in that app's own Developer Portal Analytics tab. Whatever it is, you're very unlikely to hit it just by posting a few times a day. A tool that retries aggressively on errors is what actually burns through it.

Now the rule that matters more than any of the above.

Never grant a publish-capable tool to an assistant context that also ingests untrusted content, unless publishing is gated behind an explicit confirmation that echoes the exact text back to you.

The reason is prompt injection, and it isn't hypothetical — both vendors warn about it in their own connector documentation. Anthropic's guidance on custom connectors notes that "malicious MCP servers may include hidden instructions that try to make Claude perform unintended actions." OpenAI flags the same class of risk for developer mode. The failure mode is mundane: you paste in a competitor's landing page, or ask the assistant to summarize a PDF someone emailed you, and that document contains text addressed to the model rather than to you. If the assistant holds a publish tool, a bad outcome is one tool call away — and it's public.

Two cheap mitigations. Only use servers where publishing requires confirmation and shows you the full text it's about to send — not a summary of it, the text. And keep publish-capable connections out of research threads: drafting your own post from your own material is a different context from reading things off the internet, and they shouldn't be the same conversation.

What connecting does not fix

Here's the thing that gets lost in every "connect your AI to LinkedIn" guide, including the ones with better screenshots than this one: MCP is plumbing. It moves text from a conversation to a feed. It has no opinion about whether the text is any good.

If Claude was writing posts that sounded like a LinkedIn thought-leadership template before you connected it, it will now publish posts that sound like a LinkedIn thought-leadership template, faster and with less friction. The transport was never the bottleneck. What the model knows about how you write is the bottleneck, and no amount of wiring addresses it.

That gap has a name and a body of practice behind it — see our glossary entry on AI voice matching. The short version: a model trained on your own published posts, held to explicit rules derived from your actual patterns, produces something recognizably yours. A model given a good prompt produces something recognizably generic. That's the problem ContentIn's AI LinkedIn post generator was built around, and it's live today — unlike any MCP server we're building.

There's a second gap, less discussed: a connected assistant still forgets. Every conversation starts cold, and nothing you learn from how a post performed feeds into the next one. For the wider toolkit this sits inside, our guide to LinkedIn automation tools covers the landscape beyond MCP.

Troubleshooting

The server doesn't appear after you add it. For Claude Desktop, quit and relaunch the app fully — closing the window isn't enough. For a JSON entry, check that a remote server has both a url and a type; an entry with a URL and no type is read as a local command and skipped. In Claude Code, /mcp shows connection state and tool counts per server, which tells you whether the problem is connection or discovery.

Authentication fails or silently expires. OAuth tokens expire; reconnect from the connectors panel rather than re-adding the server. If the server uses an API key, confirm the header name the server expects — Authorization: Bearer and a custom header like X-API-Key are both common and are not interchangeable.

The assistant sees the tools but won't call them. Usually the request is ambiguous. Name the action: "publish this to LinkedIn using the LinkedIn tool," not "post this." If the client shows the server as connected with zero tools, the server is up but not advertising a tool surface — that's a server-side problem, not yours.

Rate limits. If publishing fails intermittently rather than consistently, suspect throttling rather than auth. LinkedIn doesn't publish a standard member-level cap on the Share API — it's set per app and visible in your Developer Portal's Analytics tab — and a retry loop can burn through it faster than you'd expect.

It works in Claude Code but not in ChatGPT. Almost always the local-versus-remote split. If the server runs as a command on your machine, ChatGPT can't reach it, and no amount of configuration will change that.

Frequently asked questions

Can Claude post to LinkedIn on its own?

Only through a third-party MCP server that you connect and authorize, and only if that server exposes a publishing tool. Claude has no built-in ability to reach LinkedIn. A well-designed server also requires you to confirm the exact text before anything goes live, so "on its own" should never be literally true.

Can ChatGPT post to LinkedIn?

Yes, with the same caveat. ChatGPT supports remote MCP servers through developer mode, which provides full read and write tool support, with write actions requiring confirmation by default. Connect a hosted LinkedIn MCP server or an automation bridge like Zapier or Composio, and ChatGPT can publish to your feed. What it can't do is run a local open-source LinkedIn server, because ChatGPT only accepts remote HTTPS endpoints.

Is there an official ChatGPT LinkedIn integration?

No. LinkedIn is not among OpenAI's first-party connectors, and OpenAI has not shipped a LinkedIn integration of its own. Any ChatGPT LinkedIn integration you find is a third-party MCP server or automation bridge that you add yourself — and the same API-versus-scraping question applies to it as to anything you'd connect to Claude.

Does Claude have a LinkedIn connector?

Not a native one. Anthropic's reviewed connector directory contains no LinkedIn entry. What people mean by "the Claude LinkedIn connector" is a custom connector: a third-party remote MCP server you add yourself under Customize > Connectors.

Is connecting an AI assistant to LinkedIn against LinkedIn's terms?

It depends entirely on how the server connects, not on MCP itself. A server acting through LinkedIn's API with permissions you explicitly granted is performing member-authorized actions on your own content — the same posture as using that vendor's web app. A server that automates your logged-in session with a scraped cookie falls under the automated-access restrictions in LinkedIn's User Agreement and carries real account risk. Check which one you're installing before you install it; the README usually says, but rarely at the top.

Does this work in Claude Code, Claude Desktop, and Claude on the web?

Remote servers work across all three, plus Cowork, on Pro, Max, Team and Enterprise plans. Free accounts don't currently support custom remote MCP connectors. Local servers are Desktop and Claude Code only. The configuration surface differs (a command in Claude Code, a settings panel on web and Desktop) but the server is the same server.

Do I need an API key, or a LinkedIn developer account?

You never need a LinkedIn developer account — the vendor holds the API access and you simply authorize their app against your normal LinkedIn login, the same way any "sign in with LinkedIn" flow works. Whether you need an API key depends on the server: some use OAuth end-to-end, some issue you a key to paste into an auth header. Open-source servers typically want neither, because they want your session cookie instead, which is the thing to be careful about.

Where ContentIn fits

To restate it clearly, since this is the section where you'd expect the pitch: the ContentIn LinkedIn MCP server is not live yet. It's in build, with a waitlist. We're not going to describe it as something you can install today, and we'd rather you picked Route 3 or Route 4 this week than waited on us.

What we'll say about the design, because it's the reason we're building it at all: the interesting question about a LinkedIn MCP was never "can it post?" — four routes can already post. It's what the thing on the other end knows about how you write, and whether anything you say in a conversation ever makes it back into your own content system instead of evaporating when the thread ends. That's the gap we're building into, and publishing will be gated behind an explicit confirmation that echoes the exact text, for the reasons in the safety section above.

If that's the version you want, join the waitlist — you'll get setup instructions the moment access opens. And if the actual problem is that the drafts don't sound like you, that part is solved and shipping: start a trial and train it on the posts you've already written.