LinkedIn Sales Navigator MCP Server

MCP server that gives AI assistants (Claude Desktop, Claude Code, any MCP client) access to LinkedIn Sales Navigator contact and account search — by driving a real, logged-in browser on your machine and capturing Sales Navigator's own search API responses.

Why this design (and why not cookie-replay)

The common approach — copy your li_at + JSESSIONID cookies and replay them as HTTP requests from a server — gets you logged out repeatedly. LinkedIn scores each session on IP, browser fingerprint, TLS, and the full cookie set; two replayed cookies from a different machine look like a hijacked session, so it invalidates them.

This server does the opposite. It keeps a persistent browser profile you log into once, by hand, and then lets that genuine session do the work:

MCP client (Claude) ──stdio/HTTP──> this server ──drives──> your logged-in Chromium ──> Sales Navigator
                                                    │
                                          captures the JSON the browser
                                          itself receives (page.on "response")

Every request to LinkedIn originates from the real browser: your IP, your fingerprint, your full cookie jar, browser-generated CSRF/track headers, and the session is refreshed by the browser as normal. Nothing is replayed or reconstructed. That is what keeps you signed in.

We never automate the login itself — typing credentials is a strong bot signal. You sign in manually once; the profile persists.

Tools

Both search tools take a full Sales Navigator URL (build the search in the UI, copy it from the address bar) and a pages count (1–10, 25 results each).

Beyond tools, the server exposes one resource (sales-nav://queries — saved queries and their progress as attachable JSON context) and one prompt (sales_nav_search_workflow — the step-by-step prospecting playbook, for clients that support MCP prompts).

Search tools do not return the records

This is deliberate, and it is the thing most likely to surprise you. Records go to SQLite; the tool returns only a status object, so a 250-row scrape doesn't dump 250 rows into the model's context:

{
  "url_hash": "a6ca46c9365bce93",
  "scraper_type": "contacts",
  "status": "paused",              // new | in_progress | paused | complete
  "new_records_this_call": 25,
  "total_records": 25,
  "total_available": 11897313,
  "pages_fetched": 1,
  "last_page": 1,
  "next_page": 2,                  // null once exhausted
  "raw_dir": null,                 // set when include_raw=true
  "suggestion": "Saved 25 records so far (through page 1) ..."
}

To get at the data, call get_results (a sample) or export_results (files), or read the SQLite database directly.

Pipeline depth

How far a query is taken is a property of the query, not of the call that made it, so a run resumed tomorrow knows what the search was collected for.

search_contacts(url, pages=4, depth="open_profile")

Depth is stored on the query and echoed back with a next_step. Requesting a depth the server has not enabled is refused with an explanation rather than silently downgraded, so a default install cannot be pointed at a list and made to pull thousands of full profiles.

enrich_leads and fetch_lead_profiles hit the same endpoint with different projections, and stay separate on purpose: the screen runs across a whole list to find who is free to message, the full fetch runs only for the leads you are about to write to. Merging them would pull heavy payloads for leads you never contact — and would make "recent activity" as stale as the screen.

Sending messages

This is the only capability that writes to LinkedIn, and it is treated differently from everything else here. Reading looks like a person browsing; a burst of messages looks like exactly what it is, and the consequence lands on your account rather than on the code. So every default is the cautious one:

Free vs paid, and why enrichment comes first

Open Profile members can be messaged without spending an InMail credit; everyone else costs one from a finite monthly budget. The compose window states which it is — "Free to Open Profile" versus "Use 1 of N credits" — and the sender reads that line, records the channel, and refuses the paid path unless you have explicitly allowed it.

That is why enrich_leads matters commercially and not just as metadata: next_outreach_batch returns only confirmed Open Profile leads by default, so the free channel is the path of least resistance.

Never twice

Outreach state lives in lead_outreach, keyed on (member_id, campaign), and the exclusion is global: anyone with a sent row in any campaign is filtered out of every future batch. Dedupe elsewhere in this server saves a wasted request; here it prevents messaging the same human twice because two searches happened to find them. member_id is the only identifier stable across searches, which is why it is the key.

State is committed per send, never per batch — a crash must not leave a message delivered on LinkedIn but unrecorded here.

The offer file stays yours

The server never generates copy and never learns what you sell. Your positioning lives in a Markdown file that is gitignored and not packaged:

cp offer.example.md offer.md    # then edit it
echo "OFFER_FILE=./offer.md" >> .env

The sales_nav_compose_message prompt renders that file together with the lead record and the drafting rules; your MCP client's model writes the message. With no offer file configured the prompt refuses to render at all.

The evidence gate

The drafting model must return the record fields it drew on:

{"subject": "...", "body": "...", "evidence_used": ["positions[0].title", "companyName"]}

Every entry is resolved against the lead record actually fetched. Name a field that does not exist and the message is rejected unsent. It is a cheap, deterministic check that "personalized" means grounded in data we really have — a message claiming a conference talk gets rejected because nothing supports it. Empty evidence_used is also rejected: that is a template, not personalization.

Unattended batches

Everywhere else the split is deliberate: the server decides who, your client's model decides what to say. That needs a human-driven turn — fine at a desk, useless on a schedule.