Cursor speaks MCP natively and takes remote servers over HTTP, which means there is nothing to install: no npm package, no local process, no mcp-remote bridge. A remote entry in Cursor's config is a URL and a headers object, so the workspace key travels in an ordinary Authorization header exactly as the API expects it. That makes Cursor the least fiddly of the four clients here.
Authentication in one line
What Cursor gets
4 LinkedIn tools plus the workspace ones. All read-only — Cursor can research LinkedIn; it cannot contact anybody through it.
Setup
Generate a key
In TopClozer, Developer → Create a key (MCP). It is shown once and stored only as a hash, so copy it now.
Create the config
Put the block below in ~/.cursor/mcp.json to have the tools everywhere, or in .cursor/mcp.json in a project to scope them to it. Cursor also has a UI for this under Settings → Tools & MCP.
Reload
Cursor picks the file up on reload. The server should appear in Tools & MCP with its tool list expanded.
Ask for something
"Find VP Engineering people at fintech companies in Berlin and tell me which three are worth approaching." The agent will call search_linkedin_people and then read the profiles.
The config
Lives in ~/.cursor/mcp.json for every project, or .cursor/mcp.json inside one. Swap the key and you are done.
{
"mcpServers": {
"topclozer": {
"url": "https://topclozer.com/api/mcp",
"headers": {
"Authorization": "Bearer tcz_live_YOUR_KEY"
}
}
}
}Verify it works
Ask Cursor: “which TopClozer tools do you have?” — 12 should come back. To check the endpoint independently of the client, an unauthenticated GET returns the server name, version and tool list:
curl -s https://topclozer.com/api/mcpIf the tool list is empty but the connection succeeded, the problem is the key rather than the URL: the MCP handshake is answered before authentication, on purpose, so a client can complete initialize and then surface a clean 401 on the first real call instead of failing with an opaque connection error.
Cursor gotchas
Specific to this client. None of these are guesses — each one has cost somebody an evening.
- A project config does not inherit the global one
- If you keep .cursor/mcp.json in a repo, that file is what Cursor reads there. A server defined only in ~/.cursor/mcp.json will not appear.
- The key is in a file in your home directory
- Which is fine until the project config ends up in git. Put .cursor/mcp.json in .gitignore, or keep the server global and out of the repo entirely.
- An empty tool list means auth, not transport
- The handshake is answered before authentication, so a bad key connects cleanly and then fails on the first call. Check the header before you check the URL.
What it will not do
- Send anything. No invite, message, reply, follow or like. Every tool reads except pause_campaign, and outbound stays behind human approval in the product.
- Work without a connected account. The LinkedIn tools run through a sender account in your workspace. Without one they return a readable error saying so — accounts for agents covers how teams get one.
- Run unlimited. 30 LinkedIn calls per 5 minutes per workspace. An agent retrying in a loop is the request pattern that gets accounts restricted.
FAQ
Do I need to install anything?
No. TopClozer is a remote HTTP server, so Cursor talks to it directly. You do not need npx, mcp-remote, Docker or a local process — that requirement belongs to the open-source LinkedIn servers that run a browser on your machine.
Can Cursor send LinkedIn messages through this?
No. Every tool is read-only except pause_campaign. Cursor can search, read profiles and read posts; it cannot invite, message or reply. Sending stays behind human approval inside the product.
Which LinkedIn account does it use?
A sender account connected to your TopClozer workspace, not your personal profile. Call list_sender_accounts to see which identities are available and which one is used by default.
Other clients: ChatGPT · VS Code · Claude · the tool reference