linkedin-api-mcp

Disclaimer: This is an independent, community project. It is not affiliated with, authorized by, endorsed by, or sponsored by LinkedIn Corporation or Microsoft. "LinkedIn" is a registered trademark of LinkedIn Corporation and is used here only descriptively to identify the third-party service this software interoperates with.

An MCP server for LinkedIn. It drives a real, headless browser (patchright, an undetected fork of Playwright) using your own logged-in LinkedIn session cookie. There is no scraping API, no credential stuffing, no bypass of LinkedIn's login. Your agent gets 12 read tools (profiles, companies, jobs, posts, your inbox) and two write tools, kept deliberately separate: sending a message and sending a connection request. Every action goes through a single browser session, one at a time, paced against limits you control. See Safety below.

Documentation: mcp.johannsenlum.com/linkedin

Install (one-click)

Deeplinks exist for Cursor and VS Code only; no other client has a documented install-link format. These prefill the command below, nothing else needs filling in since the cookie lives in your OS keyring, not an environment variable.

All clients

claude mcp add linkedin -- uvx linkedin-api-mcp

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

No one-click install exists for Claude Desktop (it installs .mcpb bundles, not deeplinks). Copy this JSON in via Settings → Developer → Edit Config:

{
  "mcpServers": {
    "linkedin": {
      "command": "uvx",
      "args": ["linkedin-api-mcp"]
    }
  }
}

Fallback for the button above, or if you'd rather paste it directly:

{
  "mcpServers": {
    "linkedin": {
      "command": "uvx",
      "args": ["linkedin-api-mcp"]
    }
  }
}

Fallback for the button above, or if you'd rather paste it directly. Note VS Code uses a servers key, not mcpServers:

{
  "servers": {
    "linkedin": {
      "type": "stdio",
      "command": "uvx",
      "args": ["linkedin-api-mcp"]
    }
  }
}

[mcp_servers.linkedin]
command = "uvx"
args = ["linkedin-api-mcp"]

Codex CLI's config schema has changed across versions and this block is not independently verified against a live install. If it doesn't load, the reliable path is running uvx linkedin-api-mcp yourself and pointing Codex at whatever its current stdio-server config expects.

No deeplink exists for Zed. Add this under context_servers in your Zed settings:

{
  "context_servers": {
    "linkedin": {
      "source": "custom",
      "command": "uvx",
      "args": ["linkedin-api-mcp"]
    }
  }
}

No deeplink exists for Windsurf. It only resolves servers from its own registry, so this has to be pasted in manually via Windsurf Settings → MCP Servers → Edit raw config:

{
  "mcpServers": {
    "linkedin": {
      "command": "uvx",
      "args": ["linkedin-api-mcp"]
    }
  }
}

If you'd rather not rely on the keyring in a given client (a sandboxed environment, or CI), pass the cookie directly instead of running auth:

{
  "mcpServers": {
    "linkedin": {
      "command": "uvx",
      "args": ["linkedin-api-mcp"],
      "env": { "LINKEDIN_COOKIE": "your-li_at-value" }
    }
  }
}

Anywhere you do this, treat that config file with the same care as the cookie itself: don't commit it, and restrict its permissions.

Related MCP server: LinkedIn Sales & Navigator MCP Server

Getting your session cookie

LinkedIn doesn't offer an API key for this kind of access, so the server uses the same session cookie your browser already holds.

1. One-time: install the Chromium build the server drives.

   uvx --from linkedin-api-mcp patchright install chromium

2. Log in to linkedin.com in a normal browser.

3. Open DevTools (F12 or Cmd+Opt+I) → Application → Cookies → https://www.linkedin.com.

4. Find the row named li_at and copy its Value.

5. Store it:

   uvx linkedin-api-mcp auth

   Paste the value in when prompted; the terminal will not echo it back. By default it's stored in your OS keyring (Keychain, Windows Credential Manager, or Secret Service on Linux), never written to a config file.

6. Verify LinkedIn accepts it before wiring up a client:

   uvx linkedin-api-mcp --test

   Prints the server's redacted configuration and confirms the session is live. It never prints the cookie itself.

Tools

14 tools: 12 read, 2 write. send_message and connect are the only two that change anything, and both are visible to another real person the moment they run: there is no draft, preview, or undo step. Everything else only reads what your account can already see. Covered by 68 tests.

What's verified, and what isn't

This is a days-old project. Rather than claim everything works, here's what's actually been checked against a live account, and what hasn't.

Safety

• A serialised action queue. Every tool call, including linkedin_status, passes through the same queue before it touches the browser: one action at a time, never in parallel.

• A minimum interval and an hourly ceiling, both enforced, not just claimed:

  Setting	Default	Env var	Effect
  Minimum interval between actions	2 seconds	LINKEDIN_MIN_INTERVAL	Calls are paced against the previous one, not run back-to-back.
  Actions per rolling hour	120	LINKEDIN_MAX_PER_HOUR	Once hit, further calls fail immediately with a rate_limited error rather than queueing or sleeping.

  The ceiling is local to this server: it exists to stop a looping agent from generating a burst of LinkedIn traffic, not because LinkedIn told us these numbers. Lowering them is always safe; raising them is you deciding you're willing to accept more risk than the defaults assume.

• Prompt-injection fencing on all scraped free text. Anything read off a LinkedIn page (a headline, an about section, a message) passes through your agent as data. It is fenced before your agent sees it, so text on a profile or in a message cannot pose as an instruction.

• The cookie lives in your OS keyring, not a config file, by default. See Getting your session cookie.

• send_message proves delivery before reporting success. It polls the conversation until the sent text actually appears, and raises send_unconfirmed rather than a false {"sent": true} if it doesn't.

Other environment variables the server reads: LINKEDIN_COOKIE (overrides the keyring), LINKEDIN_HEADLESS (default true), LINKEDIN_NAV_TIMEOUT_MS (default 30000).

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.

Licence

MIT © 2026 Johannsen Lum.

Use it, change it, redistribute it, build something commercial on it: the only condition is that you keep the copyright notice and licence text. It comes with no warranty of any kind.

Contributions are accepted under the same licence.

Contributing

Issues and pull requests are welcome: github.com/JohannsenLum/linkedin-api-mcp. Changes are recorded in CHANGELOG.md.

Running the tests

Install the development dependencies and run pytest from the repository root:

pip install -e ".[dev]"
python -m pytest -q

The default test suite does not need Chromium, a LinkedIn account, LINKEDIN_COOKIE, or network access. Browser interactions are replaced by the test doubles in tests/fakes.py, which parse canned HTML and expose the small Playwright surface used by the tools. For a parsing-test example, see tests/test_people_parsing.py.

This is an independent project, not affiliated with LinkedIn Corporation. See the disclaimer at the top of this document.