linkedin-mcp-server

MCP Server for LinkedIn

Give your AI agents access to LinkedIn through your own browser session. Read profiles, research companies, find jobs, and manage conversations and connection requests.

This is an independent open-source project, not affiliated with LinkedIn or Microsoft. LinkedIn is a trademark of LinkedIn Corporation, used here only to identify the service this software interacts with.

Running LinkedIn agents in production? LinkupAPI is the hosted outreach API built for scale, across LinkedIn Classic, Sales Navigator, and Recruiter, plus email, WhatsApp, and iMessage.

Try LinkupAPI free →

Cadenza is the single hosted MCP server for all your LinkedIn needs. It covers Classic, Sales Navigator, and Recruiter with 100+ actions, each within limits you set. Works on web, desktop, and mobile.

Use code FOUNDING20 for 20% off your first year. Try Cadenza →

This MCP server is supported by Unipile. Unipile is the fully managed cloud option for developers: a hosted LinkedIn API for Classic, Sales Navigator, and Recruiter that handles auth, sessions, and infrastructure for you.

Try Unipile free for 7 days →

Zernio gives your agents official APIs for every social channel. Post, reply, and run ads on Instagram, TikTok, X, YouTube, Threads, and more, through one API or MCP server.

Try Zernio free →

---

Installation Methods - LinkedIn MCP Server

Tool	Description
get_person_profile	Read profile sections: experience, education, skills, projects, volunteering, posts.
get_my_profile	Read your own profile, with the same section selection as other profiles.
connect_with_person	Send a connection request with an optional note, or accept an incoming one.
get_sidebar_profiles	Find recommended profile links, including people you may know.
get_inbox	List recent inbox conversations, with links to open individual threads.
get_conversation	Read a conversation's messages using a LinkedIn username or thread ID.
search_conversations	Search messages by keyword and return links to matching conversation threads.
archive_conversation	Archive a conversation by thread ID; a repeat call reports it already archived.
send_message	Send after confirmation; profile targets may open a new DM (#483).
reply_to_conversation	Reply inside an existing thread or InMail by thread ID. Sends after confirmation.
get_company_profile	Read company information, with optional sections for posts and open jobs.
get_company_posts	Read recent posts from a company's feed, with links to the original posts.
search_companies	Find companies by keyword and return links to their LinkedIn profiles.
get_company_employees	Find company employees, optionally filtered by name, title, or skill.
search_jobs	Find job postings by keyword and location, with job IDs for reading details.
get_saved_jobs	List your saved job postings, with job IDs for looking up their details.
dismiss_job	Dismiss a job from job search so later searches no longer show it. Irreversible.
search_people	Find people by keyword, location, connection degree, and current company.
get_job_details	Read a job posting's description, requirements, and company details.
get_job_apply_url	Check whether a job uses Easy Apply or links to an employer's application.
get_easy_apply_form	Read an Easy Apply form's fields, options and prefilled values. Never submits.
get_feed	Read recent posts from your home feed, with links to the original posts.
search_posts	Search posts by keyword, optionally filtered by recency or content type.
get_session_status	Check your saved login and browser state without opening a browser.
close_session	Close the shared browser session without deleting your saved login.

Setup with uvx (Recommended)

Prerequisites: Install uv.

Installation

Add to your MCP client's mcpServers configuration

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

The @latest tag turns on automatic updates, which keep the server working with LinkedIn's current page structure. The server starts quickly and prepares the shared Patchright Chromium browser cache in the background under ~/.linkedin-mcp/patchright-browsers. On the first tool call that needs authentication, it reuses a LinkedIn session from a signed-in local browser if it finds one, and otherwise opens a LinkedIn login browser window.

AI agent? Get a quick confirmation from the user before enabling automatic updates.

[!NOTE] Early tool calls may return a setup/authentication-in-progress error until browser setup or login finishes. If you prefer to create a session explicitly, run uvx mcp-server-linkedin@latest --login.

Setup Help

• Default (stdio): Standard communication for local MCP servers
• Streamable HTTP: For a web-based MCP server
• If no transport is specified, the server defaults to stdio
• An interactive terminal without explicit transport shows a chooser prompt

Session:

• --login - Open a browser to sign in and save the session
• --import-from-browser [BROWSER] - Reuse a session from a locally signed-in Chromium browser (chrome, chromium, brave, edge, arc, vivaldi, helium, yandex, whale, coccoc, opera, opera_gx, auto). Bare flag picks auto, the most recently used browser with a live LinkedIn session.
• --auto-import / --no-auto-import - Import a session from a signed-in local browser on the first tool call that needs one, before falling back to manual login (default: on). Skipped in Docker, behind a proxy, and on a non-loopback HTTP bind. On macOS the keychain may prompt once.
• --logout - Clear the stored session
• --login-viewer - Docker only: show the --login browser at a token-protected URL on port 6080 (see Authentication)
• --user-data-dir PATH - Browser profile directory (default: ~/.linkedin-mcp/profile). Rotating or clearing a session deletes this directory and its parent, which holds the stored cookies and derived profiles.
• --claim-profile-root - Take over a profile directory the server will not claim on its own, such as one whose parent already holds other files. Needed once per directory.

Transport:

• --transport {stdio,streamable-http} - Force the transport mode (default: stdio)
• --host HOST / --port PORT / --path PATH - HTTP server address (defaults: 127.0.0.1, 8000, /mcp)

Timeouts:

• --timeout MS - Timeout for a single page operation (default: 5000)
• --tool-timeout SECONDS - Timeout for a whole tool call (default: 180). Raise it for calls that read many pages, slow networks, or a cold-start browser.
• --login-timeout SECONDS - How long the login browser waits for you to finish signing in (default: 1800; 0 = no limit). --login-viewer ends the session after 30 minutes either way.
• --login-inline-wait SECONDS - How long a tool call waits for a login to finish before telling the model to retry (default: 25, max 45; 0 = return at once)

Shared browser:

• --browser-wait SECONDS - How long to wait for another server process to hand over the shared browser (default: 25, max 45; 0 = report busy at once). Only matters with several MCP clients running at once.
• --browser-min-hold SECONDS - Shortest time this process keeps the shared browser before handing it over (default: 20). Clamped to 3 seconds below --browser-wait, so raise that one along with it. Higher means fewer browser restarts but longer waits for other clients.
• --browser-idle-timeout SECONDS - Close an idle browser and release the profile after this long without a tool call (default: 600; 0 = keep it open)

Browser:

• --no-headless - Show the browser window (useful for debugging)
• --chrome-path PATH - Path to a Chrome/Chromium executable
• --proxy-server URL - Route browser traffic through a proxy, as scheme://host:port. Set it up before --login; see Using a proxy.

Other:

• --log-level {DEBUG,INFO,WARNING,ERROR} - Logging level (default: WARNING)

If you are already signed into LinkedIn in Chrome, Chromium, Brave, Edge, Arc, Vivaldi, Helium, Yandex, Naver Whale, Cốc Cốc, Opera, or Opera GX, you can skip the manual --login step and reuse that session:

# Auto-pick the most recently used browser with a live LinkedIn session
uvx mcp-server-linkedin@latest --import-from-browser
# Or target a specific browser
uvx mcp-server-linkedin@latest --import-from-browser brave

This reads the browser's LinkedIn cookies, validates them against your feed, and saves them to ~/.linkedin-mcp/profile/, the same place --login writes to. Notes:

• With several signed-in browsers, the most recently used live LinkedIn session is tried first. If LinkedIn rejects it (revoked or remote-logged-out), the next most recent is tried automatically; the first the server accepts is imported. There is no prompt to pick. Pass a browser name to target one specifically.
• On macOS the OS keychain may prompt to allow access to the browser's Safe Storage. Close the source browser first for the most reliable read.
• Cookies protected by Chrome 127+ app-bound encryption (v20) cannot be decrypted without OS elevation; in that case use --login instead.
• Imported cookies match a real login's on-disk set. The local server reads them back in full from the saved profile; the Docker bridge narrows to the same minimal auth subset it uses for a normal session.

Basic Usage Examples:

# Run with debug logging
uvx mcp-server-linkedin@latest --log-level DEBUG

HTTP Mode Example (for web-based MCP clients):

uvx mcp-server-linkedin@latest --transport streamable-http --host 127.0.0.1 --port 8080 --path /mcp

Runtime server logs are emitted by FastMCP/Uvicorn.

Tool calls are serialized to protect the shared LinkedIn browser session, both within one server process and across separate ones. If you run several MCP clients at once, each starts its own server process, and only one of them uses the browser at a time; the others wait briefly and take over as soon as it finishes a call. A client that waits too long gets a "browser is busy" message and can simply retry. Use --log-level DEBUG to see the wait/acquire/release logs.

This covers processes on the same machine and in the same runtime. It does not extend between the host and a Docker container sharing the same ~/.linkedin-mcp directory, so do not run --login or --logout on the host while a container is running.

Test with mcp inspector:

1. Install and run mcp inspector bunx @modelcontextprotocol/inspector
2. Click pre-filled token url to open the inspector in your browser
3. Select Streamable HTTP as Transport Type
4. Set URL to http://localhost:8080/mcp
5. Connect
6. Test tools

• Ensure you have uv installed: curl -LsSf https://astral.sh/uv/install.sh | sh
• Check uv version: uv --version (should be 0.4.0 or higher)
• On first run, uvx downloads all Python dependencies. On slow connections, uv's default 30s HTTP timeout may be too short. The recommended config above already sets UV_HTTP_TIMEOUT=300 (seconds) to avoid this.
• Windows, DLL load failed while importing _greenlet: move to greenlet 3.5.5 or newer, whose published Windows wheels carry the C++ runtime inside the extension again. A fresh uvx run resolves that on its own; an environment that pins its dependencies needs uv lock --upgrade-package greenlet. Only greenlet 3.3.1 through 3.5.4 need MSVCP140.dll, which neither the python.org installer nor the uv-managed builds carry, and a greenlet built from source can need it at any version. Where the version cannot be moved, the Microsoft Visual C++ Redistributable supplies that DLL. Reported as greenlet#525, fixed in greenlet#526.

• Browser profile is stored at ~/.linkedin-mcp/profile/
• Managed browser downloads are cached at ~/.linkedin-mcp/patchright-browsers/
• The browser cache keeps growing: a server upgrade can bring a new Chromium revision, and Patchright keeps the old one for as long as any installed version still references it. uvx keeps one archive per version you have ever run, so every one of them holds such a reference and the old revisions stay. The server logs a warning naming the revisions it is holding and how much space they take. To reclaim it, stop every LinkedIn MCP Server instance, delete ~/.linkedin-mcp/patchright-browsers/, and let the next launch download the current browser.

• Make sure you have only one active LinkedIn session at a time
• LinkedIn may require a login confirmation in the LinkedIn mobile app for --login
• LinkedIn may show a captcha challenge during login. Run uvx mcp-server-linkedin@latest --login which opens a browser where you can solve it manually.

• Page operations failing (elements not found, navigation hangs): increase the browser page-op timeout: --timeout 10000 or TIMEOUT=10000 (milliseconds, default 5000).
• Entire tool calls timing out (e.g. multi-section profiles, cold-start Chromium, slow containers): increase the per-tool execution timeout: --tool-timeout 300 or TOOL_TIMEOUT=300 (seconds, default 180).
• First tool call with no session: if a locally logged-in browser has a live LinkedIn session, the server auto-imports it (see AUTO_IMPORT_FROM_BROWSER / --auto-import) instead of forcing a manual login. On macOS the keychain may prompt once for Safe Storage access. If no importable browser session exists, it falls back to opening a login window and waits up to LOGIN_INLINE_WAIT seconds (default 25, max 45; --login-inline-wait) so a quick sign-in resolves in one call. If the wait elapses, the tool returns a pending signal and the model retries in about 30 seconds. Neither the auto-import nor the inline wait applies under Docker or when the server is bound to a non-loopback HTTP host. Create the session on the host with --login, or use the explicit Docker --login --login-viewer command.
• Users on slow connections may need higher values for either.

• If tool calls answer "No valid LinkedIn session is available in Docker" on a machine that is not a container, the runtime was misdetected. This happened on Linux hosts running a Docker daemon for unrelated services. Set LINKEDIN_MCP_CONTAINER=false to override the detection; true forces the opposite.

• If Chrome is installed in a non-standard location, use --chrome-path /path/to/chrome
• Can also set via environment variable: CHROME_PATH=/path/to/chrome
• On macOS and Linux the browser must be at least as new as the one that last opened your profile, and the server refuses the launch otherwise. (Not on Windows: a browser there cannot be asked its version without starting one, so the check is off.) An older browser can silently drop stores a newer one wrote, the saved session among them, and the failure then looks exactly like an expired login. The message names both versions. Going back to the bundled Chromium after running a newer Chrome once is the usual way to meet this; either run the newer browser again, whichever one that was, or run --login, which moves the stored session aside and signs in fresh with the browser you have. --logout also clears it but discards the old session instead of keeping it recoverable, and it asks for confirmation on the terminal, so it is not usable from a server an MCP client started.
• Only Chrome, Chromium and Chrome for Testing are compared this way. Forks number themselves differently (Vivaldi is on 7.x, Edge's build number sits far below Chrome's under the same major), so pointing CHROME_PATH at one turns the check off rather than producing a refusal nothing could satisfy.

Claude Desktop MCP Bundle (formerly DXT)

Prerequisites: Claude Desktop.

Installation

1. Download the latest .mcpb artifact from releases
2. Click the downloaded .mcpb file to install it into Claude Desktop
3. Call any LinkedIn tool

On startup, the MCP Bundle prepares the shared Patchright Chromium browser cache in the background. On the first tool call that needs authentication, the server reuses a LinkedIn session from a signed-in local browser if it finds one, and otherwise opens a LinkedIn login browser window.

[!NOTE] Early tool calls may return a setup/authentication-in-progress error until browser setup or login finishes. Retry the tool call once the browser download or sign-in completes.

Setup Help

• Claude Desktop starts the bundle immediately; browser setup continues in the background
• If the Patchright Chromium browser is still downloading, retry the tool after a short wait
• Managed browser downloads are shared under ~/.linkedin-mcp/patchright-browsers/
• The browser cache keeps growing: Patchright keeps an old Chromium revision for as long as any installed version still references it, so an upgrade can leave both on disk. The server logs a warning naming what it holds. To reclaim the space, stop every LinkedIn MCP Server instance, delete ~/.linkedin-mcp/patchright-browsers/, and let the next launch download the current browser.
• Windows, the bundle exits with DLL load failed while importing _greenlet: install the Microsoft Visual C++ Redistributable, or reinstall a bundle pinning greenlet 3.5.5 or newer, whose published Windows wheels carry the C++ runtime inside the extension again. A bundle pinning greenlet 3.3.1 through 3.5.4 needs MSVCP140.dll from that redistributable, which neither the python.org installer nor the uv-managed builds carry, and a greenlet built from source can need it at any version. The server names this itself on startup, and only after checking that the loader cannot produce that DLL. Reported as greenlet#525, fixed in greenlet#526.

• Make sure you have only one active LinkedIn session at a time
• LinkedIn may require a login confirmation in the LinkedIn mobile app for --login
• LinkedIn may show a captcha challenge during login. Run uvx mcp-server-linkedin@latest --login which opens a browser where you can solve captchas manually. See the uvx setup for prerequisites.

• Page operations failing (elements not found, navigation hangs): increase the browser page-op timeout: --timeout 10000 or TIMEOUT=10000 (milliseconds, default 5000).
• Entire tool calls timing out (e.g. multi-section profiles, cold-start Chromium, slow containers): increase the per-tool execution timeout: --tool-timeout 300 or TOOL_TIMEOUT=300 (seconds, default 180).
• First tool call with no session: if a locally logged-in browser has a live LinkedIn session, the server auto-imports it (see AUTO_IMPORT_FROM_BROWSER / --auto-import) instead of forcing a manual login. On macOS the keychain may prompt once for Safe Storage access. If no importable browser session exists, it falls back to opening a login window and waits up to LOGIN_INLINE_WAIT seconds (default 25, max 45; --login-inline-wait) so a quick sign-in resolves in one call. If the wait elapses, the tool returns a pending signal and the model retries in about 30 seconds. Neither the auto-import nor the inline wait applies under Docker or when the server is bound to a non-loopback HTTP host. Create the session on the host with --login, or use the explicit Docker --login --login-viewer command.
• Users on slow connections may need higher values for either.

• Set Chrome executable in the extension's settings to a Chrome, Chromium or Chrome for Testing binary, such as /usr/bin/google-chrome. Leave it blank to keep the bundled Chromium. It sets CHROME_PATH, described under Custom Chrome path in the uvx setup help.
• This is the fix when tool calls refuse to open the profile because a newer browser last opened it: point the setting at that newer browser instead of signing in again.

• If tool calls answer "No valid LinkedIn session is available in Docker" on a machine that is not a container, the runtime was misdetected. This happened on Linux hosts running a Docker daemon for unrelated services. Set LINKEDIN_MCP_CONTAINER=false to override the detection; true forces the opposite.

Codex Plugin

Prerequisites: Codex and uv.

Installation

Run in a terminal

codex plugin marketplace add stickerdaniel/linkedin-mcp-server
codex plugin add linkedin-mcp-server@linkedin-mcp-server

The plugin runs the latest server release. On the first tool call that needs authentication, the server reuses a LinkedIn session from a signed-in local browser or opens a login window.

[!NOTE] Early tool calls may return a setup/authentication-in-progress error until browser setup or login finishes. Retry the tool call once the browser download or sign-in completes.

Claude Code Plugin

Prerequisites: Claude Code and uv.

Installation

Run in a terminal

claude plugin marketplace add stickerdaniel/linkedin-mcp-server
claude plugin install linkedin-mcp-server@linkedin-mcp-server

The plugin runs the latest server release. On the first tool call that needs authentication, the server reuses a LinkedIn session from a signed-in local browser or opens a login window.

[!NOTE] Early tool calls may return a setup/authentication-in-progress error until browser setup or login finishes. Retry the tool call once the browser download or sign-in completes.

Cursor Plugin

Prerequisites: Cursor and uv on your PATH.

Installation

From the Cursor Marketplace: open Customize in the sidebar, search for LinkedIn MCP, and choose Install. The plugin bundles the LinkedIn skill.

One-click MCP install (server only, without the skill):

Both run the latest server release. On the first tool call that needs authentication, the server reuses a LinkedIn session from a signed-in local browser or opens a login window.

[!NOTE] Early tool calls may return a setup/authentication-in-progress error until browser setup or login finishes. Retry the tool call once the browser download or sign-in completes.

Setup with Docker

Prerequisites: Make sure Docker is installed and running.

Authentication

Log in once. The container opens a LinkedIn login browser that you drive from your own browser tab.

macOS / Linux:

# Create the directory first so the container can save your session into it
mkdir -p ~/.linkedin-mcp
docker run -it --rm \
  -v ~/.linkedin-mcp:/home/pwuser/.linkedin-mcp \
  -p 127.0.0.1:6080:6080 \
  stickerdaniel/linkedin-mcp-server:latest \
  --login --login-viewer

PowerShell (Windows):

$sessionDir = Join-Path $env:USERPROFILE ".linkedin-mcp"
New-Item -ItemType Directory -Force -Path $sessionDir | Out-Null
docker run -it --rm `
  -v "${sessionDir}:/home/pwuser/.linkedin-mcp" `
  -p 127.0.0.1:6080:6080 `
  stickerdaniel/linkedin-mcp-server:latest `
  --login --login-viewer

Open the full URL the command prints (it carries the access token) and sign in. Ctrl+V (Cmd+V on a Mac) pastes plain ASCII text, such as a password from your password manager, into the login browser. The viewer closes itself afterwards; let the command exit on its own so the session is stored completely. It gives up after 30 minutes.

Keep the same host directory mounted at /home/pwuser/.linkedin-mcp on every later docker run, otherwise the server cannot find the session.

Add to your MCP client's mcpServers configuration

macOS / Linux (absolute path in JSON):

{
  "mcpServers": {
    "mcp-server-linkedin": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-v", "/absolute/path/to/.linkedin-mcp:/home/pwuser/.linkedin-mcp",
        "stickerdaniel/linkedin-mcp-server:latest"
      ]
    }
  }
}

Spell that first path out in full. A client runs docker directly rather than through a shell, so a leading ~ reaches Docker unexpanded and it refuses the mount.

PowerShell (Windows): use a forward-slash JSON path. A backslash path like C:\Users\Alice\.linkedin-mcp fails JSON parsing because \U is an invalid escape. Use C:/Users/Alice/.linkedin-mcp instead, replacing Alice with your username.

{
  "mcpServers": {
    "mcp-server-linkedin": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-v", "C:/Users/Alice/.linkedin-mcp:/home/pwuser/.linkedin-mcp",
        "stickerdaniel/linkedin-mcp-server:latest"
      ]
    }
  }
}

[!NOTE] In PowerShell, ~ is not expanded inside a composite Docker -v argument. Use C:/Users/<you>/.linkedin-mcp or build the path with $env:USERPROFILE\.linkedin-mcp before passing it to Docker.

[!NOTE] Sessions expire over time. When tool calls start asking for authentication, repeat the login command above, or run uvx mcp-server-linkedin@latest --login on the host.

Setup Help

• Default (stdio): Standard communication for local MCP servers
• Streamable HTTP: For a web-based MCP server
• If no transport is specified, the server defaults to stdio
• An interactive terminal without explicit transport shows a chooser prompt

Session:

• --auto-import / --no-auto-import - Import a session from a signed-in local browser on the first tool call that needs one, before falling back to manual login (ignored in Docker). On macOS the keychain may prompt once.
• --logout - Clear the stored session and every profile derived from it
• --login-viewer - With --login, show the login browser at a token-protected URL on port 6080. Needs the profile mount from Authentication.
• --user-data-dir PATH - Browser profile directory (default: ~/.linkedin-mcp/profile). Rotating or clearing a session deletes this directory and its parent, which holds the stored cookies and derived profiles.
• --claim-profile-root - Take over a profile directory the server will not claim on its own, such as one whose parent already holds other files. Needed once per directory.

Transport:

• --transport {stdio,streamable-http} - Force the transport mode (default: stdio)
• --host HOST / --port PORT / --path PATH - HTTP server address (defaults: 127.0.0.1, 8000, /mcp)

Timeouts:

• --timeout MS - Timeout for a single page operation (default: 5000)
• --tool-timeout SECONDS - Timeout for a whole tool call (default: 180). Raise it for calls that read many pages, slow networks, or a cold-start browser.
• --login-timeout SECONDS - How long the login browser waits for you to finish signing in (default: 1800; 0 = no limit). --login-viewer ends the session after 30 minutes either way.
• --login-inline-wait SECONDS - How long a tool call waits for a login to finish before telling the model to retry (default: 25, max 45; 0 = return at once)

Shared browser:

• --browser-wait SECONDS - How long to wait for another server process to hand over the shared browser (default: 25, max 45; 0 = report busy at once). Only matters with several MCP clients running at once.
• --browser-min-hold SECONDS - Shortest time this process keeps the shared browser before handing it over (default: 20). Clamped to 3 seconds below --browser-wait, so raise that one along with it. Higher means fewer browser restarts but longer waits for other clients.
• --browser-idle-timeout SECONDS - Close an idle browser and release the profile after this long without a tool call (default: 600; 0 = keep it open)

Browser:

• --chrome-path PATH - Path to a Chrome/Chromium executable (rarely needed in Docker)
• --proxy-server URL - Route browser traffic through a proxy, as scheme://host:port. Set it up before --login; see Using a proxy.

Other:

• --log-level {DEBUG,INFO,WARNING,ERROR} - Logging level (default: WARNING)

[!NOTE] Plain --login still has no visible window in Docker. Add --login-viewer and publish 127.0.0.1:6080:6080 only for the one-shot login command. Docker is already headed by default, so --no-headless changes nothing. The experimental --daemon is ignored in Docker because its owner can outlive the virtual display.

HTTP Mode Example (for web-based MCP clients):

Bash / macOS / Linux:

docker run -it --rm \
  -v ~/.linkedin-mcp:/home/pwuser/.linkedin-mcp \
  -p 127.0.0.1:8080:8080 \
  stickerdaniel/linkedin-mcp-server:latest \
  --transport streamable-http --host 0.0.0.0 --port 8080 --path /mcp

PowerShell (Windows):

$sessionDir = Join-Path $env:USERPROFILE ".linkedin-mcp"
docker run -it --rm `
  -v "${sessionDir}:/home/pwuser/.linkedin-mcp" `
  -p 127.0.0.1:8080:8080 `
  stickerdaniel/linkedin-mcp-server:latest `
  --transport streamable-http --host 0.0.0.0 --port 8080 --path /mcp

Both halves of that are needed, and they do different jobs. --host 0.0.0.0 makes the server reachable inside the container: a process bound to 127.0.0.1 in there cannot be reached through a published port at all. The 127.0.0.1: in front of -p is what limits it outside, to this machine. Drop that prefix and Docker publishes on every interface, which puts an endpoint with no authentication on your network. The server cannot tell the two apart, so it warns either way.

Loopback publishing limits this to the machine, not to the container. Other containers on the same host can still reach it through host.docker.internal wherever that name resolves, which is the default on Docker Desktop and OrbStack but not on native Linux Docker.

Runtime server logs are emitted by FastMCP/Uvicorn.

The HTTP server answers requests addressed to localhost or to the address it is bound to, and refuses others with 421. That is what stops a website you merely visit from pointing a domain at this server and using your LinkedIn session through your own browser.

Reaching the server by any other name is refused, including a machine name on your network and the public name in front of a reverse proxy. Either have the proxy rewrite the upstream Host to the backend address, or name the host you serve it under:

FASTMCP_HTTP_ALLOWED_HOSTS='["mcp.example"]'

That permits exactly that name and keeps refusing everything else. The endpoint still has no authentication, so anything reachable beyond your own machine belongs behind something that provides it.

Test with mcp inspector:

1. Install and run mcp inspector bunx @modelcontextprotocol/inspector
2. Click pre-filled token url to open the inspector in your browser
3. Select Streamable HTTP as Transport Type
4. Set URL to http://localhost:8080/mcp
5. Connect
6. Test tools

• Make sure Docker is installed
• Check if Docker is running: docker ps
• Permission errors on ~/.linkedin-mcp: an older rootful Docker run may have created the directory as root. Fix it with sudo chown -R "$(id -u):$(id -g)" ~/.linkedin-mcp.

• Make sure you have only one active LinkedIn session at a time
• LinkedIn may require a login confirmation in the LinkedIn mobile app for --login
• LinkedIn may show a captcha challenge during login. Run uvx mcp-server-linkedin@latest --login which opens a browser where you can solve captchas manually. See the uvx setup for prerequisites.
• If Docker auth becomes stale after you re-login on the host, restart Docker once so it can fresh-bridge from the new source session generation.

• Page operations failing (elements not found, navigation hangs): increase the browser page-op timeout: --timeout 10000 or TIMEOUT=10000 (milliseconds, default 5000).
• Entire tool calls timing out (e.g. multi-section profiles, cold-start Chromium, slow containers): increase the per-tool execution timeout: --tool-timeout 300 or TOOL_TIMEOUT=300 (seconds, default 180).
• First tool call with no session: if a locally logged-in browser has a live LinkedIn session, the server auto-imports it (see AUTO_IMPORT_FROM_BROWSER / --auto-import) instead of forcing a manual login. On macOS the keychain may prompt once for Safe Storage access. If no importable browser session exists, it falls back to opening a login window and waits up to LOGIN_INLINE_WAIT seconds (default 25, max 45; --login-inline-wait) so a quick sign-in resolves in one call. If the wait elapses, the tool returns a pending signal and the model retries in about 30 seconds. Neither the auto-import nor the inline wait applies under Docker or when the server is bound to a non-loopback HTTP host. Create the session on the host with --login, or use the explicit Docker --login --login-viewer command.
• Users on slow connections may need higher values for either.

• If tool calls answer "No valid LinkedIn session is available in Docker" on a machine that is not a container, the runtime was misdetected. This happened on Linux hosts running a Docker daemon for unrelated services. Set LINKEDIN_MCP_CONTAINER=false to override the detection; true forces the opposite.

• If Chrome is installed in a non-standard location, use --chrome-path /path/to/chrome
• Can also set via environment variable: CHROME_PATH=/path/to/chrome
• On macOS and Linux the browser must be at least as new as the one that last opened your profile, and the server refuses the launch otherwise. (Not on Windows: a browser there cannot be asked its version without starting one, so the check is off.) An older browser can silently drop stores a newer one wrote, the saved session among them, and the failure then looks exactly like an expired login. The message names both versions. Going back to the bundled Chromium after running a newer Chrome once is the usual way to meet this; either run the newer browser again, whichever one that was, or run --login, which moves the stored session aside and signs in fresh with the browser you have. --logout also clears it but discards the old session instead of keeping it recoverable, and it asks for confirmation on the terminal, so it is not usable from a server an MCP client started.
• Only Chrome, Chromium and Chrome for Testing are compared this way. Forks number themselves differently (Vivaldi is on 7.x, Edge's build number sits far below Chrome's under the same major), so pointing CHROME_PATH at one turns the check off rather than producing a refusal nothing could satisfy.
• In the documented Docker setup this check does not apply. The container never opens the profile you created with --login; it derives its own from your cookies, and by default rebuilds that from scratch on every start, so there is nothing for an older image to downgrade. With EXPERIMENTAL_PERSIST_DERIVED_RUNTIME the derived profile is kept, and an image tag that moves backwards then throws it away and re-derives it, again with nothing for you to do. The check matters on the host, where the server opens that profile directly. Not during --login itself, which moves the old profile aside before it starts a browser and so can never trip it.

Using a proxy

LinkedIn scores the address a session signs in from. Your account's usual IP address is the safe one. You should use a proxy in your country when the server cannot use it: a VPS, another country, or a second account that must not share the first one's address.

With a paid provider, use a sticky residential session that holds one address (never per-request rotation). A WireGuard full tunnel or Tailscale exit node on your home network works when the server should use your usual home address.

Setup Help

• Set the proxy up before --login. Moving an existing session to a new address triggers a LinkedIn checkpoint. That includes a session from --import-from-browser, which was created on your real address.
• --proxy-server scheme://host:port or PROXY_SERVER, with http, https, socks4 or socks5. Only browser traffic is routed, not the MCP transport.
• Pass credentials through PROXY_USERNAME and PROXY_PASSWORD, or include them in PROXY_SERVER using the combined http://user:pass@host:port form. The combined form is not accepted by the --proxy-server CLI option.
• PROXY_BYPASS=localhost,127.0.0.1,::1 reaches local targets directly. With a proxy set, Chromium routes localhost through it too.

• Chromium cannot authenticate to a SOCKS proxy, so credentials require an http(s) endpoint. If your provider only offers authenticated SOCKS5, run a local relay that holds the credentials and point the server at that.
• A wrong proxy password shows up as a timeout or a failed sign-in, because Chromium retries the authentication challenge until the page times out. If sessions stop working right after you add a proxy, check the proxy credentials first.
• Auto-import is skipped while a proxy is configured: the imported session would move from your real address to the proxy. Use --login.
• Inside a container 127.0.0.1 is the container itself, so a relay on the host is host.docker.internal; native Linux Docker also needs --add-host=host.docker.internal:host-gateway.

Setup from Source (Develop & Contribute)

Contributions are welcome. See CONTRIBUTING.md for architecture guidelines and checklists. Search existing issues first, then use the issue forms for anything new. AI agents follow the issue-packet skill.

Prerequisites: Git and uv installed

Installation

Run in a terminal

# 1. Clone repository
git clone https://github.com/stickerdaniel/linkedin-mcp-server
cd linkedin-mcp-server

# 2. Install UV package manager (if not already installed)
curl -LsSf https://astral.sh/uv/install.sh | sh

# 3. Install dependencies
uv sync
uv sync --group dev

# 4. Install pre-commit hooks
uv run pre-commit install

# 5. Start the server
uv run -m linkedin_mcp_server

Setup Help

Session:

• --login - Open a browser to sign in and save the session
• --import-from-browser [BROWSER] - Reuse a session from a locally signed-in Chromium browser (chrome, chromium, brave, edge, arc, vivaldi, helium, yandex, whale, coccoc, opera, opera_gx, auto). Bare flag picks auto, the most recently used browser with a live LinkedIn session.
• --auto-import / --no-auto-import - Import a session from a signed-in local browser on the first tool call that needs one, before falling back to manual login (default: on). Skipped in Docker, behind a proxy, and on a non-loopback HTTP bind. On macOS the keychain may prompt once.
• --status - Check whether the stored session is valid, then exit
• --logout - Clear the stored session
• --user-data-dir PATH - Browser profile directory (default: ~/.linkedin-mcp/profile). Rotating or clearing a session deletes this directory and its parent, which holds the stored cookies and derived profiles.
• --claim-profile-root - Take over a profile directory the server will not claim on its own, such as one whose parent already holds other files. Needed once per directory.

Transport:

• --transport {stdio,streamable-http} - Force the transport mode (default: stdio)
• --host HOST / --port PORT / --path PATH - HTTP server address (defaults: 127.0.0.1, 8000, /mcp)

Timeouts:

• --timeout MS - Timeout for a single page operation (default: 5000)
• --tool-timeout SECONDS - Timeout for a whole tool call (default: 180). Raise it for calls that read many pages, slow networks, or a cold-start browser.
• --login-timeout SECONDS - How long the login browser waits for you to finish signing in (default: 1800; 0 = no limit). --login-viewer ends the session after 30 minutes either way.
• --login-inline-wait SECONDS - How long a tool call waits for a login to finish before telling the model to retry (default: 25, max 45; 0 = return at once)

Shared browser:

• --browser-wait SECONDS - How long to wait for another server process to hand over the shared browser (default: 25, max 45; 0 = report busy at once). Only matters with several MCP clients running at once.
• --browser-min-hold SECONDS - Shortest time this process keeps the shared browser before handing it over (default: 20). Clamped to 3 seconds below --browser-wait, so raise that one along with it. Higher means fewer browser restarts but longer waits for other clients.
• --browser-idle-timeout SECONDS - Close an idle browser and release the profile after this long without a tool call (default: 600; 0 = keep it open)

Browser:

• --no-headless - Show the browser window (useful for debugging)
• --slow-mo MS - Delay between browser actions (default: 0, useful for debugging)
• --viewport WxH - Viewport size (default: 1280x720). Applies to windowless mode only; a headed launch uses the real window size.
• --chrome-path PATH - Path to a Chrome/Chromium executable
• --installer-temp-dir PATH - Existing directory for browser installation temporary files (environment: INSTALLER_TEMP_DIR).
• --proxy-server URL - Route browser traffic through a proxy, as scheme://host:port. Set it up before --login; see Using a proxy.

Other:

• --log-level {DEBUG,INFO,WARNING,ERROR} - Logging level (default: WARNING)
• --help - Show help

Note: Most CLI options have environment variable equivalents. See .env.example for details.

HTTP Mode Example (for web-based MCP clients):

uv run -m linkedin_mcp_server --transport streamable-http --host 127.0.0.1 --port 8000 --path /mcp

Claude Desktop:

{
  "mcpServers": {
    "mcp-server-linkedin": {
      "command": "uv",
      "args": ["--directory", "/path/to/linkedin-mcp-server", "run", "-m", "linkedin_mcp_server"]
    }
  }
}

stdio is used by default for this config.

• Make sure you have only one active LinkedIn session at a time
• LinkedIn may require a login confirmation in the LinkedIn mobile app for --login
• LinkedIn may show a captcha challenge during login. The --login command opens a browser where you can solve it manually.

• Use --no-headless to watch the browser when a tool returns wrong or missing data
• Add --log-level DEBUG to see more detailed logging

• Browser profile is stored at ~/.linkedin-mcp/profile/
• Managed browser downloads are cached at ~/.linkedin-mcp/patchright-browsers/, shared with the uvx and MCP Bundle installations
• The browser cache keeps growing: Patchright keeps an old Chromium revision for as long as any installed version still references it, and a uv archive or a second worktree is such a reference. The server logs a warning naming what it holds. To reclaim the space, stop every LinkedIn MCP Server instance, delete ~/.linkedin-mcp/patchright-browsers/, and let the next launch download the current browser.
• Use --logout to clear the profile and start fresh

• Check Python version: python --version (should be 3.12.4+)
• Reinstall Patchright: uv run patchright install chromium
• Reinstall dependencies: uv sync --reinstall

• Page operations failing (elements not found, navigation hangs): increase the browser page-op timeout: --timeout 10000 or TIMEOUT=10000 (milliseconds, default 5000).
• Entire tool calls timing out (e.g. multi-section profiles, cold-start Chromium, slow containers): increase the per-tool execution timeout: --tool-timeout 300 or TOOL_TIMEOUT=300 (seconds, default 180).
• First tool call with no session: if a locally logged-in browser has a live LinkedIn session, the server auto-imports it (see AUTO_IMPORT_FROM_BROWSER / --auto-import) instead of forcing a manual login. On macOS the keychain may prompt once for Safe Storage access. If no importable browser session exists, it falls back to opening a login window and waits up to LOGIN_INLINE_WAIT seconds (default 25, max 45; --login-inline-wait) so a quick sign-in resolves in one call. If the wait elapses, the tool returns a pending signal and the model retries in about 30 seconds. Neither the auto-import nor the inline wait applies under Docker or when the server is bound to a non-loopback HTTP host. Create the session on the host with --login, or use the explicit Docker --login --login-viewer command.
• Users on slow connections may need higher values for either.

• If tool calls answer "No valid LinkedIn session is available in Docker" on a machine that is not a container, the runtime was misdetected. This happened on Linux hosts running a Docker daemon for unrelated services. Set LINKEDIN_MCP_CONTAINER=false to override the detection; true forces the opposite.

• If Chrome is installed in a non-standard location, use --chrome-path /path/to/chrome
• Can also set via environment variable: CHROME_PATH=/path/to/chrome
• On macOS and Linux the browser must be at least as new as the one that last opened your profile, and the server refuses the launch otherwise. (Not on Windows: a browser there cannot be asked its version without starting one, so the check is off.) An older browser can silently drop stores a newer one wrote, the saved session among them, and the failure then looks exactly like an expired login. The message names both versions. Going back to the bundled Chromium after running a newer Chrome once is the usual way to meet this; either run the newer browser again, whichever one that was, or run --login, which moves the stored session aside and signs in fresh with the browser you have. --logout also clears it but discards the old session instead of keeping it recoverable, and it asks for confirmation on the terminal, so it is not usable from a server an MCP client started.
• Only Chrome, Chromium and Chrome for Testing are compared this way. Forks number themselves differently (Vivaldi is on 7.x, Edge's build number sits far below Chrome's under the same major), so pointing CHROME_PATH at one turns the check off rather than producing a refusal nothing could satisfy.

[!IMPORTANT] FAQ

Is this safe to use? Will I get banned? This tool controls a real browser session; it doesn't exploit undocumented APIs or bypass authentication. 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. If you encounter any issues, let me know in the Discussions.

What if my agents execute too many actions? Tool calls run sequentially through a queue. You are responsible for the volume of automation you run; use it sparingly and prompt your agents responsibly.

Contributors

Thanks to everyone who has contributed code, bug reports and fixes.

Acknowledgements

Built with FastMCP and Patchright.

Use in accordance with LinkedIn's User Agreement. Automated access may violate LinkedIn's terms and can lead to account restrictions. This tool is for personal use only and comes with no warranty of any kind.

License

This project is licensed under the Apache 2.0 license.

Building on this project is welcome! See the license for terms and the NOTICE for attribution.