How is a LinkedIn MCP server different from the scrapers on GitHub?
Most open-source LinkedIn MCP projects expose read-only lookups: fetch a profile, run a search, read an inbox. They cannot run outbound, because outbound is a write with consequences. The difference is not model quality, it is whether the server will send and what happens when it does.
What the open-source cohort does well
Reading. Profiles, companies, jobs, messages. If you want an agent that can look things up during a conversation, several of these work and cost nothing.
They are genuinely useful and they are not competing for the same job.
Where they break
Sending. Their issue trackers tell the story: the open feature requests are read-side (post permalinks, reaction data, inbox filters) while the bug reports cluster on writes failing. Message sending failing after structural changes, line-break rejections, sends failing on profiles with active messaging buttons.
That is what cookie- and browser-session architecture costs. Every time LinkedIn changes its DOM, sending breaks. For a lookup that is an annoyance. For a campaign mid-flight it is a silent failure you find out about a week later.
The part nobody in that cohort has built
Enforced caps, warm-up ramps, suppression memory, approval gates, and restriction reporting. Not because they could not, but because none of them send at volume where it matters yet.
If you are running one account casually, a free reader is fine. If a restriction would cost you a pipeline, the constraint layer is the product.
Read-only MCP server vs a sending one
| Capability | Typical open-source | LinkedBoost |
|---|---|---|
| Read profiles and companies | Yes | Yes |
| Search | Yes | Yes, through your seat |
| Send invitations and messages | Partial, breaks often | Yes |
| Sequences with reply-stop | No | Yes |
| Enforced caps and ramps | No | Yes, server-side |
| Approval gate before every send | No | Yes |
| Suppression from your own history | No | Yes |
Questions people ask next
Are there free LinkedIn MCP servers?
Yes, several on GitHub. They are read-first: profiles, companies, jobs and messages. Sending is where they struggle, because browser-session architecture breaks when LinkedIn changes its markup.
Why does sending break on those servers?
They drive a logged-in browser session. Any change to LinkedIn's page structure can break the send path, and the failure is often silent.
Do I need a paid MCP server?
Only if sending matters. For lookups during a conversation, a free reader is the right tool.
Why this page exists: Issue trackers of the open-source LinkedIn MCP cohort, read September 2026
LinkedBoost is the LinkedIn MCP server: your agent sources, drafts, sends and works the inbox, inside caps the server enforces rather than suggests.
Related answers
An MCP server gives an AI assistant hands. Without one the assistant can describe what to do; with one it can do it, in your account, against real state. The value shows up only when the task is mechanical, repeated and needs live data.
Two places, and no third. Search runs through your own LinkedIn seat using your own entitlement, and you can import your own CSVs. There is no bundled contact database and no purchased data, which is a deliberate product decision rather than a gap.