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

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

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

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

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

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

{
  "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
   

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.

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

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.

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