LinkedIn MCP: which server to pick and how to install it in 2026

You want an AI assistant like Claude to read LinkedIn profiles, draft a follow-up or publish a post for you, without manual copy-paste. A LinkedIn MCP server does exactly that: it exposes your LinkedIn actions (profiles, messaging, publishing, enrichment) as tools an assistant can call through the Model Context Protocol. As of November 2026, no server is official; eight third-party projects now cover the market, split across three technical families, with a Terms of Service footprint that changes completely depending on which family you install. This article lays out the comparative table, a verified Claude Desktop setup procedure, the exact LinkedIn ToS language, and a role-based pick list for B2B growth teams.

What is a LinkedIn MCP server, and why is there no official one

A LinkedIn MCP server connects an AI assistant (Claude Desktop, Claude Code, ChatGPT with connectors, Cursor, Codex, Gemini CLI, Windsurf, Cline) to LinkedIn through the Model Context Protocol, the open standard Anthropic released on November 25, 2024. The server holds LinkedIn credentials and only exposes tools to the assistant: search a profile, send a message, publish a post, list an inbox.

LinkedIn publishes none. ContentIn states it plainly: « LinkedIn offers no official MCP server; every available option is third-party » (ContentIn, 2026-10-30). The market therefore splits between open-source GitHub projects and vendors (ContentIn, Unipile, GTM API, Derrick, Zapier) that expose their existing LinkedIn integration as an MCP server.

For broader context on how AI assistants plug into a B2B growth stack today, read our State of AI Marketing 2026 and how to transform your B2B strategy with AI.

The three families of LinkedIn MCP servers in 2026

LinkedIn MCP servers fall into three technical families, and each family inherits the ceiling of what it drives. Picking the family is the first decision, because it fixes both the account risk and the functional scope.

Family 1, browser automation. A headless driver signs into a real LinkedIn account with a session cookie (`li_at`) or a login window. Upside: reads everything the user sees, including Sales Navigator. Downside: « A standard account is flagged after around 80 to 100 profile views per day » per Derrick (2026-09-28), and LinkedIn tightened its stance on Playwright scrapers in late 2025, forcing servers to migrate to Patchright, a fork built to evade bot detection.

Family 2, official API. The server calls LinkedIn partner endpoints through OAuth, scope `w_member_social` to publish on a member's behalf. ToS-compatible. Known limit: `/v2/search/people` is not a documented public endpoint, so cold profile search is not viable on the official API without Marketing Developer Platform or Sales Navigator API access.

Family 3, native enrichment or bridge. The server queries third-party sources (Unipile, GTM API, Derrick) or routes actions through an aggregator (Zapier MCP, Composio) that relays to the platform's existing LinkedIn integration. No cookie on your side, no scraping; cost is credits or a subscription, and scope is capped by what the vendor already supports.

8 LinkedIn MCP servers compared in 2026

No top-ranking page lines up these eight projects side by side with authentication, license, starting price and ToS posture. Here's the chiffred view, accurate as of 2026-11-10.

Quick read: Family 1 (stickerdaniel) covers the widest LinkedIn surface but puts your account under § 8.2 of the User Agreement. Family 2 (Dishant27, felipfr) stays compliant but loses cold profile search. Family 3 (Unipile, GTM API, Derrick, ContentIn, Zapier) costs a subscription and shifts the ToS responsibility toward the vendor, within a scope the vendor has already fixed.

How to install a LinkedIn MCP server in Claude Desktop (verified setup)

Three steps are enough: create the authentication on the LinkedIn side (cookie or OAuth), paste a JSON block into `claude_desktop_config.json`, restart Claude Desktop. The config file lives at `~/Library/Application Support/Claude/` on macOS and `%APPDATA%/Claude/` on Windows. For an HTTP client like Claude Code, the command is `claude mcp add --transport http …` and the consent happens via `/mcp` during the session.

Family 1 example: stickerdaniel (uvx, local cookie or login)

1. Install uv (Python manager), then paste this block into `claude_desktop_config.json`:

   {
     "mcpServers": {
       "mcp-server-linkedin": {
         "command": "uvx",
         "args": ["mcp-server-linkedin@latest"],
         "env": { "UV_HTTP_TIMEOUT": "300" }
       }
     }
   }

2. On first launch, the server either opens a LinkedIn login window or imports the `li_at` cookie from a signed-in local browser. The session is saved under `~/.linkedin-mcp/profile/`.
3. In Claude Desktop, confirm that the 25 tools (profiles, messaging, companies, jobs, feed, search) appear in the MCP list.

Reminder from the stickerdaniel README: « LinkedIn's User Agreement prohibits automated access », « accounts using automated tools can be restricted or banned ». Set up a proxy before `--login` to avoid a LinkedIn checkpoint.

Family 3 example: GTM API (HTTP hosted, OAuth consent)

1. Create a GTM API account (the free Sandbox covers one connected account).
2. In Claude Desktop, add the server through the matching HTTP command with the endpoint `https://mcp.gtm-api.com/mcp`. Consent is granted in the browser; no key is pasted on the client side.
3. For a local CLI (Claude Code headless, for example), run `GTM_API_KEY=gtm_live_xxx npx -y @gtm-api/linkedin-mcp` and let the server handle the token.

To revoke, the connection is removed either from the member's LinkedIn settings or from the GTM API dashboard. A LinkedIn OAuth access token lives 60 days (`expires_in: 5184000`); refresh goes through a new authorization request.

What the LinkedIn Terms actually allow: § 8.2, § 3.1, API Terms

MCP is only a transport; what the LinkedIn ToS targets is what you plug behind it. ContentIn's 2026-07-28 ToS reading sorts the use cases into three categories, and the literal English clauses are easier to defend than any paraphrase.

Operational translation: a Family 1 server falls under § 8.2 the moment it drives your session. A Family 2 server stays inside the `w_member_social` scope as long as it publishes your own content, not someone else's. A Family 3 server shifts ToS responsibility to the vendor, but you remain accountable for what the agent triggers. This is not a legal opinion; it is the grid ContentIn builds from the clauses, and it matches what the open-source READMEs themselves warn against.

For the broader question of what AI can safely own on LinkedIn without breaking your reach, read the end of free LinkedIn reach.

Which LinkedIn MCP server for your growth role

The server to install depends first on the role that will use it and the risk zone they can own. Role-based pick list, built on the families defined above.

Two practical rules follow. First, an SDR targeting prospecting volume is best served by native enrichment, not scraping; B2B prospecting, multichannel and AI-led is built on this type of source. Second, a content creator automating publishing stays inside the `w_member_social` scope, which is what our LinkedIn content strategy 2026 guide recommends.

Guardrails before letting an agent publish to your LinkedIn account

Three technical guardrails, non-negotiable, for any MCP stack that touches LinkedIn.

Preview, then confirm. Every publish, invite or message action is shown back to the user in text before it goes out. GTM API writes it on its page: « outward actions go through a preview → confirm step and a server-side daily-limit check before reaching LinkedIn ». This pattern is the one our data and AI expertise enforces in every agent workflow plugged into a social platform.

Server-side rate limit. LinkedIn caps invites, InMails and profile views. Treat every quota error as a stop, never as a retry loop (rule stated verbatim by Unipile).

No third-party profile storage. API Terms § 4.1: « You must not capture, copy, cache, or store any Content. » Search results are read, pushed into the next action, forgotten. No hidden profile database on the MCP side, and one API key per connected account, never a global key shared with an MCP client.

On our side, Bulldozer runs its own tools through MCP (more than 500 Bulldozer tools exposed as `mcp__bulldozer__` to Claude Code, LinkedIn Ads included), orchestrated by agents that our team supervises. It is the same logic as a third-party LinkedIn MCP server, extended to the whole growth stack, with human validation before every publish.

Key takeaways

• A LinkedIn MCP server is a transport, not a product: three families (browser, official API, enrichment) decide both the risk and the scope.
• No official LinkedIn server in November 2026; eight serious projects share the market, three open-source and free, five hosted and paid (ContentIn, Unipile, GTM API, Derrick, Zapier MCP).
• A LinkedIn account scraped via Family 1 is flagged around 80 to 100 profile views per day; publishing via `w_member_social` (Family 2 or 3 API-backed) stays within the ToS scope.
• Claude Desktop setup: JSON block in `claude_desktop_config.json`, restart, test one tool; for Claude Code, `claude mcp add --transport http` and OAuth consent.
• Three guardrails before opening an agent on your account: preview → confirm, server-side rate limit, zero third-party profile storage.

A LinkedIn MCP server alone solves the transport; it does not solve orchestration (which playbook, which validation, which measurement) or compliance (ToS, GDPR, AI governance). If you want to plug an AI agent into LinkedIn inside your growth stack without running the plumbing yourself, look at Bulldozer OS: AI agents connected to your tools, supervised by a Bulldozer expert, nothing goes out without human validation.