Linked API MCP

It can reach everything you can, which is the point and the problem. Section 8.2 of the User Agreement bars bots and scraping by any means, and enforcement lands on the account rather than on the software.

The server writes to LinkedIn as you, over a route LinkedIn does not sanction. Automated messages and connection requests under a member’s own name are what the enforcement is built to catch, and the account is what it acts on.

Two tokens copied from the vendor dashboard: a workspace token and one identification token per connected LinkedIn account. They are read from environment variables, from HTTP headers, or from query parameters on the hosted endpoint. Admin tools need only the workspace token. No session cookie and no LinkedIn password is ever handled by the server — grepping the source for those returns nothing. Per the vendor's safety page you sign in to LinkedIn yourself inside your isolated cloud browser, and the vendor states it does not store the password. The session that drives LinkedIn is a real signed-in browser, which is why this is filed as a browser server rather than a vendor one.

Hosted route: nothing local — paste a URL with your two tokens into the client's connector settings. Local route: Node.js and npx; the Dockerfile builds on Node 20, so that is the tested baseline, but package.json declares no engines field. Docker is optional. No local headless browser is needed, because the browser is the vendor's. Hard requirements either way: a paid seat, a real LinkedIn account connected by signing in inside the vendor's cloud browser, and for the Sales Navigator tools a Plus seat plus the account's own Sales Navigator subscription.

Claude (claude.ai and Claude Desktop, as a custom connector); Claude Desktop (local); Claude Code; ChatGPT (connector); Codex; Cursor; VS Code; Windsurf. Where the file goes in each Claude surface. The same block in Cursor. What a ChatGPT connector can and cannot reach.

stdio by default for the local package; streamable-http for the hosted endpoint.

A vendor-hosted remote endpoint added as a connector URL, or run locally through npx. The repository also ships a Dockerfile. In every case the LinkedIn work still runs on the vendor's cloud, not on your machine.

Eight dedicated tools: Sales Navigator people search, company search, profile fetch, company fetch, message send, thread read, inbox sync and thread management. The docs state these run on a Plus seat and require the connected account to hold its own Sales Navigator subscription.

Nothing in the registered tools touches Recruiter or Recruiter Lite — the word does not appear in the source. The README markets a recruitment use case, but that is served by the ordinary search, fetch and message tools.

The write tools act as your own LinkedIn account and carry the account risk; the read tools are lower risk but are still automated access. The User Agreement prohibits using "bots or other unauthorized automated methods to access the Services, add or download contacts, send or redirect messages, create, comment on, like, share, or re-share posts", and separately prohibits software, scripts or robots used to scrape or copy the Services. Everything this server does falls under those clauses. The vendor is explicit that it is "An independent product, not affiliated with, authorized by, endorsed by, or sponsored by LinkedIn Corporation." Its stated mitigations are one dedicated, non-headless cloud browser per account on a stable residential address in your region; device-fingerprint matching; human-paced actions; and per-action daily, weekly and monthly caps you configure, which stop and return an error when hit. These are mitigations, not an exemption: an account driven by this server can still be restricted, and only the account holder bears that. One practical guardrail worth knowing: actions are queued asynchronously, and the source repeatedly warns that retrying the original tool queues duplicate work — a naive agent retry loop can send duplicate messages, connection requests, posts, comments and reactions.

On the hosted route both long-lived tokens are passed as URL query parameters. They land in client config files and are the kind of value that ends up in proxy and application logs; the server accepts headers too, but every documented client config uses the query-string form. The server logs at info level by default and writes the full tool arguments on every call and the full result on success, so outgoing message bodies, post text and fetched profile data are written to the log stream unless the log level is raised. Admin tools are workspace-scoped and need only the workspace token: an agent holding it can change billing seats, rotate tokens, relax rate limits and irreversibly disconnect the account. The custom-workflow tool accepts an arbitrary action definition, so allowlisting by tool name does not constrain it. The vendor states it never sees or stores the LinkedIn password and that the authenticated session is unreachable even by its own team; that is a vendor claim, not something verifiable from the client source.