How do I use @mhdd_24/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., "@@mhdd_24/linkedin-mcp Post to LinkedIn: Just finished a great book on AI." 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.

@mhdd_24/linkedin-mcp

by Mhdd-24

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

@mhdd_24/linkedin-mcp

MCP server that posts to LinkedIn through the LinkedIn API. Use it from Cursor, Claude Desktop, VS Code Copilot, or any MCP-compatible client.

You type natural language — the assistant calls create_post for you. No manual member ID setup; your LinkedIn OAuth access token resolves identity automatically.

Full documentation: docs/WIKI.md

How it works (30 seconds)

You (chat) → MCP client → linkedin-mcp → LinkedIn userinfo (access token)
                                      → LinkedIn ugcPosts API
                                      → Text post on your profile

Access token calls userinfo → returns memberId, name, email
Author URN is built from memberId — not hardcoded
Visibilities come from config — validated before posting
create_post validates visibility, POSTs the share, returns the post URN

Related MCP server: linkedin-mcp

Prerequisites

Requirement	Notes
Node.js 18+	Uses native fetch
LinkedIn OAuth access token	Member token with required scopes (see below)
Default visibility (optional)	`DEFAULT_VISIBILITY` so you don't pass it every time

Required OAuth scopes

Scope	Purpose
`openid`	OpenID Connect identity
`profile`	Display name
`email`	Email address
`w_member_social`	Create posts on your profile

Obtain a token via the LinkedIn OAuth 2.0 Authorization Code flow.

Install

Option A — npm (recommended after publish)

npm install -g @mhdd_24/linkedin-mcp

This installs the linkedin-mcp CLI and compiles dist/ via the package prepack script.

Option B — npx (no global install)

npx @mhdd_24/linkedin-mcp

Downloads and runs the latest published version on each invocation.

Option C — clone and build (contributors)

git clone https://github.com/Mhdd-24/Linkedin-MCP.git
cd Linkedin-MCP
npm install
npm run build
node dist/index.js

Configure your MCP client

Cursor

Edit Cursor Settings → MCP or ~/.cursor/mcp.json:

{
  "mcpServers": {
    "linkedin": {
      "command": "npx",
      "args": ["-y", "@mhdd_24/linkedin-mcp"],
      "env": {
        "LINKEDIN_ACCESS_TOKEN": "<your-oauth-access-token>",
        "DEFAULT_VISIBILITY": "PUBLIC"
      }
    }
  }
}

After global install, you can use:

"command": "linkedin-mcp"

Local development:

"command": "node",
"args": ["/path/to/linkedin-mcp/dist/index.js"]

Restart Cursor (or toggle the MCP server off/on) after saving.

Claude Desktop

%APPDATA%\Claude\claude_desktop_config.json (Windows) or ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

{
  "mcpServers": {
    "linkedin": {
      "command": "npx",
      "args": ["-y", "@mhdd_24/linkedin-mcp"],
      "env": {
        "LINKEDIN_ACCESS_TOKEN": "<your-oauth-access-token>",
        "DEFAULT_VISIBILITY": "PUBLIC"
      }
    }
  }
}

Environment variables

Variable	Required	Default	Purpose
`LINKEDIN_ACCESS_TOKEN`	Yes*	—	OAuth access token for userinfo + posting
`DEFAULT_VISIBILITY`	No	`PUBLIC`	Default audience for `create_post`
`LINKEDIN_API_BASE_URL`	No	`https://api.linkedin.com`	LinkedIn API host

* Or pass accessToken on each tool call.

Aliases: LI_ACCESS_TOKEN, accessToken, defaultVisibility, etc. (see WIKI).

Never commit access tokens. Put them only in MCP env or a local .env (for npm run dev).

Tools

Tool	Purpose
`whoami`	Test token — shows memberId, name, email, author URN
`list_visibilities`	Lists valid post visibility values
`create_post`	Create a text post on your LinkedIn profile

Usage

Step 1 — Verify setup (optional)

In chat:

Run whoami on the linkedin MCP.

Expected: your LinkedIn identity and author URN.

Step 2 — See valid visibilities (optional)

list_visibilities

Examples: PUBLIC, CONNECTIONS

Step 3 — Create a post

Post to LinkedIn: Just shipped a new feature! Excited to share what we've been building.

Create a LinkedIn post with visibility PUBLIC: Happy to announce our open-source MCP server for LinkedIn integration.

`create_post` parameters

Parameter	Required	Example
`text`	Yes	"Just shipped a new feature!"
`visibility`	No*	"PUBLIC"
`accessToken`	No	Only if not in env

* Optional when DEFAULT_VISIBILITY is set in MCP config.

What happens after `npm install`?

Package files land in node_modules/@mhdd_24/linkedin-mcp/ (or global prefix if -g).
prepack / publish includes compiled dist/ — no local build needed for end users.
The linkedin-mcp bin points to dist/index.js.
Your MCP client runs that entry over stdio (stdin/stdout = MCP protocol; logs go to stderr).
On startup: validateEnv() warns if access token is missing.
Tools are registered; the server waits for CallTool requests from the AI.

After publishing to npm (maintainers)

Bump version in package.json and src/config/linkedin.config.ts (LI.SERVER.VERSION).
Build and test: npm run build then test with local mcp.json.
Publish: npm publish --access public (logged in as package owner).
Users update by restarting MCP — npx picks up the new version automatically.
Global install users: npm update -g @mhdd_24/linkedin-mcp.

Current package version: 1.0.0.

See WIKI — Publishing for the full checklist.

Troubleshooting

Problem	Fix
MCP server won't start	Check Node.js 18+ is installed
No access token provided	Set `LINKEDIN_ACCESS_TOKEN` or pass `accessToken` on the tool
Invalid visibility	Run `list_visibilities`; use an exact match (case-insensitive)
visibility is required	Set `DEFAULT_VISIBILITY` in env or pass visibility on `create_post`
userinfo failed: 401	Token expired or invalid — refresh your OAuth token
Post failed: 403	Token missing `w_member_social` scope

More detail: docs/WIKI.md § Troubleshooting.

License

ISC

Available Tools

3 tools

create_postA

Create a text share on LinkedIn. The author is resolved from userinfo (not from arguments). visibility is validated against the supported values. Returns the created post URN.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	The post body text. Up to 3000 characters.
`visibility`	No	Audience for the post, e.g. "PUBLIC" or "CONNECTIONS". Optional if DEFAULT_VISIBILITY env var is set.
`accessToken`	No	LinkedIn OAuth access token. Optional if LINKEDIN_ACCESS_TOKEN is set.

TDQS

A4.2/5.0

Behavior4/5

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

Discloses key behaviors: author resolution from userinfo, visibility validation, return of post URN. No annotations exist, so description carries the burden well. Could mention that it is a write/destructive action.

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 main purpose. No fluff, every clause adds information.

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?

Complete for a simple create tool: covers parameters, side effects, and return. No output schema, but description suffices.

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

Parameters4/5

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

Adds value beyond schema: explains author resolution and validation. Schema coverage is 100%, so baseline is 3; the extra context justifies 4.

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?

Clear verb 'Create' and specific resource 'text share on LinkedIn'. Distinguishes from siblings by stating author resolution and visibility validation. No ambiguity.

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?

Implicitly describes when to use (create a post) but lacks explicit alternatives or conditions. Sibling tools like 'list_visibilities' suggest complementary use, but no direct comparison.

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

list_visibilitiesA

List valid post visibility values (e.g. PUBLIC, CONNECTIONS). Use these exact values for visibility in create_post.

ParametersJSON Schema

Name	Required	Description	Default
`accessToken`	No	LinkedIn OAuth access token. Optional if LINKEDIN_ACCESS_TOKEN is set.

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It only states that it lists values, but does not mention that it is read-only, non-destructive, or any side effects. Authentication requirements (optional token) are implied but not stated in the description.

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 sentences: the first states the core action with examples, the second provides usage guidance. It is front-loaded, concise, and every sentence is valuable with no waste.

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?

Given no output schema and no annotations, the description does not specify the return format (e.g., array of strings) or error conditions. It is minimally adequate for a simple list tool but lacks some context that would help an agent fully understand the tool's behavior.

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 coverage is 100% with the accessToken parameter already described. The description does not add any meaning beyond the schema; it focuses on the purpose. Baseline of 3 is appropriate as no extra value is added.

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 the verb 'list' and the resource 'valid post visibility values' with examples (PUBLIC, CONNECTIONS). It distinguishes itself from siblings like create_post by showing how the output is used, and whoami is unrelated.

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 implies use when needing valid visibility values for create_post. It does not explicitly exclude other uses, but the context with siblings is clear. No explicit when-not-to-use is given, but it's sufficient for a simple reference tool.

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

whoamiA

Resolve the current LinkedIn member from the OpenID Connect userinfo endpoint using an access token. Returns the member id (used as the author URN), display name, and email.

ParametersJSON Schema

Name	Required	Description	Default
`accessToken`	No	LinkedIn OAuth access token. Optional if LINKEDIN_ACCESS_TOKEN is set.

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It explains the source (OpenID Connect userinfo endpoint) and returned fields (member id, display name, email). Does not explicitly state read-only nature but implies no side effects.

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, no fluff, front-loaded with purpose. Every word adds value.

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?

No output schema, but description lists return fields. For a simple self-info tool, this is adequately complete.

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

Parameters4/5

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

Schema coverage is 100%, and description adds value by clarifying the accessToken is optional if LINKEDIN_ACCESS_TOKEN is set, which is not in the schema description.

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?

Description clearly states the tool resolves the current LinkedIn member using OAuth, distinct from sibling tools (create_post, list_visibilities) which perform different actions.

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?

Description says 'using an access token' and notes optional parameter, but does not explicitly specify when to use this tool versus alternatives or when not to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv1.0.0Jul 8, 2026
- First observedcreate_post
- First observedlist_visibilities
- First observedwhoami

Install Server

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

TDQS

A4.1/5.0

Scored 2026-07-08 21:35 across 3 tools

Disambiguation5/5

Each tool serves a distinct purpose: whoami resolves user identity, list_visibilities provides valid visibility options, and create_post handles posting. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: create_post, list_visibilities, whoami (verb-only). The pattern is uniform and predictable.

Tool Count4/5

3 tools is minimal but appropriate for a focused LinkedIn posting server. It covers the core workflow: identify user, check options, create post. Could be expanded slightly, but not under-scoped.

Completeness4/5

The tool surface covers the essential steps for creating a text post: user info, visibility choices, and posting. Missing update/delete or media posting, but for a basic text share it is complete.

Maintenance

ActivityMaintained

ResponsivenessSyncing

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

GTM API: LinkedIn MCP ServerOAuth
com.gtm-api
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
Social Media Communication
1100
LinkedIn MCP Server A
ai.com.mcp
LinkedIn API as MCP tools to retrieve profile data and publish content. Powered by HAPI MCP.
Social Media Communication Marketing
337
PerfectPostOAuth
social.perfectpost.mcp
PerfectPost is a LinkedIn content management platform. This MCP server gives AI assistants read and write access to a user's PerfectPost account: published posts with their engagement analytics, drafts lifecycle (create / edit / schedule), and LinkedIn profile data.
Social Media Marketing Content Management Systems
2
LinkMCPOAuth
io.linkmcp
Hosted MCP server for LinkedIn: 31 tools for profiles, search, messaging, posts, enrichment.
Social Media Communication Search
2

Related MCP Servers

@isteam/linkedin-mcp
Social Media Marketing
isteamhq
A
license
A
quality
D
maintenance
MCP server for LinkedIn that enables AI agents to post, comment, like, and manage content on LinkedIn.
Updated 5 months ago (2026-04-17 08:58 UTC)
10
17
1
MIT
linkedin-mcp
Social Media Communication
KpihX
A
license
Not graded
quality
D
maintenance
MCP server for LinkedIn, enabling posting, liking, commenting, and profile retrieval via official OAuth 2.0. Features CLI, HTTP admin, and optional Telegram bot.
Updated 5 months ago (2026-03-29 16:44 UTC)
14
MIT
linkedin-pages-mcp
Social Media Marketing
MCPWorks-Technologies-Inc
A
license
Not graded
quality
D
maintenance
MCP server for managing LinkedIn Company Pages via the official Community Management API. Post content, manage comments, track analytics, and more through the Model Context Protocol.
Updated 5 months ago (2026-03-26 12:25 UTC)
1
MIT
LinkedIn MCP Server
Social Media Communication
ayushnagvanshi101098-ship-it
A
license
Not graded
quality
D
maintenance
MCP server for posting to LinkedIn, managing drafts, scheduling, commenting, and reacting, all from the terminal.
Updated 5 months ago (2026-03-31 05:38 UTC)
113
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/Mhdd-24/Linkedin-MCP'

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

@mhdd_24/linkedin-mcp

How it works (30 seconds)

Prerequisites

Required OAuth scopes

Install

Option A — npm (recommended after publish)

Option B — npx (no global install)

Option C — clone and build (contributors)

Configure your MCP client

Cursor

Claude Desktop

Environment variables

Tools

Usage

Step 1 — Verify setup (optional)

Step 2 — See valid visibilities (optional)

Step 3 — Create a post

create_post parameters

What happens after npm install?

After publishing to npm (maintainers)

Troubleshooting

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`create_post` parameters

What happens after `npm install`?