LinkedIn MCP Server

A production-grade Model Context Protocol server that lets an AI assistant operate LinkedIn through an authenticated browser session — profile management, posting, networking, messaging, job search and automated applications.

102 tools across 15 categories. No password login: authentication reuses cookies from a browser where you are already signed in. Selectors repair themselves when LinkedIn changes its markup — using your own model, with page content never leaving your machine.

Unofficial project. Not affiliated with or endorsed by LinkedIn Corporation. Automating LinkedIn may violate its User Agreement and can get your account restricted. See Responsible use.

Why this design

A few decisions shape everything else, and they are worth stating up front.

Two transports, chosen per operation. Reads prefer LinkedIn's internal Voyager API — one HTTP request returning structured JSON, no browser. Writes go through real DOM automation, because LinkedIn's write endpoints are the least stable part of that API and a malformed request can silently blank a profile section. Each transport falls back to the other.

Selector fallback chains. LinkedIn ships UI changes constantly and its class names are obfuscated. Every element is described by a ranked list of selectors — stable test hooks first, then ARIA roles, then visible text, then structural guesses. A markup change usually breaks one candidate, not all four, turning a hard breakage into a silent fallback.

Selectors that repair themselves. When every candidate misses, the server shows your model a redacted structural outline of the page, takes its suggestions, verifies them against the live DOM, and remembers what works — so a markup change costs one slow call instead of a broken tool and a wait for the next release. It is deliberately narrow: it never relearns a destructive control, never adopts a selector it has not just seen resolve, and never sends page content anywhere. See Self-healing below.

Errors are data, not exceptions. Every tool returns the same envelope whether it succeeds or fails, and failures carry a machine-readable code plus a remediation string. An agent can read why something failed and adapt, instead of blindly retrying.

Conservative by default. Rate limits, daily action quotas, a confirmation gate on destructive tools, and a global dry-run switch. LinkedIn restricts accounts that behave inhumanly, and a restriction costs far more than a slow run.

It says what it does not know. Sections LinkedIn withholds are reported as unavailableSections. Generated resumes list their gaps. Inferred values — like whether someone is a recruiter — carry a score and the signals behind it. Nothing is silently invented.

Related MCP server: LinkedIn MCP Server

Install

Requires Node.js 20+.

From npm

The shortest path from nothing to working tools, on any platform:

npm install -g linkedin-mcp-bridge   # 1. install
linkedin-mcp-setup                    # 2. sign in, and register with Claude Code

Step 2 opens a real Chrome window at LinkedIn. Sign in by hand — passwords, 2FA and CAPTCHAs stay between you and LinkedIn, and this server never sees them. When you are in, it offers to register itself with Claude Code and to set the profile path in the server's env block. Restart your client and the linkedin_* tools are there.

Other binaries in the package:

linkedin-mcp-bridge                   # stdio server (what your client spawns)
linkedin-mcp-http                     # streamable HTTP server

Alternatively, skip the install and point your client at npx -y linkedin-mcp-bridge, which fetches the package on first run. You still need to sign in once — run npx -y -p linkedin-mcp-bridge linkedin-mcp-setup. See Authenticate.

From source

git clone https://github.com/Sabari2005/linkedin-mcp-server.git
cd linkedin-mcp-server
npm install            # installs deps and the Chromium browser
cp .env.example .env
npm run setup:profile  # sign in by hand; see Authenticate below
npm run build

Verify:

npm run cookies:check   # is the session valid?
npm run tools:list      # what can it do?
npm run smoke           # exercise every tool against your account (dry run)

Authenticate

This server never asks for your password. You sign in to LinkedIn yourself, in a real browser, and the server reuses that session — so 2FA, CAPTCHAs and device confirmations all work normally.

Nothing to configure (default)

Install, add the server to your client, and ask it something:

> Show my LinkedIn profile

A Chrome window opens at the LinkedIn login page.
Sign in there. The request completes on its own.

The first call that needs authentication creates a browser profile, opens it at LinkedIn, and waits. Sign in quickly and the same call returns your data; take longer and it says "sign in, then ask again" while the window stays open — the next request goes through. You only ever sign in once: the session lives in the profile and survives restarts.

The profile lives outside the repo, one per machine:

Set LINKEDIN_AUTO_LOGIN=false to turn this off and get a plain error instead.

Sign in up front (optional)

To choose where the profile lives, or to authenticate before wiring up a client:

npm run setup:profile        # from source
linkedin-mcp-setup           # installed globally

It prints one line for your .env:

LINKEDIN_BROWSER_PROFILE=/path/it/printed

Either way the profile is dedicated on purpose: Chrome 136+ refuses to be automated against your primary user-data directory, and it fails by hanging for three minutes rather than saying so. A separate profile also means you never have to close your everyday Chrome to let the server run.

Cookie capture (alternative)

npm run login

Best when there is no Chrome to keep around — a headless server, a container. It opens a browser once, captures the session to a file, and reuses it. That file is a credential, and it expires when LinkedIn rotates or you change your password.

Manual export via the Cookie-Editor extension also works — see docs/authentication.md.

Set exactly one strategy. LINKEDIN_LI_AT outranks LINKEDIN_COOKIE_FILE, which outranks LINKEDIN_BROWSER_PROFILE. A leftover cookie-file line silently ignoring your profile is the single most common setup failure. The server warns at startup when it sees more than one.

Check what it resolved to at any time:

npm run cookies:check

Connect a client

Two transports, same 102 tools:

Every config below uses npx, which downloads the package on first run and needs no clone, no build and no absolute paths. The -y skips the install prompt, which a client launching the server has no way to answer.

On the very first authenticated call the server opens a Chrome window for you to sign in (see Authenticate). Nothing else is required up front.

Replace "command": "npx", "args": ["-y", "linkedin-mcp-bridge"] with "command": "node", "args": ["/absolute/path/to/dist/index.js"] after npm install && npm run build. Use an absolute path — clients do not launch from your project directory.

Claude Code

linkedin-mcp-setup offers to do this for you. To do it by hand:

claude mcp add linkedin --scope user -- npx -y linkedin-mcp-bridge
claude mcp list   # → linkedin: ✔ Connected

Use --scope user, not the default local. A local-scoped server is recorded under projects["<cwd>"] in ~/.claude.json and only loads when Claude Code starts from that exact directory — from anywhere else the tools simply are not there, which is easy to mistake for a broken server.

Cursor

.cursor/mcp.json in the project, or ~/.cursor/mcp.json globally:

{
  "mcpServers": {
    "linkedin": {
      "command": "npx",
      "args": ["-y", "linkedin-mcp-bridge"]
    }
  }
}

Windsurf

~/.codeium/windsurf/mcp_config.json — same shape as Cursor:

{
  "mcpServers": {
    "linkedin": {
      "command": "npx",
      "args": ["-y", "linkedin-mcp-bridge"]
    }
  }
}

GitHub Copilot (VS Code)

.vscode/mcp.json in the workspace. Note Copilot's key is servers, not mcpServers:

{
  "servers": {
    "linkedin": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "linkedin-mcp-bridge"]
    }
  }
}

Then open the Copilot Chat Agent mode tool picker to enable the LinkedIn tools.

OpenAI Codex CLI

~/.codex/config.toml:

[mcp_servers.linkedin]
command = "npx"
args = ["-y", "linkedin-mcp-bridge"]

Claude Desktop

claude_desktop_config.json:

{
  "mcpServers": {
    "linkedin": {
      "command": "node",
      "args": ["C:\\absolute\\path\\to\\mcp\\dist\\index.js"]
    }
  }
}

• Windows %APPDATA%\Claude\claude_desktop_config.json

• macOS ~/Library/Application Support/Claude/claude_desktop_config.json

Hosted clients — ChatGPT, Claude web, Gemini, Antigravity

These cannot spawn a local process; they connect to a URL. Run the HTTP transport:

export MCP_HTTP_TOKEN="$(openssl rand -hex 32)"   # required for any non-loopback bind
npx -y -p linkedin-mcp-bridge linkedin-mcp-http     # → http://127.0.0.1:3000/mcp

Then add it as a custom connector with the URL and an Authorization: Bearer <token> header.

A hosted client cannot reach your laptop directly, so expose the port with a tunnel (cloudflared tunnel --url http://127.0.0.1:3000, ngrok http 3000, or a reverse proxy) and give the client the public URL.

This endpoint acts as you on LinkedIn. Anyone who can reach it can post, message and connect as you. The server refuses to bind to a non-loopback address unless MCP_HTTP_TOKEN is set — do not remove that check, and always terminate TLS at your tunnel or proxy.

Any other MCP client

Any stdio MCP client works: run npx -y linkedin-mcp-bridge and speak JSON-RPC over stdin/stdout. Note that stdout carries the protocol — all logging goes to stderr and data/logs/.

First run

Start with dry-run enabled so nothing can touch your real account while you explore:

DRY_RUN=true

Every mutating tool then validates its arguments and reports what it would do without doing it. Turn it off when you are ready.

Try these:

Check my LinkedIn session status Read my LinkedIn profile and suggest improvements Search for remote machine learning jobs posted in the last week

What it can do

Full catalogue: npm run tools:list, or ask the assistant to call linkedin_list_tools.

Example workflows

Tailor an application end to end

Find remote LLM engineer jobs in Germany posted this week. For the three best matches, analyse how well my profile fits, generate a tailored resume for each, and draft a cover letter addressed to someone on the hiring team.

The assistant chains linkedin_search_jobs → linkedin_analyse_job_fit → linkedin_generate_resume → linkedin_get_hiring_team → linkedin_generate_cover_letter.

Bulk apply, safely

Apply to all Easy Apply data engineering jobs in Berlin using resume.pdf. My phone is +49 30 12345678 and I have 5 years of Python experience.

linkedin_apply_to_jobs_bulk introspects each employer's form, answers from what you supplied plus remembered answers, and stops rather than guessing at any required question it cannot answer confidently — reporting exactly which ones, so you can supply them and retry.

Improve a profile

Read my profile, score it, then rewrite my About section to target AI engineering roles and add the three skills I am missing.

Recruiter outreach

Find recruiters hiring AI engineers in Berlin, draft a personalised message for each based on my background, and show me the drafts before sending anything.

More in examples/.

Safety

The defaults assume you would rather be slow than restricted.

Daily quotas persist to disk, so restarting the server cannot be used to sidestep them.

Raising these limits materially increases the risk of a temporary account restriction.

Self-healing

LinkedIn rewrites its markup continuously and hashes class names per build. The usual result is a control that quietly stops resolving, a fix that is one line long, and a wait for someone to ship it.

Instead, when every shipped selector misses, the server asks your model to work out where the element went:

1. It captures a structural outline of the page — tags, roles, ARIA labels, stable data-* hooks, href shapes. Never text.

2. It asks for candidate selectors via MCP sampling, so the request goes to the model your client is already running. No API key, no separate billing, no third-party service.

3. It verifies each candidate against the live DOM and keeps only what resolves.

4. It remembers what worked and tries it first next time.

Requires a client that supports sampling. Without one the feature stays off and selector failures behave exactly as before.

What it will not do

Reviewing repairs

"show me any selectors the server has relearned"     → linkedin_selector_repairs
"forget the relearned connect button"                → linkedin_selector_repairs { forget: true, label: "connect button" }

Repairs are local to your machine. If one works, please open a PR with it — that is how the fix reaches everyone else instead of each user relearning it independently.

Turn the whole thing off with SELECTOR_REPAIR=false.

Configuration

Every setting lives in .env — see .env.example for the annotated list. The most useful:

TRANSPORT_STRATEGY=auto      # auto | api | browser
BROWSER_HEADLESS=true        # false to watch automation live (great for debugging)
LOG_LEVEL=info               # trace | debug | info | warn | error | silent
DEBUG_ARTIFACTS=true         # screenshot + HTML dump on browser failures
CACHE_TTL_MS=300000          # read cache lifetime

Set exactly one authentication source — see Authenticate.

Troubleshooting

PROFILE_LOCKED Something else is using the Chrome profile — Chrome allows exactly one process per user-data directory. Your session is fine; do not re-export cookies. Usually a second copy of this server, a linkedin-mcp-setup window still open, or a Chrome you launched from that profile. Close the extra one, or restart your MCP client if it has accumulated duplicate servers, then retry.

Older versions reported this as AUTH_EXPIRED, which sent people to redo a sign-in that was never broken. If you see that on an old build, upgrade.

AUTH_EXPIRED / AUTH_MISSING Run npm run cookies:check — it reports which strategy resolved and flags conflicting ones. If the session is dead, re-run npm run setup:profile (or npm run login). See docs/authentication.md — in particular the section on cookies exported from the login page, which look valid but are not.

My browser profile is being ignored LINKEDIN_LI_AT and LINKEDIN_COOKIE_FILE both outrank LINKEDIN_BROWSER_PROFILE. Comment them out. npm run cookies:check names the winner.

SELECTOR_NOT_FOUND / UI_CHANGED LinkedIn changed its markup. Check the screenshot in data/artifacts/, then add a candidate to the relevant list in src/browser/selectors.ts. No other code needs to change.

RATE_LIMITED Back off. Lower RATE_LIMIT_REQUESTS_PER_MINUTE. Sustained throttling can escalate.

QUOTA_EXCEEDED A self-imposed safety limit, not LinkedIn. Wait for the window to roll over, or raise the corresponding RATE_LIMIT_* value if you accept the risk.

Browser will not launch npx playwright install chromium. If using LINKEDIN_BROWSER_PROFILE, close Chrome completely — Chromium cannot share a locked profile.

Browser hangs for ~180s, then times out Chrome 136+ refusing to automate a primary Chrome user-data directory. The silent hang is the symptom — there is no error until the timeout. Run npm run setup:profile to create a dedicated profile and point LINKEDIN_BROWSER_PROFILE at that instead.

Watch it work Set BROWSER_HEADLESS=false and LOG_LEVEL=debug.

Architecture

src/
  core/        config, logger, errors, tool registry, response envelope,
               retry/backoff, rate limiting, TTL cache, shared types
  auth/        cookie parsing and normalisation, session lifecycle
  browser/     Playwright manager, LinkedInPage wrapper, selector registry
  voyager/     internal API client and normalized-JSON graph decoder
  domains/     profile, posts, network, messaging, jobs, applications,
               companies, recruiters, search, notifications, settings, documents
  tools/       MCP tool definitions (schemas + descriptions)
  storage/     local store for applications, drafts, remembered answers
  export/      JSON / CSV / JSONL / Markdown writers
  cli/         login, session check, cookie import, tool listing

The registry (src/core/registry.ts) is the keystone: it wraps every tool with argument validation, rate limiting, quota enforcement, dry-run interception, confirmation gating, timing and error normalisation. That is why individual tool handlers stay short — the repetitive parts happen exactly once.

Development

npm run dev        # watch mode
npm run typecheck  # strict type check
npm run build      # compile to dist/

Adding a tool: write the domain logic in src/domains/, define the tool with defineTool() in src/tools/, and add it to the array in src/tools/index.ts. The registry handles everything else.

Smoke test

npm run smoke exercises every registered tool against your live session. It forces DRY_RUN=true, so reads hit LinkedIn for real while writes are intercepted and validated without being sent. Fixtures (a post, a job, a conversation) are discovered from your own account at runtime — nothing is hardcoded.

npm run smoke                      # every tool
npm run smoke -- --only jobs -v    # one category, with failure detail
npm run smoke -- --skip-writes     # reads only
npm run smoke -- --json            # machine-readable report

A handful of tools are skipped by design: those that print live credentials (auth_export_cookies), tear down the session the suite depends on (system_reset, auth_reload), or have irreversible LinkedIn-side effects even in dry run (request_data_export, mark_notifications_read). Tools whose fixture is missing from your account — messaging tools on an empty inbox, for example — are reported as skipped rather than passed.

Releasing

Releases are tag-driven and fully automated by .github/workflows/publish-mcp.yml. Pushing a v* tag publishes the npm package and then registers it with the MCP Registry.

npm version patch          # bumps package.json
# bump "version" and packages[0].version in server.json to match
npm run validate:registry  # fails loudly if anything disagrees
git commit -am "Release v1.0.4" && git tag v1.0.4
git push origin main --tags

server.json is the registry manifest. npm run validate:registry checks it against the $schema it declares using ajv, then verifies the invariants the schema cannot express:

The workflow authenticates to the registry with GitHub OIDC, so the only secret the repository needs is NPM_TOKEN (an npm automation token). npm publish runs first — registry validation fetches the published package — and is skipped if that version is already on npm, so a re-run after a partly failed release still completes.

Limitations

Stated plainly, because silent failure is worse than a clear "no":

• Premium features (InMail to strangers, full analytics, Recruiter) need a paid account. Tools report this rather than failing obscurely.

• Scheduled posting is not supported — LinkedIn's scheduler has no automatable surface. Use local drafts plus your own scheduler.

• Most account settings are read-only here. LinkedIn's settings UI has no stable hooks and a mis-click has real privacy consequences, so only unambiguous toggles are writable; the rest come with direct links.

• Skill extraction from job descriptions is keyword matching against a curated vocabulary — deliberately conservative, since a false "requires Rust" is worse than an omission.

• Recruiter identification is inferred from headline patterns; LinkedIn has no recruiter entity type. Every match carries a score and its reasoning.

• Resume generation assembles and organises real profile data. It never invents experience, and reports what it could not source.

Responsible use

This automates your own LinkedIn account, from your own machine, using a session you signed into yourself. There is no server in the middle and no credential ever leaves your computer. You remain responsible for what it does.

Read this before you use it. LinkedIn's User Agreement restricts automated access — §8.2 prohibits using "software, devices, scripts, robots… to scrape the Services" and using "bots or other automated methods to access the Services." Using this tool may violate that agreement, and LinkedIn can restrict or terminate accounts for it. That risk is yours, it is real, and no amount of care in this codebase removes it.

The conservative defaults exist for that reason. Keep them, prefer targeted actions over volume, and treat a daily quota as a ceiling rather than a target.

What this deliberately does not do:

• No credential handling. It never accepts, stores, or types a password. Authentication is a browser session you established yourself.

• No evasion by default. BROWSER_STEALTH is off, and LinkedIn's own bot-detection endpoint is not blocked. Automating your own account does not require concealing that it is automated, and the project takes the view that it should not try to.

• No bulk harvesting. There is no multi-account support, no unattended crawling, and no mass outreach. Volume is what gets accounts restricted and what makes a tool a scraper.

• No data collection by us. No telemetry, no analytics, no phone-home. Everything stays in your data/ directory.

If you export other people's data, that data is theirs and may be regulated where you or they live (GDPR, India's DPDP Act, and similar). Exporting a profile is a decision with obligations attached; the tool will not make it for you.

Do not use this to spam, to scrape people who have not consented, or to misrepresent qualifications. Generated resumes and letters are drafts built from your real profile — review them before they reach another person.

Trademark

This is an independent, unofficial project. It is not affiliated with, endorsed, sponsored by, or connected to LinkedIn Corporation in any way. "LinkedIn" is a trademark of LinkedIn Corporation, used here only to describe what this software interoperates with.

License

MIT — provided "as is", without warranty of any kind. See LICENSE.