LinkedIn MCP server

What this is

The Model Context Protocol is how an AI client discovers and calls tools on a server it did not ship with. This server puts two things behind that protocol. The first is LinkedIn: the model can search for people matching an ICP, read a profile down to its work history and latest post, pull a member's recent posts and list an account's first-degree connections — each call running through a connected sender account in your workspace, seeing exactly what that account sees. The second is the outreach workspace itself: campaigns and their funnel numbers, lead lists, the unified inbox across every sender, the approval queue, and one tool that pauses a campaign.

Everything reads except pause_campaign. There is no tool that sends an invite, a message, a reply, a follow or a like, and there is not going to be one — the reasoning is under what it does not do.

It is a real endpoint, not a waitlist. https://topclozer.com/api/mcp answers an unauthenticated GET with what it is and which tools it exposes, so you can check it before wiring credentials:

curl -s https://topclozer.com/api/mcp

{
  "server": "topclozer-mcp",
  "version": "1.1.0",
  "protocolVersion": "2025-06-18",
  "transport": "http",
  "auth": "Authorization: Bearer <workspace API key>",
  "tools": ["search_linkedin_people", "get_linkedin_profile", "get_linkedin_posts", "list_linkedin_connections", "list_sender_accounts", "get_usage", "list_campaigns", "get_stats", "list_leads", "get_inbox", "list_tasks", "pause_campaign"]
}

What it can do

12 tools on two surfaces. The 4 LinkedIn tools reach a live session through a connected sender account and share a rate limit; the 8 workspace tools read our own database and are unlimited. Each name links to its full reference — arguments, response shape, error cases:

Reads LinkedIn

Reads your workspace

Quickstart

Two things are needed: a workspace API key (Developer → Create a key (MCP), in the app) and one command. For Claude Code:

claude mcp add --transport http topclozer https://topclozer.com/api/mcp \
  --header "Authorization: Bearer tcz_live_YOUR_KEY"

Or, to check the endpoint from a shell before involving a client at all:

curl -s https://topclozer.com/api/mcp \
  -H "Authorization: Bearer tcz_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Claude Desktop, the exact config JSON, a first working call and the troubleshooting list live on the Claude setup page.

Authentication

Every call except discovery needs a workspace API key. Keys are minted in the app, shown once, stored only as a SHA-256 hash, and revocable from the same screen. Three ways to present one, in the order the server checks:

• Authorization: Bearer tcz_live_… — use this one.
• X-Api-Key: tcz_live_… — for clients that reserve the Authorization header.
• ?key=tcz_live_… — for clients whose UI accepts a URL and nothing else. It works, but query strings land in access logs, so prefer a header when you have the choice.

A key identifies one workspace; every tool call is scoped to it and cannot see another. An unknown or revoked key gets HTTP 401 with JSON-RPC error -32001 — it never falls back to a browser session, so a stale key fails loudly instead of quietly answering as someone else.

Protocol details

JSON-RPC 2.0 over HTTP POST. Protocol version 2025-06-18 (the 2025-03-26 and 2024-11-05 versions are also accepted during the handshake). Methods implemented:

• initialize — answered before auth so a client can complete the handshake and surface a clean 401 on the first real call rather than an opaque connection failure.
• notifications/* — acknowledged with 202 and an empty body. Notifications carry no id and must not be answered with a result.
• ping — returns an empty result.
• tools/list — all 12 tools with their input schemas. Requires a key.
• tools/call — runs one tool. Requires a key.

A call and its envelope:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": { "name": "get_stats", "arguments": {} }
}

// response
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      { "type": "text", "text": "{\n  \"senders\": 4,\n  \"campaigns\": 3,\n  …\n}" }
    ]
  }
}

Tool results come back as MCP content blocks: a single text block whose body is the tool's JSON, pretty-printed. Parse that string; it is not returned as structured content.

Error codes

What it does not do

The short version of the boundary, so nobody installs this expecting the other half:

• No sending. No tool sends an invite, a message, a reply, a follow or a like. Outbound actions are released by the product under the workspace sending policy — by default, after a person approves them. Sending is the irreversible action, and an agent having a bad hour should not be able to burn an account.
• The LinkedIn tools are rate limited — 30 calls per 5 minutes, per workspace, shared across them and enforced with a 429. An agent retrying in a loop is the request pattern that gets an account restricted; this is the limit that stops the loop reaching LinkedIn.
• No LinkedIn without an account. The LinkedIn tools need a connected sender account in the workspace. Without one they return a readable error rather than silently returning nothing.
• People only. People search, profiles, posts and connections are implemented. Company search, job search and message sending are not.
• No campaign creation or editing, no lead import, no resume — pause is the only state change an agent can make.
• No MCP resources or prompts. The server advertises the tools capability only.
• No SSE stream and no server-initiated notifications. A GET asking for text/event-stream answers 405.
• No OAuth. Authentication is a workspace API key; there is no authorization-server metadata to discover.
• No paging or filters on list_leads and get_inbox — they return the full set and you filter client-side.

The account an agent drives

The install nobody warns you about: the tools operate a workspace, and a workspace only sends from a connected LinkedIn account. Pointing automation at your own profile is against LinkedIn's User Agreement and is the usual way a profile ends up restricted — which is why most teams put a separate account behind the automation.

We do not sell accounts, so there is no pitch here, only the two honest routes: rent a managed verified account when you want it operated and replaced if it goes down, or buy an aged account outright when you want to own it. The trade-offs are laid out on accounts for agents.

Setup, per client

Nothing here is Claude-specific. Any client that can add a remote MCP server over HTTP connects to the same endpoint with the same key — but the config differs enough between them to be worth writing down separately, and each of these was checked against that client's own documentation rather than recalled.

Everything else takes the same endpoint and a way to send the key, and needs no page of its own:

Claude Code

One command: claude mcp add --transport http. Documented on the Claude page.

Claude Desktop

A config block, also on the Claude page.

Windsurf, Zed, Cline, Roo

All take a remote MCP server over HTTP. The Cursor config is the closest template — a url plus an Authorization header.

n8n and Make

Either an MCP client node or a plain HTTP request with the JSON-RPC body from the tool reference. The endpoint does not care which.

Your own agent

JSON-RPC 2.0 over HTTP POST. The envelopes are on the tool reference; there is no SDK to install.

Clients that let you set headers should send Authorization: Bearer; clients whose dialog accepts only a URL can use the ?key= form — ChatGPT is the notable one, and its page explains the trade-off. If your client requires an SSE transport or OAuth, it will not connect; see the limits above.

FAQ

Next: every other LinkedIn MCP server, compared · the Claude install · the tool reference · pricing