Your agent needs to read and write LinkedIn. You searched for a LinkedIn MCP server, found a dozen GitHub projects and a few hosted wrappers, and noticed something odd: none of them come from LinkedIn. That is not an oversight you can wait out. LinkedIn's platform has been partner-gated since 2015, and the MCP layer you plug into your agent is built by someone else on top of either the official REST API or a logged-in browser session. Those two foundations have completely different risk, auth, and capability profiles, and picking the wrong one is the kind of mistake that surfaces as a suspended member account three months into production.
This section establishes the two objects being compared. One of them is not what most agent developers assume it is.
As of July 2026, LinkedIn publishes, endorses, and supports zero MCP servers. There is no hosted endpoint, no mcp.linkedin.com, and no MCP product in the developer catalog alongside Sign In with LinkedIn, Share on LinkedIn, Community Management API, and the Advertising API. The largest community projects say so directly in their own README files: independent, not affiliated with LinkedIn or Microsoft.
The first family wraps the official REST API. It runs the same OAuth 2.0 Authorization Code flow, requests the same scopes, and hits the same partner gates. If your app is not approved for the Community Management API, the MCP wrapper cannot post as an organization either, because the wrapper has no privileges your app does not have.
The second family drives a member's authenticated browser session, usually by reading the li_at cookie or launching a headless Chromium profile. This is the family that returns profile search, connection lists, and job data, because those endpoints exist only in the logged-in web app. It also puts a durable, unscoped, human credential inside your agent runtime.
The official platform is a catalog of separately gated REST products, not one API. Sign In with LinkedIn using OpenID Connect and Share on LinkedIn are enabled automatically on a new app. Community Management, Advertising, Lead Sync, Messaging, and Talent products each require a review that evaluates your legal entity, your use case, and your verified LinkedIn Page.
Marketing and Community Management endpoints live under https://api.linkedin.com/rest/ and require a LinkedIn-Version header in YYYYMM format on every call, plus X-Restli-Protocol-Version: 2.0.0 on the Posts API. Consumer endpoints such as the OpenID Connect userinfo call remain on /v2/. Start at the access and permissions guide.
The comparison below assumes the MCP column means a community or vendor-hosted server, because that is the only LinkedIn MCP that exists.
The capability gap is not between MCP and REST. It is between what LinkedIn's API is allowed to return and what a logged-in browser session can see.
The capabilities most agent builders want are the ones LinkedIn deliberately does not sell: people search, arbitrary profile reads, and open messaging. No MCP server changes that. The servers that appear to solve it are reading the web app as your user, which is a policy problem, not a capability win.
The capabilities LinkedIn does expose are richer than most MCP wrappers implement. Campaign management, ad analytics pivots, organization ACLs, and follower typeahead are all in the REST surface and absent from most community servers. On the official path, the ceiling is your partner approval. On the session path, the ceiling is how long the account survives.
LinkedIn has one auth system, so MCP does not give you a second one. What changes between paths is the credential your agent ends up holding.
Every agent-relevant surface runs on 3-legged OAuth 2.0 with member consent. Application Authorization exists, but it is not enabled by default, Marketing APIs explicitly do not accept it, and its tokens expire in 30 minutes with no refresh token. Treating client credentials as a background-agent shortcut on LinkedIn does not work.
Access tokens are valid for 60 days. Programmatic refresh tokens are valid for 365 days from the initial grant, and the TTL does not reset when you mint a new access token. On day 360 both credentials expire in five days and the member must reauthorize through the browser. Refresh tokens are also limited to approved Marketing Developer Platform partners, so outside MDP your agent's real token lifetime is 60 days and then a login screen. Understanding how to handle token refresh for AI agents becomes critical at this ceiling.
A li_at cookie carries the member's full application privileges, has no OAuth scopes, cannot be narrowed per agent, and cannot be revoked for one integration without invalidating the member's other sessions. It is a non-human identity wearing a human's badge. When an employee leaves, disabling their IdP account does nothing to a cookie sitting in an MCP config file on a laptop.
Both paths require per-user credential isolation in a multi-tenant B2B agent. OAuth gives you a token per member. A session server gives you a cookie per member. Neither path gives you storage, rotation, or revocation. Those are infrastructure problems regardless of which path you choose. The challenge of credential ownership across agent tool-calling patterns is the same whether you pick MCP or the raw API.
The operational surface on LinkedIn is heavier than most connectors, and the MCP layer absorbs almost none of it.
LinkedIn's versioned Marketing APIs release on a monthly cadence and are supported for a minimum of one year. You pin a LinkedIn-Version value and migrate on a schedule. A community MCP server pins its own version, which means your agent's contract with LinkedIn is now controlled by a maintainer you do not employ.
LinkedIn enforces both an application-level and a member-level daily quota, and standard rate limits are not published. Limits reset at midnight UTC, over-quota calls return 429, and you look up the actual number for an endpoint in the Developer Portal Analytics tab after making at least one call to it. Developer admins get email alerts at 75% of the application quota, and those alerts do not fire on member-level breaches.
LinkedIn identifies everything by URN, and half the endpoints want them URL-encoded while the other half want them raw. A reaction takes urn:li:ugcPost:7123456789 unencoded; listing comments on the same post takes urn%3Ali%3AugcPost%3A7123456789. Getting this wrong produces 400s that read like schema errors. This is exactly the class of detail that separates a tested tool schema from API documentation repurposed for agents.
Community Management and Advertising access require a registered legal entity, a verified business email, a verified Page super admin, and a supported commercial use case. Both products start every app on a Development tier before Standard. Plan your agent roadmap around the review, because no amount of engineering shortens it.
Both lists below assume you are building for other people's LinkedIn accounts, not your own.
Scalekit's LinkedIn connector is the API-backed path with the operational work already done. It runs OAuth 2.0 per member, vaults the tokens, refreshes them, and exposes 49 tools as of the June 2026 connector docs, including linkedin_post_create, linkedin_organization_post_create, linkedin_posts_list, linkedin_social_metadata_get, linkedin_member_search, and the full ad account, campaign, and creative surface. The connector page has the tool catalog and starter prompts.
The connection name you pass in code must match the connection configured in your Scalekit dashboard under AgentKit, Connections. This is the single most common integration error.
Before the agent sees anything, retrieve the tools the current user's connected account is authorized to call. This is not a catalog lookup. A marketer whose LinkedIn account has no ad account access will not receive the ad tools, so the agent cannot select one and hallucinate its parameters.
actions.langchain.get_tools() returns native StructuredTool objects, so there is no schema reshaping. Filtering by tool_names is what keeps the context small: the LinkedIn connector's 49 tools at roughly 200 tokens each cost close to 10,000 tokens before the agent does any work, and four tools cost a fraction of that. For a deeper look at how LangChain tool calling works and where it stops, see our full guide.
If you are executing a single known action rather than running a reasoning loop, call executeTool directly. Scalekit resolves the member's LinkedIn token server-side; the credential never enters your agent runtime or the LLM context.
If you want LinkedIn over MCP without adopting a session-cookie server, a Virtual MCP server gives you a scoped endpoint backed by the official API.
A standard MCP server exposes every tool it has. A Virtual MCP server declares exactly which connections and tools an agent role can see, and whose connected account it acts with. You create it once per agent role and mint a short-lived session token before each run.
LinkedIn credentials expire on a 60-day clock and can be revoked by the member at any time, so check the connected account before every run rather than discovering the failure mid-task.
The endpoint is static and the identity is not. One server definition serves every tenant, and each run receives a token scoped to that member's connected accounts, so a token minted for a member at one customer cannot reach another customer's LinkedIn Page. There is no MCP server to deploy, host, or maintain, and no per-user server configuration. Setup details are in Set up and connect a Virtual MCP server. For context on how tool calling auth changes when you move from single-tenant to multi-tenant, see our dedicated guide.
Every tool call is logged against the connected account that authorized it: who triggered it, which tool ran, and what came back, with 90 days of queryable history. This is the difference between an audit trail that answers "which member's credential published this organization post" and one that says a service account did it. Agent tool observability is the difference between an audit trail and a black box. Auth logs are exportable to your SIEM.
Both paths hand you a credential per member and stop there.
For an agent serving 40 marketers across 8 customer organizations, the official path means 40 OAuth grants to store encrypted, refresh before the 60-day access token expires, and re-consent before the 365-day refresh ceiling. The session path means 40 cookies with no expiry contract at all, which is worse, not better. Neither path ships a vault, rotation logic, or a revocation flow. Secure token management for AI agents at scale requires purpose-built infrastructure beyond what any MCP wrapper provides.
A marketer leaves. Their IdP account is disabled. Your scheduled LinkedIn agent still holds a valid credential for their member identity and keeps publishing to the customer's company page. The agent does not decide to keep using it. It just does. Revocation has to be an event in your infrastructure, not a manual cleanup task. This is exactly the scenario described in when an employee leaves, who revokes their AI agent's access.
Scalekit's LinkedIn connector handles the OAuth flow, per-user token storage, automatic refresh, and revocation for both the direct tool-calling path and the Virtual MCP path, so the MCP versus API decision does not change your auth infrastructure. What the member cannot do, the agent cannot do.
If your agent is interactive and its job is content, engagement, and page analytics, use an MCP layer that is backed by LinkedIn's official API with OAuth, and scope it to the handful of tools the agent actually needs. If your agent runs on a schedule, touches ads or Lead Sync, needs webhook delivery, or lives in a pipeline where an unplanned schema change is an incident, call the REST API directly and pin your own version.
The one path to reject outright is the session-cookie MCP server. It is the only option that trades a scoped, revocable, auditable credential for an unscoped one, and it does so in exchange for data LinkedIn has decided not to sell you. The credential management problem is identical on the paths that remain, and that is the part that needs production-grade infrastructure.
Building a LinkedIn agent and want a second opinion on the auth model? Join the Scalekit Slack community or talk to an engineer.
Browse the Scalekit LinkedIn connector: scalekit.com/connectors/linkedin
