LinkedIn

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](https://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 Code

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

Claude Desktop : claude_desktop_config.json

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"] } } }

Cursor : ~/.cursor/mcp.json

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

{

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

VS Code : .vscode/mcp.json

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"] } } }

Codex CLI : ~/.codex/config.toml

[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.

Zed : settings.json

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"] } } }

Windsurf : ~/.codeium/windsurf/mcp_config.json

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.

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

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.

[!WARNING]

**This cookie *is* your LinkedIn login.** Anyone who has it can act as you:

read your messages, message your connections, see everything your account can

see, without needing your password. It survives a password change, and it

cannot be revoked from any session list LinkedIn shows you. Never paste it

into a chat, a commit, an issue, a screenshot, or anywhere other than

linkedin-api-mcp auth.

1. 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.

1. 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:

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 th