stickerdaniel/linkedin-mcp-server: LinkedIn data for Claude through your own browser session

What stickerdaniel/linkedin-mcp-server actually does

LinkedIn publishes no public API for profile reading, job search or messaging. The practical alternative for an agent is a browser session that is already signed in, driven programmatically. This project wraps that idea in a Model Context Protocol server, so an MCP-compatible client such as Claude Desktop or Claude Code can call tools like get_person_profile, search_jobs or get_inbox instead of you copying text out of a tab.

The audience is narrow and specific. It is for engineers and analysts who already run an MCP client, who are willing to log in to LinkedIn in a browser the server controls, and who want structured output rather than screenshots. The README is explicit that this is an independent community project, not affiliated with, authorized by or endorsed by LinkedIn Corporation, and that the LinkedIn name is used descriptively. That disclaimer is the honest framing of what follows: you are automating your own account, with the account-level risk that implies.

The browser session is the whole architecture

There is no token exchange and no OAuth flow. The server launches Patchright, a Chromium automation stack, against a persistent profile directory. The default is ~/.linkedin-mcp/profile, and the .env.example notes that running with --login creates the profile through a browser login. Everything the tools return is scraped from pages that session can see, which is why the tool list mirrors LinkedIn's own navigation: profiles and their sections, company pages, the /people/ page for employees, job search and job details, the messaging inbox, the home feed, and the Posts tab search.

Two consequences follow. First, authentication is a human step, not a configuration value. The README states that the server opens a LinkedIn login browser window on the first tool call that needs authentication, and that early tool calls may return a setup or authentication-in-progress error until browser setup or login finishes. Second, the shared Chromium cache lives under ~/.linkedin-mcp/patchright-browsers, which is prepared in the background. Docker users get a headed browser on a virtual display that never appears on the host, per the note in .env.example, so the login flow has to be handled with that in mind.

The tool surface is broader than reading. connect_with_person sends a connection request or accepts one, send_message composes and sends, and get_sidebar_profiles pulls recommendation URLs from sections like "People you may know". The README flags a real defect in the messaging path: profile-based targeting may open a separate DM instead of replying in an existing thread, tracked as issue #483. If you plan to automate replies, that is the behaviour to verify first.

Installing it with uvx and running a first profile lookup

The README calls uvx the recommended universal setup. Install uv first, then register the server with your MCP client. The @latest tag turns on automatic updates, which the README says keeps the server working with LinkedIn's current page structure. If an AI agent is doing the editing, the README asks it to confirm with the user before enabling automatic updates.

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

The UV_HTTP_TIMEOUT value gives the first download room to finish. After the client restarts, ask it for a profile you can see yourself. A minimal first call is the authenticated user's own profile, which avoids depending on any particular person's page layout. The tool list documents get_my_profile as taking the same section selection as get_person_profile, and the README lists experience, education, interests, honors, languages, certifications, skills, projects, contact_info and posts as the selectable sections.

Expect a login window on the first authenticated call. If the tool returns a setup or authentication-in-progress error, that is documented behaviour, not a failure. Once login completes, the same call should return the sections you named. Section selection matters for cost: asking for fewer sections means less page work. The .env.example separates two timeouts that are easy to confuse. TIMEOUT is browser page-op milliseconds and defaults to 5000. TOOL_TIMEOUT is per-tool MCP execution seconds and defaults to 180.0, and the file says to raise it when heavy scrapes hit the FastMCP "Tool ... execution timed out" error.

For a container instead of uvx, the repository ships a compose file. It mounts ~/.linkedin-mcp into the container and passes proxy variables through.

services:
  linkedin-mcp:
    image: stickerdaniel/linkedin-mcp-server:4.24.2
    volumes:
      - ~/.linkedin-mcp:/home/pwuser/.linkedin-mcp
    environment:
      - LOG_LEVEL=WARNING

The compose comment warns that a proxy relay on the host must be addressed as host.docker.internal, not 127.0.0.1, because inside the container that address is the container itself.

Where this breaks, and when it is the wrong tool

The design has one structural failure mode: it depends on LinkedIn's page structure, and the README's own justification for the @latest tag is that automatic updates keep the server working when that structure changes. Read that as an admission. Any pinned version will eventually drift, and the failure will look like a tool returning empty sections rather than an error, which is harder to notice in an agent loop.

Account risk is the second limit. You are driving a real logged-in session, and the README does not document rate limits, retry policy or what happens when LinkedIn presents a security challenge. The --login wait defaults to 1800 seconds with 0 meaning no limit, precisely because 2FA, captcha and security challenges are expected. There is no documented rollback for a bad automation run, and send_message and connect_with_person are irreversible in the ordinary sense: the README does not describe an undo.

It is also the wrong tool for anything that needs a contract. If you are building a product feature that reads LinkedIn data for other people, or you need predictable throughput and an SLA, a scraping bridge over your own session is not the component to build on. The same applies if you cannot keep a persistent profile directory on the machine, since the session lives there and the .env.example notes that rotating or clearing a session deletes that directory and its parent.

The managed alternative the README points at

The README's sponsor section names Unipile as the fully managed cloud alternative, described as a hosted LinkedIn API for Classic, Sales Navigator and Recruiter that handles auth, sessions and infrastructure, with a 7-day trial. The difference in approach is not cosmetic. This project runs locally, uses your browser session, and stores state under ~/.linkedin-mcp. Unipile is hosted, so authentication and session maintenance move off your machine, and the README frames it as covering account tiers this project reaches only through the same scraping path.

That trade is worth naming plainly. You give up local control of the session and the data path, and you take on a vendor relationship, in exchange for not owning the breakage when LinkedIn changes a page. For a one-off research task on your own account, local is the smaller commitment. For a workflow that has to keep running unattended, the hosted route removes exactly the failure mode described above. The README presents Unipile as a sponsor, so treat the comparison as the project's own framing rather than a neutral evaluation.

Maintenance, licensing and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-09, days before this writing. Releases are frequent and versioned: v4.24.0 on 2026-09-07, v4.23.3 on 2026-09-02, v4.23.2 on 2026-09-01. The pyproject.toml declares version 4.24.2, so the published metadata and the release tag list are not perfectly in step, which is worth knowing if you pin by tag. The classifier is "Development Status :: 4 - Beta".

The upgrade story is unusually deliberate for a project this size. The Dockerfile pins the build backend against a hashed constraints file so the image does not resolve setuptools fresh from PyPI, and it installs the project with --no-deps so runtime dependencies stay exactly as the frozen lock installed them. The pyproject.toml carries a comment explaining that license-files is declared rather than left to setuptools defaults, because Apache-2.0 section 4(d) binds a derivative only to the notices the project actually distributes, and it notes the wheel and sdist were measured to carry NOTICE. If you fork or repackage, that NOTICE file is the thing to keep.

Licensing is Apache-2.0, which permits commercial use and modification with the usual notice and attribution conditions. Nothing here is legal advice, and the trademark disclaimer in the README is separate from the code licence: the software is Apache-2.0, the LinkedIn name is not yours to use freely. Python support is declared as >=3.12.4,<3.15.

Editorial conclusion

Adopt it if you want an MCP agent to read LinkedIn pages you can already open yourself and you accept that page structure changes will break tools until an update lands. Do not adopt it if you need a supported, rate-limited API with a contract, or if you cannot run a persistent browser profile on the machine. Before wiring it into anything, run the uvx config once, confirm the login window appears and that get_person_profile returns the sections you asked for, and check whether your client shows a confirmation prompt for send_message.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. stickerdaniel/linkedin-mcp-server on GitHub