A LinkedIn MCP server is a third-party bridge that exposes LinkedIn actions, profile lookups, job search, messaging, posting, as tools an AI agent like Claude can call through the Model Context Protocol. Several real open-source and hosted options exist, and each makes a different tradeoff between feature breadth and how closely it follows LinkedIn's own terms of service.
TL;DR
MCP is Anthropic's open standard (introduced November 2024) for connecting AI assistants to external tools without a custom integration per app. A LinkedIn MCP server applies that standard to LinkedIn: real projects exist on GitHub and via Composio, using either a browser session (broad access, closer to ToS risk) or LinkedIn's official Community Management API (narrow access, closer to compliant). Setup takes about 10 minutes for the simplest servers. Read the ToS section before you point any of them at your primary account.
Anthropic introduced the Model Context Protocol as an open standard for connecting AI assistants to the systems where data actually lives: content repositories, business tools, developer environments, and consumer platforms like LinkedIn. The often-repeated analogy is a USB-C port for AI applications, one connector shape instead of a different cable for every device.
The protocol has three architectural pieces. The host is the application a person actually uses (Claude Desktop, Claude Code, Cursor). The client is the connection logic inside the host that speaks MCP to one specific server. The server is the process that exposes tools, resources, and prompts to the model. When someone says "LinkedIn MCP server," they mean the third piece: a server whose tools happen to call LinkedIn.
Depending on the project, a LinkedIn MCP server can expose profile and company lookups, job search with filters, message inbox reads and sends, feed retrieval, and post creation. No single server exposes all of these; each project picks a subset based on its auth method, since LinkedIn's official API surface is much narrower than what a logged-in browser session can technically reach.
These are actual, web-verified projects as of mid-2026. None are built or endorsed by LinkedIn. Auth method is the column that matters most for account risk.
| Server | What it exposes | Auth method | Notes |
|---|---|---|---|
| stickerdaniel/linkedin-mcp-server | Profiles, companies, jobs, messages, and feed content | Browser session (interactive login or cookie import) | The most actively documented open-source option. Installs via uvx or a Docker MCP Toolkit image, stores a persistent session at ~/.linkedin-mcp/, and its own README states plainly that automated access can get an account restricted. |
| fredericbarthelet/linkedin-mcp-server | user-info and create-post, backed by LinkedIn's Community Management API | OAuth 2.0 via the draft MCP third-party authorization flow | Uses LinkedIn's own API rather than a browser session, which is the closer-to-compliant path. The tradeoff is a much smaller tool set and a LinkedIn Developer app you must register and get approved yourself. |
| Composio LinkedIn MCP toolkit | 22 tools covering posts, comments, articles, analytics, and ad targeting | Managed OAuth 2.0 (Composio handles token refresh) | A hosted, managed alternative rather than something you run yourself. Aimed at agent builders who want LinkedIn actions wired into Claude Code or Cursor without maintaining a server. |
| Community scraper-style servers | Profile, job, and company search; some add resume or outreach helpers | Typically session cookies or an unofficial API wrapper | Smaller projects like felipfr/linkedin-mcpserver, Dishant27/linkedin-mcp-server, and eliasbiondo/linkedin-mcp-server exist and work, but maintenance and auth approach vary project to project. Read each README's auth section before trusting it with a real account. |
Lifast generates on-brand LinkedIn posts and lead magnets from your product, without an agent operating your live logged-in session.
Try Lifast Free90 days of consistent posting. No ads.
"Build MCP Server: Claude Reads LinkedIn Profiles" by AI Anytime, published March 13, 2025. A hands-on walkthrough of wiring an MCP server to fetch LinkedIn profile data for Claude.
This sequence works across most local MCP servers, whether the specific project you pick uses browser-session auth or an official API.
Pick an MCP-compatible client
Claude Desktop, Claude Code, and Cursor all support loading external MCP servers through a config file or connector menu. Confirm your client supports local (stdio) MCP servers, not only remote ones, since most LinkedIn MCP servers run locally.
Install a package runner
Browser-session servers like stickerdaniel/linkedin-mcp-server ship as a uv/uvx package, so install uv first (a single command on macOS, Linux, or Windows). API-based servers like fredericbarthelet's need Node 22 and pnpm instead.
Choose your auth path deliberately
This is the decision that matters most. Browser-session auth is faster to set up and exposes more of LinkedIn's surface (messaging, feed, company data) but runs closer to what LinkedIn's User Agreement calls automated access. The official Community Management API path is narrower (mostly posting and basic profile reads) but works within a sanctioned developer program.
Run the server manually once
Before wiring it into your AI client, run the server directly from a terminal. For a cookie-based server this means confirming the login flow completes and a session file lands in your home directory. For an OAuth server this means confirming the redirect and token exchange work against your own registered LinkedIn app.
Add the server to your client's MCP config
Most desktop clients read a JSON config file. You add an entry under a top-level mcpServers key naming the command and arguments needed to start the server (see the config snippet below).
Fully restart the client
MCP servers are typically loaded once at startup. A simple app reload sometimes is not enough, quit the client entirely and reopen it so it re-reads the config and spawns the new server process.
Confirm the tools actually appear
Open the client's tool, connector, or MCP inspector panel and check that LinkedIn-specific tools (profile lookup, job search, create-post, and so on) are listed. If nothing shows up, check the server's stdout for an auth error before assuming the config is wrong.
Test with a single read-only prompt
Ask the agent to look up one public profile or list your own recent posts. Read-only calls are the lowest-risk way to confirm the whole chain (client, config, server, LinkedIn session) is actually working end to end.
Set hard usage guardrails before any write actions
Decide a daily action cap before you let an agent send connection requests, messages, or posts on your behalf. Treat the agent the same way you would treat a junior assistant with your login: useful, but not unsupervised at scale.
Recheck the project's README periodically
LinkedIn MCP servers are maintained by individuals or small teams, not LinkedIn itself, and LinkedIn's detection systems change. A setup that worked cleanly in one quarter can trip a security checkpoint the next, so re-read the repo's issues tab before assuming nothing has changed.
A typical entry added to a client's MCP config file (for example claude_desktop_config.json) to register a locally-run LinkedIn MCP server installed via uvx. Exact keys vary by client and server, check the specific project's README.
{
"mcpServers": {
"linkedin": {
"command": "uvx",
"args": ["mcp-server-linkedin@latest"],
"env": {
"LINKEDIN_SESSION_DIR": "~/.linkedin-mcp"
}
}
}
}Hypothetical, plausible scenarios showing the shape of the work, not documented case studies.
Illustrative: recruiter profile triage
A recruiter connects a LinkedIn MCP server to Claude and asks it to pull structured data (headline, current role, tenure) for a shortlist of 15 candidates already sourced elsewhere, so the recruiter can scan a comparison table instead of opening 15 tabs.
Illustrative: sales rep account research
Before a discovery call, a sales rep has the agent fetch the prospect's company page (headcount, recent posts, leadership changes) and summarize it into three talking points, cutting pre-call research from 20 minutes to under 3.
Illustrative: content calendar drafting
A founder uses an MCP server with create-post access to let an agent draft a week of posts as unpublished drafts for human review, rather than auto-publishing, keeping a person in the loop on anything that actually goes live.
Illustrative: job search filtering
A job seeker asks the agent to search listings matching specific title and seniority filters and summarize which ones mention remote work, turning a repetitive search-and-skim task into one prompt.
Illustrative: engineering demo of the protocol itself
A developer builds a LinkedIn MCP server purely to learn MCP's request and response shape, using LinkedIn as a familiar API surface rather than because LinkedIn access is the actual goal.
LinkedIn's User Agreement prohibits automated access to the platform, and accounts using automated tools can be restricted or banned. Coverage of LinkedIn's 2026 enforcement describes updated detection deployed across all regions, suspicious sessions flagged within 48 hours, and first-time violations resulting in full suspension in some cases. This is a real risk, not a hypothetical one.
Treating browser-session auth as risk-free because it is not scraping in the technical sense
Running a real logged-in browser session under agent control is still automated access in LinkedIn's own terms, whether or not the code technically counts as a scraper.
Letting the agent send connection requests or messages at machine speed
Search coverage of 2026 ban waves repeatedly points to high action counts and suspiciously even timing (like a request every 90 seconds) as detection triggers, not any single action in isolation.
Skipping the README's auth section on a community server
Smaller, less-maintained LinkedIn MCP projects vary in how they authenticate and what data they cache locally. Read that section before pointing any of them at a real account.
Assuming an MCP wrapper makes an action compliant
MCP is a transport and tool-definition protocol. It says nothing about whether the underlying action against LinkedIn is allowed, that is entirely a function of which auth path and API the server actually uses.
Wiring write actions (post, message, connect) in before testing read actions
Read-only calls are reversible and low-stakes. Confirm the full chain works with reads before letting an agent write anything to a real profile.
Using a personal, primary LinkedIn account as the first test
If a test account or a low-stakes secondary profile is available, use it first. The account that gets flagged during a config mistake should not be the one carrying five years of professional network history.
No. Every LinkedIn MCP server discussed here is a third-party project built against either LinkedIn's public-facing web session or its Community Management API for developers. LinkedIn has not published its own MCP server or endorsed any of the community ones.
A browser extension runs inside your browser and typically acts on the page you are viewing. A LinkedIn MCP server runs as a separate process that an AI agent calls as a tool, letting the model chain LinkedIn actions together with other tools (a calendar, a CRM, a document) in one reasoning loop, not just one page at a time.
Yes, MCP servers are not complicated to scaffold once you have picked an auth method. The harder decision is still the same one: browser session versus official API, and that choice governs your ToS exposure regardless of who wrote the code.
A lot of people who go looking for a LinkedIn MCP server actually want a narrower outcome: more consistent posts and inbound leads, not an agent driving a real logged-in session. If that is the actual goal, a tool built specifically for LinkedIn content and lead-gen, like Lifast, gets there without any of the session-automation risk covered above, since it generates posts and lead magnets from your product rather than operating your account directly.
Anthropic's MCP announcement
The original November 2024 announcement defining the protocol, its goals, and the host/client/server architecture referenced throughout this page.
View the announcement →stickerdaniel/linkedin-mcp-server
Source for the browser-session auth flow, uvx install path, and the project's own explicit ToS risk warning quoted on this page.
View the repo →fredericbarthelet/linkedin-mcp-server
Source for the official-API path: Community Management API, OAuth 2.0, and the draft MCP third-party authorization flow.
View the repo →The Model Context Protocol is an open standard, introduced by Anthropic in November 2024, that gives any AI application a single, consistent way to connect to external tools and data sources instead of writing a custom integration for every pair of app and data source.
Before MCP, connecting an AI assistant to, say, a calendar, a database, and LinkedIn meant three separate bespoke integrations, each with its own auth handling and request format. MCP standardizes that into one protocol: a host application (like Claude Desktop) talks to one or more MCP servers, each of which exposes a defined set of tools, resources, and prompts the model can call.
A LinkedIn MCP server is simply an MCP server whose tools happen to wrap LinkedIn: profile lookups, job search, messaging, or posting, depending on which server and which auth path it uses. Nothing about MCP itself is LinkedIn-specific, LinkedIn did not build or endorse any of the servers named on this page.
Host: the AI application the person actually uses, such as Claude Desktop, Claude Code, or Cursor. The host is what reads the MCP config file and decides which servers to launch.
Client: the connection logic inside the host that speaks MCP to a specific server, usually one client instance per server.
Server: the process that exposes tools (actions the model can call, like create-post), resources (structured, file-like data the model can read), and prompts (reusable prompt templates) to the client. A LinkedIn MCP server's tools are what actually talk to LinkedIn, over a browser session or an API, depending on the project.
Every comparison of LinkedIn MCP servers eventually reduces to one question: does this server use LinkedIn's sanctioned API, or does it drive a real logged-in session the way a human browser would? The feature list (more tools, more data types) is usually inversely related to how compliant the auth path is, because LinkedIn's own Community Management API only exposes a narrow, approved slice of actions.
That tradeoff is the entire reason this page includes a ToS section instead of only a setup guide. Picking a LinkedIn MCP server is a risk decision about your account, not just a technical integration choice.
What people actually ask before wiring an AI agent into their LinkedIn account.
A LinkedIn MCP server is a Model Context Protocol server that exposes LinkedIn actions, such as profile lookups, job search, messaging, or posting, as tools an AI agent like Claude can call. It is not built or endorsed by LinkedIn; it is a third-party bridge between an MCP-compatible AI client and LinkedIn, using either a browser session or LinkedIn's own API depending on the project.
It depends on the auth method. Servers that drive a logged-in browser session (rather than LinkedIn's official Community Management API) fall under LinkedIn's User Agreement restrictions on automated access, and accounts using automated tools can be restricted or banned. Servers built on LinkedIn's official API and a registered developer app sit on firmer ground, though they expose far fewer actions.
For broad read access (profiles, jobs, companies, messages) with browser-session auth, stickerdaniel/linkedin-mcp-server is the most actively documented open-source option. For a narrower, API-backed path, fredericbarthelet/linkedin-mcp-server uses LinkedIn's Community Management API with OAuth. For a managed, hosted option with a large tool set, Composio's LinkedIn MCP toolkit handles OAuth and token refresh for you.
Not necessarily. Some servers install with a single command through uvx or a Docker MCP Toolkit image and configure through a JSON file, no custom code required. Building your own server (rather than using an existing one) does require development work, mostly in defining tool schemas.
Some servers, like fredericbarthelet's, expose a create-post tool, and Composio's toolkit exposes post, comment, and article creation among its 22 tools. Whether posts publish immediately or sit as drafts depends entirely on how you prompt the agent and which tool you invoke, there is no universal safeguard built into MCP itself.
If the actual goal is better LinkedIn posts and lead capture rather than raw account automation, a purpose-built tool that generates content and manages a calendar without operating your live session carries far less account risk than any MCP server driving a browser session. Tools like Lifast take that approach for LinkedIn content and lead-gen specifically.