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 tools to read profiles, companies, jobs and posts, and — deliberately separated out — two tools that take real actions on your behalf: 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 Rate limits below.

Install

Requires Python 3.11+. The server is published for uv, so nothing needs a persistent virtualenv:

# One-time: install the Chromium build patchright drives.
uvx --from linkedin-api-mcp patchright install chromium

# One-time: store your session cookie in the OS keyring.
uvx linkedin-api-mcp auth

# Verify the cookie works before wiring it into a client.
uvx linkedin-api-mcp --test

--test prints the server's redacted configuration and confirms LinkedIn accepts the stored session — it never prints the cookie itself.

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. Log in to linkedin.com in a normal browser.

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

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

4. Run uvx linkedin-api-mcp auth and paste it in when prompted (the terminal will not echo it back).

By default the cookie is stored in your OS keyring (Keychain, Windows Credential Manager, or Secret Service on Linux), never written to a config file. For CI or a throwaway environment, set LINKEDIN_COOKIE instead and skip auth entirely — the environment variable takes priority when both are set.

Related MCP server: LinkedIn Sales & Navigator MCP Server

Tools

send_message and connect are the only two tools that change anything — everything else only reads what your account can already see. Both are visible to another real person the moment they run: there is no draft, preview, or undo step.

Client configuration

All three clients spawn the same command over stdio; only the file differs.

Claude Desktop

Add to claude_desktop_config.json:

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

Claude Code

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

or add the same block as above to .mcp.json.

Cursor

Add to .cursor/mcp.json:

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

If you'd rather not rely on the keyring in a given client (e.g. a sandboxed environment), 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.

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.

Rate limits

The queue answer above is enforced, not just claimed — every tool call, including linkedin_status, passes through the same ActionQueue before it touches the browser:

Both are read from the environment at startup. 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. Call linkedin_status to see current usage against both before running a batch of actions.

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

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.