OpenClaw and LinkedIn:
what an agent can reach.

You have an agent runtime on your own hardware, it answers you in WhatsApp or Slack, and the obvious next question is whether it can do your LinkedIn work. Search for the answer and you get skill listings, MCP repositories and integration guides, most of which skip the fact that decides everything: LinkedIn publishes no API for the majority of what you want, so every route to it is a workaround, and the workarounds have very different prices.

This is the job-by-job version. What OpenClaw ships with, what it can reach without asking anything of your account, what needs your logged-in session, and what no runtime can do cleanly because LinkedIn exposes it to nobody. Then the half that is actually a purchase decision: what to check in an outreach tool before you hand an agent standing permission to act as you.

What OpenClaw is

OpenClaw is a self-hosted agent runtime and message router. It runs as a long-lived Node service on hardware you control, connects a chat channel to a model, and gives that model tools: files, a shell, a browser, and any MCP server you add. Peter Steinberger published it in November 2025 as Clawdbot and renamed it OpenClaw in January 2026.

Two of its concepts matter here. Skills are instruction packs, a SKILL.md file the agent's prompt lists by name and the agent reads when a task calls for it, to teach it a repeatable workflow using tools it already has. Channels are the messaging platforms the runtime speaks. The channel list is the first thing worth reading, because it explains the shape of the whole problem: OpenClaw's documentation lists 32 platforms, among them Slack, Discord, WhatsApp, Telegram, Signal and iMessage (OpenClaw channels documentation, checked October 2026).

LinkedIn is not one of them, and that is not an oversight. Every channel on that list has an official bot API, an open protocol, or a session you link from your own device, the way WhatsApp and iMessage are connected. LinkedIn offers none of these for the things salespeople want, so there is nothing to build a channel on.

What an OpenClaw agent can and cannot do on LinkedIn

An OpenClaw agent can read genuinely public LinkedIn pages and can publish to your own feed through LinkedIn's sanctioned API. It cannot search people, export a post's engagement, send a connection request, or message a stranger through any sanctioned route, because LinkedIn publishes no API for those. Everything in that second group runs on a logged-in session, yours or a vendor's.

Here is the table to read twice. The third column is the honest part: for most rows there is no clean route, only a choice of which workaround to pay for.

The two sanctioned rows are worth knowing precisely, because they are the only LinkedIn work an agent can do without connecting your account at all. Sign In with LinkedIn returns the authenticated member's own profile and nothing else. Share on LinkedIn grants w_member_social, which lets an application publish a post on behalf of the member who authorized it, and it is added from the Products tab of your app in the developer portal without a review queue (Microsoft Learn, LinkedIn developer documentation, checked August 2026).

An agent that drafts your weekly post, waits for you to say yes in Telegram, and publishes it under a scope LinkedIn hands out on request never leaves the official surface. That is also the ceiling of what that surface can do. The moment the job is outbound rather than outward, the sanctioned lane ends.

The three routes to LinkedIn, and what each one needs from you

Every OpenClaw LinkedIn setup you will find online is one of three shapes. They fail in different ways, so it is worth naming them separately.

The built-in browser tool. OpenClaw ships a single browser tool that opens, navigates, snapshots and acts on pages through a Chromium profile. By default that profile is isolated and logged into nothing. You can also point it at your real signed-in Chrome, and the documentation draws a clear line between the two: the isolated profile starts signed into nothing, while the real one lets the agent act inside your own browser session (OpenClaw browser tool documentation, checked August 2026). An isolated profile cannot do your outreach because it is not you. A signed-in profile can, because at that point the agent is acting with your own login, reading whatever text a stranger wrote along the way.

A community skill. ClawHub is the skill marketplace, and there are LinkedIn skills on it. Skills are markdown instruction packs with real access to the machine, and the marketplace has had a bad year. Snyk scanned 3,984 skills and found 283, about 7.1% of the registry, mishandling credentials by pushing secrets through prompts and logs in plaintext (Snyk, February 2026). Unit 42 later documented five malicious skills that got past scanning between February and May 2026, including two macOS infostealers calling command-and-control infrastructure, all since removed by OpenClaw (Unit 42, June 2026). A skill that would need your LinkedIn login to do its job is exactly the kind you want to know the provenance of before installing.

An MCP server. The agent calls a typed tool, the server does the LinkedIn work somewhere else, and the credential, if there is one at all, never sits in your prompt or your skill directory. This is the only one of the three that scales past a weekend, and it is the reason the buying question exists.

Put the idea to work

Less searching.
More conversations.

Tell Vera who you want to reach. Review the first message. Take it from there.

Ask Vera to find leads

Why MCP is the part that turns this into a buying decision

OpenClaw is a full MCP client, and that is the interesting fact for anyone shopping. It speaks stdio for local child processes, plus SSE/HTTP and Streamable HTTP for remote servers. For remote servers it does its own OAuth: an operator runs openclaw mcp add to register a server and openclaw mcp login to authorize it, tokens are stored in the runtime's SQLite state and refreshed automatically, and an oauth.identity: "per-requester" setting gives each sender their own account rather than one shared grant (OpenClaw MCP documentation, checked August 2026).

That last option matters more than it looks. One shared service account gives every person talking to your agent the union of everyone's permissions and leaves you no revocation story when someone leaves. If a vendor cannot do per-user authorization, you are buying a shared password with extra steps.

So the question stops being "does OpenClaw support LinkedIn" and becomes "which outreach tool exposes a remote MCP server my runtime can authorize". Asked of a different client, that is the subject of the map of every LinkedIn MCP server for Claude, and which of them need your account connected before they will do anything at all. The answer set is small, and it splits on one axis.

What to demand from an outreach tool before you connect it

Six questions, in the order that saves the most time. A vendor who cannot answer the first four in writing is not ready to hold a standing permission on your account.

1. Which tools need a connected LinkedIn account, named individually. Not "some". A list you can check line by line against what each tool actually does.
2. Where the credential lives. In their infrastructure behind an OAuth grant, or in a config file on your machine that a model can read.
3. Whether the grant is per user. One shared service account is one revocation problem and no audit trail.
4. Whether pacing runs on their server or in your prompt. Rate discipline enforced by instructions is rate discipline a model can be talked out of.
5. Whether a human approves each outbound action. The MCP specification asks for it directly: there should always be a human in the loop with the ability to deny a tool invocation.
6. What the tool annotations say, and whether you can read them before authorizing. readOnlyHint and destructiveHint both default to assuming the tool can write and can destroy when a server omits them, so an unannotated manifest tells you nothing about what it actually does. If you cannot see the manifest first, that is your answer.

Sending an invitation is different in kind from a search or a draft: it is irreversible, taken as you, visible to a stranger, and counted against a weekly ceiling you cannot raise. That is the action worth a human's explicit yes before it happens, not a vendor's assurance that pacing is handled somewhere behind the scenes.

Where BeReach fits, and where it does not

BeReach is an AI agent that finds people who just showed interest, writes one personal message per person, and sends from your own account at a paced rate, with every send approved by you. It is not a scraper and it is not unattended automation. The reason it appears in an article about agent runtimes is the connector: a remote MCP server your client authorizes once over OAuth, exposing 27 curated tools.

Being precise about support matters more than being flattering. That connector is built and tested against Claude.ai and Claude Cowork, and works in ChatGPT too. OpenClaw's MCP client speaks the same transport and runs its own OAuth handshake, which is the shape a remote connector needs, but a runtime nobody has tested against is a runtime nobody has tested against. To drive the same operations from OpenClaw today, the honest answer is the BeReach API for your own agent: 114 REST operations behind a bearer token, which no client's MCP implementation can get wrong. The Claude path and its setup live on the BeReach connector for Claude page.

Whichever runtime you settle on, the split those 27 tools are built around is worth borrowing, because it shows exactly which of them touches something you cannot undo.

Ten of the 27 are annotated read-only. Five carry the destructive annotation, and every one of those five touches an invitation, a message, or the send schedule. That is the split worth checking before you authorize a tool: which of a vendor's actions are read-only, and which one is the destructive send you want a human to approve first.

Pacing sits on the server rather than in a prompt, so it applies identically to a tool call and a click in the app. You never set a pace: BeReach spaces every invitation and message for each connected account and slows a new account down on its own, as the pacing rules explain. An agent that can send is an agent that can send too fast, and the only reliable place to fix that is below the model.

To see the finding half before wiring anything into a runtime, describe the buyer and get the searches runs the same public search the connector's find tools call, and you can export the commenters on a post to CSV from the same lane.

For why the model should stop at the draft rather than the send, Claude for sales walks through where a model's judgment ends. For the same loop running on a schedule instead of inside a chat, see the guide to an AI agent for LinkedIn outreach. Plans start at 89 EUR per month billed quarterly, 99 regular, with a 14-day free trial, and the full list is on the pricing page.

The bottom line

OpenClaw is a capable self-hosted agent runtime with real MCP support, and LinkedIn is the one channel it cannot speak natively, because LinkedIn lets nobody speak it. Posting to your own feed is sanctioned and easy. Everything outbound has no official API, so it runs on a logged-in session, and the three ways to get one are a browser profile the runtime drives, a community skill you are trusting on faith, or an MCP server that keeps the credential out of your prompt. Only the third survives a real week of outreach, and choosing between servers comes down to one question: which of their tools need your account, and who approves the ones that do. For the outreach tools themselves, see every LinkedIn outreach tool we compare.

Frequently asked questions