How do I use linkedin-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@linkedin-mcp Post this to my LinkedIn profile: Excited to share our new product launch! #innovation" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

linkedin-mcp

by sindhujaIBM

Overview Schema Related Servers Score Discussions

TypeScript

Remote

linkedin-mcp

An MCP (Model Context Protocol) server that lets an AI agent post, comment, and read analytics on LinkedIn — for your personal profile, and optionally a company page you administer.

Point Claude (or any MCP-compatible agent) at this server and it can:

post_to_profile — publish a post to your personal LinkedIn profile
post_to_company_page — publish a post to a company page you administer
comment_on_post — comment on a post as your profile or a company page
get_recent_posts — list recent posts with their URNs, so the agent can find something to comment on or check analytics for
get_post_analytics — impressions, reactions, comments, shares, and clicks for a post

Nothing here talks to LinkedIn except LinkedIn's own official REST API. Your access token stays local, in a .env file you control.

1. Create a LinkedIn Developer App

Go to linkedin.com/developers/apps and create a new app.
Under Products, add:
- Sign In with LinkedIn using OpenID Connect — lets you look up your own person URN
- Share on LinkedIn — gives you w_member_social, the scope that lets you post and comment as yourself
If you also want company page posting and analytics, add the product that grants w_organization_social / r_organization_social on your app (LinkedIn calls this the Community Management API in newer developer accounts, Marketing Developer Platform in older ones). This product is gated — you apply for access from the app's Products tab, and LinkedIn reviews the request. Skip this if you only want personal posting; post_to_profile, comment_on_post, and get_recent_posts/get_post_analytics for your profile all work without it.

Related MCP server: SocialAPIs MCP Server

2. Run the OAuth 2.0 flow to get an access token

LinkedIn uses the standard OAuth 2.0 authorization code flow.

Authorize (open in a browser, replace CLIENT_ID and REDIRECT_URI with your app's values):

https://www.linkedin.com/oauth/v2/authorization
  ?response_type=code
  &client_id=CLIENT_ID
  &redirect_uri=REDIRECT_URI
  &scope=openid%20profile%20w_member_social

Add %20r_organization_social%20w_organization_social to the scope if you added company page access in step 1.

LinkedIn redirects you to REDIRECT_URI?code=AUTH_CODE. Grab AUTH_CODE from that URL.

Exchange the code for an access token:

curl -X POST https://www.linkedin.com/oauth/v2/accessToken \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=AUTH_CODE" \
  -d "redirect_uri=REDIRECT_URI" \
  -d "client_id=CLIENT_ID" \
  -d "client_secret=CLIENT_SECRET"

The response includes access_token. It's valid for 60 days — after that, repeat this flow to refresh it.

3. Get your person URN

curl https://api.linkedin.com/v2/userinfo \
  -H "Authorization: Bearer ACCESS_TOKEN"

The sub field in the response is your person ID. Your person URN is urn:li:person:SUB_VALUE.

4. (Optional) Get your organization URN

Only needed for company page features:

curl "https://api.linkedin.com/v2/organizationalEntityAcls?q=roleAssignee" \
  -H "Authorization: Bearer ACCESS_TOKEN"

Find your organization's ID in the response; the URN is urn:li:organization:ORG_ID.

5. Install

Option A — npm package:

npm install -g @sindhujaks/linkedin-mcp

Option B — clone and build:

git clone https://github.com/sindhujaIBM/linkedin-mcp.git
cd linkedin-mcp
npm install
npm run build

6. Configure your credentials

If you installed via npm, create a .env file in the directory you'll run the server from (see .env.example in this repo for the template). If you cloned the repo:

cp .env.example .env

Fill in LINKEDIN_ACCESS_TOKEN and LINKEDIN_PERSON_URN from steps 2–3. Add LINKEDIN_ORGANIZATION_URN if you did step 4.

7. Add it to Claude

Claude Code (npm install):

claude mcp add linkedin -- linkedin-mcp

Claude Code (cloned repo):

claude mcp add linkedin -- node /absolute/path/to/linkedin-mcp/dist/index.js

Claude Desktop — add this to your claude_desktop_config.json:

{
  "mcpServers": {
    "linkedin": {
      "command": "linkedin-mcp"
    }
  }
}

(Or "command": "node", "args": ["/absolute/path/to/linkedin-mcp/dist/index.js"] if you cloned the repo instead of installing via npm.)

Restart Claude, and the five tools above will be available. You can then just ask, in plain language: "post this to my LinkedIn profile," or "comment 'thanks for reading' on my most recent post," or "how did my last post do?"

Notes

Access tokens expire after 60 days. When yours does, tool calls will fail with an auth error — re-run the OAuth flow in step 2 and update .env.
post_to_company_page, and using as: "company" on the other tools, all require LINKEDIN_ORGANIZATION_URN to be set — otherwise they return a clear error telling you what's missing.
This uses LinkedIn's /v2/ugcPosts and related endpoints. LinkedIn occasionally changes API versioning requirements for newer developer apps; if a call fails with a version-related error, check LinkedIn's API versioning docs for the current required header.

License

MIT

Available Tools

5 tools

comment_on_postA

Comment on a LinkedIn post, as your profile or a company page. Useful right after publishing — LinkedIn's feed algorithm weighs early engagement heavily.

ParametersJSON Schema

Name	Required	Description
`as`	Yes	Comment as your personal profile or a company page
`post_urn`	Yes	The URN of the post to comment on (returned by post_to_profile or post_to_company_page)
`comment_text`	Yes	The comment text

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description carries the full burden. It does not disclose that this is a public write action, whether authentication is required, whether comments can be edited or deleted, or what the outcome/return value looks like. The algorithm timing note is the only additional behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly written sentences: the action comes first, and the timing rationale follows. There is no redundant detail or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter tool, the purpose, actor, and timing are clearly covered and the schema fully documents parameters. However, with no annotations and no output schema, the description does not address what to expect after invocation or what prerequisites/limitations exist.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and all three parameters are already documented in the input schema. The description only restates the 'as' choice ('profile or company page') and adds no new meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a concrete verb and object: 'Comment on a LinkedIn post,' and further scopes it by actor ('as your profile or a company page'). This clearly distinguishes it from sibling tools like post_to_profile and get_recent_posts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence provides explicit timing guidance: 'Useful right after publishing — LinkedIn's feed algorithm weighs early engagement heavily.' It gives clear context for when the tool is valuable, though it does not explicitly name alternatives or when-not-to-use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_post_analyticsA

Get performance stats (impressions, reactions, comments, shares, clicks) for a specific LinkedIn post.

ParametersJSON Schema

Name	Required	Description	Default
`as`	Yes	The account that owns the post
`post_urn`	Yes	The URN of the post

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the full burden. 'Get' implies a read-only operation and the metric list clarifies the expected result, but the description does not disclose possible limitations like data delay, permission requirements, or behavior when metrics are unavailable. It is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence that front-loads the action, resource, and metric list without any filler or redundant wording. Every element earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with only two parameters and no output schema, the description covers the tool's purpose and the data returned. It doesn't discuss time ranges or permissions, but those are not essential for a straightforward analytics retrieval, and the schema covers the parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents both 'as' and 'post_urn' clearly. The description adds no additional meaning about parameter formats, constraints, or relationships; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and a well-defined resource ('performance stats for a specific LinkedIn post'), and enumerates the exact metrics returned (impressions, reactions, comments, shares, clicks). This makes it immediately distinguishable from siblings like post_to_profile or get_recent_posts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies this tool is for retrieving analytics of one specific post, but it doesn't explicitly state when to prefer it over get_recent_posts or mention any exclusions or alternatives. The use case is inferable from context, but no direct guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_recent_postsA

List the most recent posts for your profile or company page, with their URNs and basic stats. Useful for finding post URNs to comment on.

ParametersJSON Schema

Name	Required	Description	Default
`as`	Yes	Which account to fetch posts for
`count`	No	How many recent posts to return (default 5, max 10)

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description itself must carry behavioral disclosure. It signals a read-only list operation and a 'most recent' ordering, and it discloses that each post comes with a URN and basic stats. It does not mention pagination, authentication requirements, or exactly which stats are included, so it is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the primary behavior and followed by a practical use case. Every word earns its place; there is no redundant restatement of the tool name or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read tool with no output schema, the description adequately covers what is returned (URNs and basic stats) and why an agent would call it. It could be more specific about the shape of the stats, but nothing essential to selecting and invoking the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents 'as' as the profile/company enum and 'count' with default and max. The description adds no parameter-level meaning beyond that, which matches the baseline for fully covered schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('List'), a specific resource ('most recent posts for your profile or company page'), and the key output ('URNs and basic stats'). This clearly separates it from the sibling create/comment/analytics tools without needing to read their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a concrete use case: 'Useful for finding post URNs to comment on.' It does not explicitly exclude alternatives or mention get_post_analytics, but the context is clear enough for an agent to choose this over post/comment tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

post_to_company_pageA

Post to a LinkedIn company page you administer. Requires LINKEDIN_ORGANIZATION_URN to be set. Returns the post URN and URL.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	The post text content
`article_url`	No	Optional URL to attach as an article link

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses a key prerequisite (LINKEDIN_ORGANIZATION_URN) and the return payload (post URN and URL), and implies permission via 'you administer.' However, it does not mention immediate visibility, publication side effects, or failure behavior, which are relevant for a write operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tight sentences with no filler. The main action is front-loaded, followed by a clear prerequisite and return value. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter tool with no output schema and no annotations, the description provides the core essentials: action, target, admin scope, environmental prerequisite, and return values. It could be more complete by noting that posts are published immediately or by describing error handling, but these are minor gaps given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description itself does not add new meaning to the parameters beyond what the schema already provides for text and article_url. It mentions the overall output but not parameter-specific details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Post to a LinkedIn company page you administer.' It clearly distinguishes from siblings like post_to_profile by specifying company page, and adds the admin constraint and expected return values (post URN and URL).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The context is clear—this is for posting to a company page, not a profile—and the prerequisite LINKEDIN_ORGANIZATION_URN must be set. However, it does not explicitly mention alternatives like post_to_profile, nor does it say when not to use this tool, leaving some inference to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

post_to_profileA

Post to your personal LinkedIn profile. Returns the post URN and URL.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	The post text content
`article_url`	No	Optional URL to attach as an article link

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool posts and returns the post URN and URL, which is helpful, but it does not mention permissions, visibility settings, side effects, or failure modes. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no wasted words. It front-loads the core action and includes the return value, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter posting tool, the description covers the essential behavior and return value. It lacks explicit guidance about when to use sibling tools or any caveats about posting, but the schema plus the concise description are sufficient for correct invocation in most cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents both parameters (text and article_url). The description adds no parameter-specific detail, but the baseline of 3 applies because the schema handles parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Post') and resource ('your personal LinkedIn profile'). The word 'personal' distinguishes it from the sibling tool post_to_company_page, so an agent can select it correctly without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: use this when posting to a personal LinkedIn profile, as opposed to a company page. It does not explicitly list alternatives or state when-not-to-use, but the 'personal' qualifier effectively communicates the intended scope.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a clearly different action and resource: posting to a profile, posting to a company page, commenting, listing recent posts, and fetching analytics. There is no meaningful overlap or ambiguity between the tools.

Naming Consistency5/5

All tool names follow the same snake_case verb-first convention, with clear patterns like post_to_* and get_*. The naming is predictable and makes the purpose of each tool immediately obvious.

Tool Count5/5

Five tools is well-scoped for a LinkedIn content publishing and engagement server. Each tool covers a distinct core operation without unnecessary bloat or missing essentials.

Completeness4/5

The set covers the main lifecycle for LinkedIn posting: create posts, comment, retrieve recent posts, and view analytics. Delete and update operations are absent, but they are not core to the apparent purpose of publishing and measuring engagement.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Instagram B
io.github.mcp-dir
Instagram for AI agents: publish, read comments and DMs, insights, and engage from your account.
Social Media
331
Sociality.io MCP
io.sociality
Social media analytics, post insights, and competitor benchmarking for AI agents.
Social Media Marketing
26
Antwork
io.antwork
Draft, schedule, and publish social posts for your workspace straight from your AI.
Social Media Marketing
2
Postey
ai.postey
Draft, schedule and publish social posts to nine platforms from any AI agent.
Social Media Marketing
1

Related MCP Servers

Facebook MCP Server
Social Media Communication
ahmedselimmansor-ctrl
F
license
Not graded
quality
D
maintenance
Enables AI agents to manage Facebook profiles, pages, posts, and engagement via the Graph API with OAuth authentication.
Updated 4 months ago (2026-05-16 02:10 UTC)
2
SocialAPIs MCP Serverofficial
Social Media Research & Data
SocialAPIsHub
A
license
B
quality
A
maintenance
Unified social media API for AI agents, enabling access to Facebook pages, groups, and posts with tools for page details, posts, reels, comments, and more.
Updated 2 months ago (2026-06-29 14:58 UTC)
47
79
1
MIT
Facebook MCP Server
Social Media Communication
hoangvantuan
A
license
Not graded
quality
C
maintenance
Enables AI agents to automate Facebook Page management including posting, commenting, and analytics via the Facebook Graph API.
Updated 2 months ago (2026-07-04 00:29 UTC)
MIT
mcp-server-linkedin
Social Media Marketing
Huzaifa-ali
A
license
A
quality
B
maintenance
Enables AI agents to publish posts, images, videos, and articles to LinkedIn.
Updated a month ago (2026-07-27 14:08 UTC)
10
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sindhujaIBM/linkedin-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

linkedin-mcp

1. Create a LinkedIn Developer App

2. Run the OAuth 2.0 flow to get an access token

3. Get your person URN

4. (Optional) Get your organization URN

5. Install

6. Configure your credentials

7. Add it to Claude

Notes

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

SocialAPIs MCP Serverofficial

Latest Blog Posts

MCP directory API