Using a LinkedIn MCP Server in Cursor

This question gets asked by developers, which makes sense. Cursor is a code editor with an AI assistant built in, it added support for MCP — the Model Context Protocol, an open standard for connecting AI assistants to outside tools — and once your editor can call tools, it is natural to wonder what else you can wire into it. LinkedIn is a fair thing to wonder about, especially if you ship things and then write about shipping them.

The honest answer has three parts: yes, the editor side of this is a real capability; no, we have not tested Kalovio there; and the fit is a little odd in a way worth thinking about before you spend an hour on it.

Does Cursor support MCP servers?

Yes. Cursor is one of the editors that adopted MCP, and MCP servers come in two shapes:

• Local servers — a program that runs on your own machine and talks to the editor over standard input and output (the same pipes a command-line tool uses). Most open-source MCP servers ship this way.
• Remote servers — a server that already runs on the internet at a normal web address, which the client connects to over HTTP. Nothing gets installed. Kalovio is this kind.

The distinction matters because it changes what you have to do. A local server means installing a runtime, cloning a repository, and putting credentials somewhere on disk. A remote server means pointing the client at a URL and signing in.

What does adding a remote MCP server to an editor actually involve?

Conceptually it is short, and the shape is the same across every client that supports remote servers. Knowing the shape is more useful than memorising one product’s buttons, because the buttons move.

• One config entry naming the server. You give it a short name of your choosing and the server’s URL. For Kalovio the URL is https://kalovio.com/mcp. In some clients you type this into a settings screen; in others you add it to a JSON (a plain-text format for settings) file. Same idea either way.
• A sign-in step, handled by the server. A remote MCP server that acts on your behalf has to know who you are. Kalovio uses OAuth — the standard “sign in and approve” flow you have used on a hundred websites. The client opens a page in your browser, you approve, and the client receives a token (a limited key). You never paste a password or a session cookie into the editor.
• A second sign-in, to LinkedIn itself. Kalovio then sends you to LinkedIn’s own consent screen once, which is what grants permission to publish for you. These two sign-ins are deliberately kept apart: the client’s token is never passed to LinkedIn, and the LinkedIn token never reaches the editor or the model.
• The tools appear. If it worked, the assistant lists the server’s tools and can call them when you ask.

That is the whole conceptual model. The friction is never the idea; it is that each client puts the config in a different place and supports OAuth to a different degree.

Can I use Kalovio in Cursor?

We do not know, and we would rather say that than guess.

Kalovio is confirmed working in Claude (as a custom connector, and it works on Claude’s free plan) and confirmed working in ChatGPT (which needs Developer Mode — available on paid plans, on the web, with the connector switched on per conversation). Those two have been used for real. Cursor has not been tested, so anything we told you about how it behaves there would be an invention rather than a report.

What we can say is what would have to be true for it to work, so you can judge the odds yourself:

• The client must support remote MCP servers over HTTP, not only local ones.
• It must support the OAuth sign-in flow for those servers, including opening a browser and handling the return trip. This is the step most likely to be missing in editor-style clients, because the first wave of MCP support was built around local servers with an API key sitting in a config file.
• It must let the model actually call the tools it discovers, rather than only listing them.

If Cursor’s current documentation says it does all three, there is a good chance it works. If you try it, the fastest sanity check is to ask the assistant to run the account status tool: it reads nothing and posts nothing, so if it comes back with your name, the connection is real.

Does connecting in one app carry over to another?

No, and this one catches people out. Connecting an MCP server inside ChatGPT on the web does not carry over to Codex, and by the same logic nothing you connect in one app appears in Cursor. Every client keeps its own server list and its own sign-in. You will approve LinkedIn again in each place. Nothing has gone wrong when that happens — that is the design.

Does posting to LinkedIn from a code editor even make sense?

Worth asking before you spend the time, because the fit is genuinely a bit odd.

A code editor’s assistant is built around your repository. It is good at questions whose answer lives in your files. LinkedIn posting is close to the opposite: the input is a thought, the output is public, and the only review step that matters is you reading the exact words before they go out. None of that benefits from having your source tree in context.

There is also a plainer point. You can already write and publish from Claude in a browser tab on a free plan. If that is available, doing the same job inside the editor adds setup and removes nothing.

When it genuinely helps

There are real cases, and they share one shape — the post is about the code in front of you:

• Release notes into a post. The assistant already has the changelog and the diff open. Asking it to turn that into a short post, then approving the wording, saves a copy-paste round trip through another app.
• Build-in-public updates. If you post weekly about what shipped, the editor is where the raw material lives.
• Feeding a queue from a scripted routine. If you already generate content as part of a repository task, dropping it into a posting queue without leaving the editor is coherent.

Outside those, a browser is the simpler tool. The setup effort is small either way; it is the ongoing context-switch that decides it.

What will not work, in Cursor or anywhere else

These limits come from LinkedIn, not from the client, so no editor and no config routes around them. Knowing them up front stops you debugging something that was never possible.

Two more look like bugs and are not. Multi-image posts and PDF carousels go through LinkedIn’s newer versioned interface, which may not be switched on for every self-serve app — you get a clear refusal rather than a silent failure, and the only way to know is to try it on your own account. Document posts also publish immediately; scheduling them is not wired up yet.

Is any of this allowed under LinkedIn’s rules?

That approval step is also the security control that matters most inside an editor. Kalovio’s publish, schedule, queue and delete tools are two-step: the first call returns a preview plus a signed token covering the exact content, and nothing happens until a second call arrives with your confirmation and a matching token. In a code editor the assistant is reading files, dependencies and documentation all day, any of which could contain text written to instruct a model. The confirm gate is what stops a stray line in a README from turning into a public post.

It is worth contrasting this with the most-searched LinkedIn MCP server on GitHub, which many developers find first. It is a scraper driving a browser session with your cookie, its README states it “does not publish or create posts on your behalf”, and it warns that accounts “can be restricted or banned”. If your goal is posting, that project is not the tool, whatever editor you put it in.

What to do if it does not connect

Work through these in order rather than changing several things at once:

• Confirm the client supports remote servers with OAuth in its current documentation. If it does not, no config fixes that, and a browser client is the answer.
• Check the URL exactly — https://kalovio.com/mcp, including the path.
• Watch for the browser window. If no sign-in page ever opens, the client is not running the OAuth step, which is a gap on its side rather than the server’s.
• Restart the editor after editing config. Most clients read the server list at startup.
• Test with a read-only tool first. Account status proves the connection without publishing anything.

If it does work for you in Cursor, that is genuinely useful information — we would rather update this page with a confirmed report than keep hedging.

The short version

Cursor supports MCP, and remote servers are the low-friction kind, so trying a LinkedIn MCP server there is a reasonable instinct. Follow Cursor’s own documentation for the config, because ours would be a guess. Treat Kalovio in Cursor as untested — Claude and ChatGPT are the confirmed paths. And be honest about the fit: unless the post is about the code in front of you, a browser is the simpler place to write it.