linkedin-mcp-server: a browser-session MCP bridge to LinkedIn, and what it costs you
Open-source MCP server for LinkedIn. Give Claude and any MCP-compatible AI agent access to profiles, companies, jobs, and messages.
At a glance
- What is it?
- The project exposes LinkedIn profiles, companies, jobs and messages to Claude and other MCP clients by driving a real logged-in Chromium session through Patchright. The tool surface is broad and the install path is short, but the whole design rests on a browser session you have to keep alive and on page structures the project does not control.
- Who is it for?
- Adopt it if you want LinkedIn data inside an MCP client and you are willing to own a local browser session, a Chromium cache under ~/.linkedin-mcp/patchright-browsers, and the maintenance that automatic updates imply. Do not adopt it if you need a supported, contractual data path, or if sending messages and connection requests from an agent without a human in the loop is unacceptable in your setting.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What problem the server actually removes
LinkedIn data is not reachable from an MCP client by default. There is no official MCP server from LinkedIn Corporation, and the README states plainly that this is an independent community project, not affiliated with, authorized by, endorsed by or sponsored by LinkedIn or Microsoft. So the practical problem is narrow: an engineer has an MCP-compatible assistant, wants it to answer questions about a person, a company, a job posting or an inbox thread, and has no sanctioned tool to hand it. This project fills that gap by reusing the one access path most individuals already have, their own logged-in browser session, and wrapping it in MCP tool calls. The intended user is an individual practitioner or a small team running Claude Desktop, Claude Code, Codex or another MCP host locally. It is not aimed at a platform team that needs a governed data pipeline with an SLA, and nothing in the material suggests it is meant to be one.
The mechanism: Patchright, a persistent Chromium cache and your session
The server does not call a LinkedIn API. According to the README it drives a shared Patchright Chromium browser cache, prepared in the background under ~/.linkedin-mcp/patchright-browsers, and it opens a LinkedIn login browser window on the first tool call that needs authentication. Everything downstream, profile sections, company pages, job search, the messaging inbox, the home feed, is read through that browser context. That single design decision explains most of the project's behaviour. It is why the README can promise access to data that an API would not expose, and it is also why early tool calls may return a setup or authentication-in-progress error until browser setup or login finishes. The README notes that a session can be created explicitly if you prefer not to wait for the lazy path, and there is a close_session tool for tearing the browser down and cleaning up resources. The tool list is section-aware rather than page-dump: get_person_profile and get_my_profile accept an explicit selection from experience, education, interests, honors, languages, certifications, skills, projects, contact_info and posts, and get_company_profile offers posts and jobs. That matters because it lets the caller limit how much of a page is parsed, which is the closest thing here to a cost control.
Getting it running with uvx, Docker or a bundle
The README labels uvx the recommended universal path and requires uv to be installed first. The client configuration it gives is a JSON block with a command of uvx and args of ["mcp-server-linkedin@latest"], plus an env entry setting UV_HTTP_TIMEOUT to 300. The @latest tag is deliberate: the README says it turns on automatic updates, which keep the server working with LinkedIn's current page structure, and it adds a note aimed at AI agents to get user confirmation before enabling automatic updates. That is an honest framing of a real dependency, since the server is coupled to markup it does not own. Alternative install paths listed in the README are a Claude Desktop MCP bundle (formerly DXT), a Codex plugin, a Docker setup, and a local development install for contributing. The package is published on PyPI as mcp-server-linkedin, and the repository carries CI and release workflows. Beyond the uvx block and the ~/.linkedin-mcp/patchright-browsers cache path, the supplied README does not show the per-client configuration for the bundle, Codex or Docker routes, so treat those as documented but not reproducible from this material alone.
Write tools are the part to think hardest about
Reading profiles is one risk profile; sending connection requests and messages is another. The tool list includes connect_with_person, which sends a connection request or accepts an incoming one with an optional note, send_message, and get_sidebar_profiles, which pulls profile URLs out of sidebar sections such as People you may know. The README states that send_message requires confirmation, and it flags a known issue: profile-based targeting may open a separate direct message instead of replying in an existing thread, referencing issue #483. That is a concrete failure mode, not a hypothetical one, and it means an agent instructed to reply to a thread can create a new one instead. The confirmation step is a mitigation, not a guarantee, and it depends on the host client surfacing the confirmation properly. If your use case is a recruiting or outreach workflow where a stray DM is a real cost, the write side of this server deserves a stricter review than the read side, and the README does not describe rate limiting, per-action quotas or an audit log.
Where the browser-session approach breaks down
The honest limitation is that this is a scraper wearing an MCP interface. The README's own justification for the @latest tag is that updates keep the server working with LinkedIn's current page structure, which is an admission that page changes break tools. A layout change to the messaging inbox or the people search results can degrade a tool without any version bump on the server side. The second limitation is session lifetime. Authentication is a browser login, the Chromium cache lives under ~/.linkedin-mcp/patchright-browsers, and the README warns that early calls may fail with a setup or authentication-in-progress error. Any headless or containerised deployment has to solve login persistence, and the supplied material does not describe how the Docker path handles that. Third, this is the wrong tool when you need reliability guarantees, when multiple users must share one integration under separate identities, or when the data has to be defensible in a compliance review. A local browser session tied to one person's account is the opposite of that.
Unipile is the managed alternative, and the README says so
The README sponsors Unipile and describes it directly: a hosted LinkedIn API for Classic, Sales Navigator and Recruiter that handles auth, sessions and infrastructure for you, with a seven-day free trial. The difference in approach is the whole story. This project runs locally on your machine, uses your own browser session, and is free and open source under Apache-2.0. Unipile runs in the cloud, owns the authentication and session lifecycle, and is a paid managed service. The trade is control and cost against operational burden. With the local server you keep the session, the credentials and the traffic on your hardware, and you accept that you maintain the browser cache and absorb breakage when LinkedIn changes a page. With the hosted option you outsource session handling and infrastructure, and you accept a vendor in the path plus a commercial relationship. Neither is strictly better; they fail in different places. Note also that the sponsorship is disclosed in the README itself, which is the correct way to handle it, and that the sponsor link is the only alternative the project names.
Licence, maintenance and what a version number buys you
The repository is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, but it also means the maintainers offer no warranty. The README's disclaimer is separate from the licence and worth reading on its own: the project is independent and not affiliated with, authorized by, endorsed by or sponsored by LinkedIn Corporation or Microsoft, and the LinkedIn name is used descriptively to identify the third-party service the software interoperates with. Nothing in the material says whether using an automated browser session against LinkedIn is permitted under LinkedIn's own terms; that question is outside the scope of the repository and you should resolve it before deploying this in a commercial setting. On maintenance, the release cadence is visible in the supplied data: v4.24.0 on 2026-09-07, v4.23.3 on 2026-09-02, v4.23.2 on 2026-09-01, with the last push to main on 2026-09-09. That is a fast patch rhythm, which is consistent with a project that has to chase page changes, and it also means the surface you integrate against moves often. Pinning a version protects you from surprise changes but also from the fixes that keep the tools working, so the choice is between two kinds of breakage rather than between breakage and none.
Editorial conclusion
Adopt it if you want LinkedIn data inside an MCP client and you are willing to own a local browser session, a Chromium cache under ~/.linkedin-mcp/patchright-browsers, and the maintenance that automatic updates imply. Do not adopt it if you need a supported, contractual data path, or if sending messages and connection requests from an agent without a human in the loop is unacceptable in your setting. Before wiring it into anything, run one read-only call such as get_person_profile through uvx, confirm the login browser window opens and completes, and check that the sections you actually need are returned rather than the setup-in-progress error the README warns about.
Community notes