How do I use linkedin-mcp-server?

1. Click on "Deploy 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-server Post a quick update about my new role" 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-server

by ihiteshgupta

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

linkedin-mcp-server

LinkedIn MCP Server — post content, share articles, and manage your LinkedIn profile through Claude using the official LinkedIn API.

6 tools for creating posts, sharing articles, managing your profile, and more — powered by the official LinkedIn REST API with OAuth 2.0.

Tools

Tool	Description	Permissions Required
`linkedin_get_profile`	Get your LinkedIn profile information	Basic (OpenID)
`linkedin_create_post`	Create a text post (up to 3000 chars)	Share on LinkedIn
`linkedin_create_article_post`	Share an article link with commentary	Share on LinkedIn
`linkedin_get_posts`	Get your recent posts	Share on LinkedIn ⚠️
`linkedin_delete_post`	Delete a post by ID	Share on LinkedIn
`linkedin_get_connections_count`	Get your total connection count	⚠️ May need partner access

⚠️ API Limitations: linkedin_get_posts and linkedin_get_connections_count use LinkedIn endpoints that may require elevated or partner-level API access depending on your app's approval status. The core tools (get profile, create post, share article, delete post) work with standard access.

Related MCP server: linkedin-mcp-server

Setup

LinkedIn requires creating a Developer App to get OAuth credentials. This takes about 10 minutes.

Step 1 — Create a LinkedIn Developer App

Go to developer.linkedin.com/apps
Click "Create app"
Fill in the required fields:
- App name: e.g. My LinkedIn MCP
- LinkedIn Page: You need a LinkedIn company page linked — create a simple one at linkedin.com/company/setup/new if you don't have one
- App logo: Upload any image (required)
Agree to the terms and click "Create app"

Step 2 — Configure OAuth Redirect URL

In your new app, go to the "Auth" tab
Under "OAuth 2.0 settings", find "Authorized redirect URLs for your app"
Click "Add redirect URL" and enter exactly:
```
http://127.0.0.1:3000/callback
```
Click "Update"
Copy your Client ID and Client Secret from this page — you'll need them next

Step 3 — Request API Products

Go to the "Products" tab in your app
Request access to both of these products:
- Sign In with LinkedIn using OpenID Connect — click "Request access" → Select → Agree
- Share on LinkedIn — click "Request access" → Select → Agree
Both are typically approved instantly for personal use

Step 4 — Install & Configure

# Install globally
npm install -g @dev-hitesh-gupta/linkedin-mcp-server

# Create config directory and add your credentials
mkdir -p ~/.linkedin-mcp
cat > ~/.linkedin-mcp/credentials.json << 'EOF'
{
  "client_id": "YOUR_CLIENT_ID",
  "client_secret": "YOUR_CLIENT_SECRET"
}
EOF

# Authenticate — opens browser for LinkedIn sign-in
linkedin-mcp-server auth

Your access token is saved to ~/.linkedin-mcp/token.json and valid for 60 days.

Step 5 — Add to Claude Code

claude mcp add linkedin -- npx @dev-hitesh-gupta/linkedin-mcp-server

Or manually in your Claude config (~/.claude/claude_desktop_config.json):

{
  "mcpServers": {
    "linkedin": {
      "command": "npx",
      "args": ["@dev-hitesh-gupta/linkedin-mcp-server"]
    }
  }
}

Usage Examples

Create a post:

Post to LinkedIn: "Just shipped a new open-source MCP server for LinkedIn automation! Check it out. #opensource #ai"

Share an article:

Share this article on LinkedIn: https://example.com/article
My commentary: "Great read on the future of AI tooling"

Control visibility:

Value	Who sees it
`PUBLIC`	Everyone on LinkedIn (default)
`CONNECTIONS`	Your 1st-degree connections only
`LOGGED_IN`	Any logged-in LinkedIn member

Re-authentication

LinkedIn tokens expire after 60 days. Re-authenticate when needed:

rm ~/.linkedin-mcp/token.json
linkedin-mcp-server auth

Data & Auth Storage

All data is stored locally:

~/.linkedin-mcp/
├── credentials.json    # Your LinkedIn app Client ID + Secret
└── token.json          # OAuth access token (expires in 60 days)

Security: Never commit these files to version control.

Troubleshooting

"Not authenticated" error:

linkedin-mcp-server auth

"Unable to determine member URN": Ensure the Sign In with LinkedIn using OpenID Connect product is approved in your app's Products tab.

Post creation fails: Ensure the Share on LinkedIn product is approved. Check the Products tab in your LinkedIn Developer app.

"Access blocked" during sign-in: Your LinkedIn app may still be under review. Check the Products tab for approval status.

Token expired:

rm ~/.linkedin-mcp/token.json && linkedin-mcp-server auth

linkedin_get_posts or linkedin_get_connections_count returns errors: These tools use LinkedIn API endpoints that require elevated permissions not available with standard developer access. This is a LinkedIn API restriction.

Requirements

Node.js 18+
A LinkedIn account
LinkedIn Developer App with OAuth credentials (see setup above)

License

MIT — Hitesh Gupta

Available Tools

6 tools

linkedin_create_article_postA

Create a LinkedIn post with an article/link. Great for sharing blog posts, news articles, or any web content with your network.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	Commentary to accompany the article
`title`	No	Optional title for the article preview
`articleUrl`	Yes	URL of the article to share
`visibility`	No	Post visibility: PUBLIC (default), CONNECTIONS, or LOGGED_IN
`description`	No	Optional description for the article preview

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as default visibility (PUBLIC), authentication requirements, error handling for invalid URLs, or whether the operation is irreversible. This is a significant gap for a creation tool.

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, front-loaded with the action, and contains no redundant information. Every sentence provides essential context.

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 creation tool with no output schema and no annotations, the description is minimal. It covers the basic purpose but omits details about return values, error behavior, or any prerequisites, leaving significant gaps for an agent to safely invoke the tool.

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 does not add any additional meaning beyond the basic parameter descriptions; it merely restates the purpose without enriching parameter understanding.

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 tool creates a LinkedIn post with an article/link, using specific verb and resource. It distinguishes from the sibling tool 'linkedin_create_post' by focusing on article/link sharing.

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 indicates appropriate use for sharing blog posts, news articles, or web content, implying it's not for text-only posts. However, it lacks explicit when-not-to-use or alternative naming beyond general context.

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

linkedin_create_postA

Create a text post on LinkedIn. Supports different visibility options: PUBLIC (everyone), CONNECTIONS (1st degree connections only), or LOGGED_IN (LinkedIn members only).

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	The content of the post (max 3000 characters)
`visibility`	No	Post visibility: PUBLIC (default), CONNECTIONS, or LOGGED_IN

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are present, so the description must carry the full burden. It discloses visibility options but does not mention authentication needs, rate limits, or what happens if the character limit is exceeded. For a creation tool, it lacks important 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 sentences, front-loaded with the purpose. No unnecessary words. Efficient and clear.

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 the tool's simplicity (2 parameters, no output schema), the description is adequate but incomplete. It explains purpose and visibility, but lacks guidance on when to use vs. creating article posts and does not describe any return value or side effects.

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 baseline is 3. The description adds detail for the visibility parameter by explaining enum meanings (e.g., '1st degree connections only' for CONNECTIONS), but adds nothing for the text parameter beyond the schema. Overall, marginal added value.

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 'Create a text post on LinkedIn' with a specific verb and resource. It distinguishes from sibling tools like 'linkedin_create_article_post' which handles article 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 implies usage for text posts but does not explicitly state when to use this tool versus alternatives (e.g., linkedin_create_article_post). No when-not-to-use guidance is provided.

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

linkedin_delete_postA

Delete a LinkedIn post by its ID.

ParametersJSON Schema

Name	Required	Description	Default
`postId`	Yes	The ID of the post to delete

TDQS

A3.5/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 full responsibility for disclosing behavioral traits. It only states the action 'delete' without explaining whether the deletion is permanent, whether it requires specific permissions, whether the post must belong to the authenticated user, or what errors may occur.

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, clear sentence with no unnecessary words. It conveys the essential purpose efficiently.

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?

The tool is simple with one parameter, but the description lacks important context for a destructive operation, such as whether deletion is reversible, required permissions, or behavior when the post does not exist. While the core action is clear, the absence of any safety or precondition information leaves it incomplete.

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?

The input schema already fully describes the single parameter (postId) with a clear description. The tool description adds no extra semantic meaning beyond restating 'by its ID,' so the baseline score of 3 is appropriate given 100% schema coverage.

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 identifies the action ('Delete') and the resource ('a LinkedIn post by its ID'). This is distinct from sibling tools like linkedin_get_posts and linkedin_create_post, 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?

The description states the action but gives no explicit guidance on when to use it versus alternatives. It is implied that this tool is for deleting posts, but no context about prerequisites, ownership, or when not to use it is provided.

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

linkedin_get_connections_countA

Get the number of LinkedIn connections. Note: This may require additional API permissions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/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 transparency burden. It adds a useful note about additional API permissions but does not disclose return format, safety guarantees, or other behavioral details.

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 short, focused sentences: the first states the purpose, the second adds a necessary permission caveat. No superfluous content.

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

Completeness5/5

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

For a parameterless tool with no output schema, the description adequately conveys what the tool does and a key prerequisite. Nothing essential is missing given the tool's simplicity.

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?

The tool has zero parameters, so the schema is fully covered. Baseline of 4 is appropriate because there are no parameter details to add.

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 tool's function with a specific verb ('Get') and resource ('number of LinkedIn connections'), distinguishing it from sibling tools that handle profiles and 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 purpose is self-evident, implying usage when the connection count is needed. The permission note provides a prerequisite but the description does not discuss alternatives or when not to use this tool.

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

linkedin_get_postsA

Get the authenticated user's recent LinkedIn posts. Note: This may require additional API permissions.

ParametersJSON Schema

Name	Required	Description	Default
`count`	No	Number of posts to retrieve (default: 10, max: 50)

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full transparency burden. It discloses a potential authorization requirement ('may require additional API permissions') and scope (authenticated user), but does not mention read-only nature, return structure, or error behavior. Adds some value beyond schema.

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?

A single sentence contains the core purpose and a permission caveat. No fluff, no repetition, and it is front-loaded with the main verb and resource.

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 read-only tool with one optional parameter and no output schema, the description is adequate. It states what it gets and notes a key prerequisite (permissions). Missing details like return format are not critical given the 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 coverage is 100%: the 'count' parameter is fully described in the input schema with default and max. The description adds no additional parameter semantics beyond what the schema already states, so baseline 3 applies.

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 uses specific verb 'Get' and resource 'authenticated user's recent LinkedIn posts', clearly distinguishing from sibling create/delete tools. It is unambiguous and defines exactly what the tool returns.

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 implies usage for reading the user's own posts, but provides no explicit when-to-use guidance or exclusions compared to sibling tools like create/delete. There is no mention of alternatives or when not to use this tool.

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

linkedin_get_profileA

Get the authenticated user's LinkedIn profile information including name, email, and profile picture.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the burden of transparency. It discloses that the profile is the authenticated user's, implying OAuth context, but does not mention read-only status, potential errors, or side effects. This is moderate transparency for a simple getter.

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, clear sentence with no filler words. It front-loads the verb and resource, and every word adds meaning. Highly concise and well-structured.

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 no parameters and no output schema, the description provides the essential context: what data is returned. It could be improved by mentioning the response format or any authentication prerequisites, but it is complete enough for a simple profile getter.

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?

The tool has zero parameters, so there are no parameter semantics to explain. The description adds value by listing what the returned profile includes, which serves as the output semantics. Baseline 4 is appropriate for zero-parameter tools.

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 action (get), the resource (authenticated user's LinkedIn profile), and specific included fields (name, email, profile picture). It distinguishes itself from sibling tools that focus on posts and connections count.

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 implies usage when the authenticated user's profile data is needed, but it does not explicitly mention when to use this tool over alternatives or any exclusions. Since siblings are clearly different, the implied usage is acceptable but not explicit.

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.

6 tool updatesv1.0.0Jul 13, 2026
- First observedlinkedin_create_article_post
- First observedlinkedin_create_post
- First observedlinkedin_delete_post
- First observedlinkedin_get_connections_count
- First observedlinkedin_get_posts
- First observedlinkedin_get_profile

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-07-13 14:55 across 6 tools

Disambiguation5/5

Each tool targets a distinct operation: creating article vs text posts, deleting posts, retrieving posts, profile, and connections count. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent 'linkedin_verb_noun' pattern (e.g., linkedin_create_post, linkedin_get_profile), making the naming predictable and clear.

Tool Count5/5

With 6 tools covering posting, reading, and profile operations, the count is well-scoped for a focused LinkedIn server, not too many or too few.

Completeness3/5

Covers core post creation, deletion, and retrieval, but lacks update post and more detailed connection data, leaving notable gaps for a complete LinkedIn interaction surface.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Iridium COAuth
com.nikhilkulkarni1755
LinkedIn outreach, commenting, scheduling, and data via Claude and human approval gates.
Social Media Marketing
2
IridiumOAuth
com.iridiumhqmcp
LinkedIn outreach, commenting, scheduling, and data via Claude and human approval gates.
Social Media Marketing App Automation
1
Reach MCP — LinkedIn for AI agents A
com.reachmcp
LinkedIn for AI agents: inbox, invitations, Sales Navigator search, posts. Quotas and webhooks.
Social Media CRM
521
mcpOAuth
com.curviate
LinkedIn actions for AI agents: search, messaging, posts and invites, as hosted MCP tools.
Social Media Communication
1

Related MCP Servers

LinkedIn MCP Server
Social Media Content Management Systems
FilippTrigub
A
license
Not graded
quality
F
maintenance
Enables posting text and media content directly to LinkedIn from Claude Desktop with support for authentication and visibility controls.
Updated a year ago (2025-05-26 07:48 UTC)
10
MIT
linkedin-mcp-server
Social Media Marketing
abhineet34
A
license
A
quality
D
maintenance
Post to LinkedIn from Claude — create posts, upload images, edit/delete posts, and manage company pages via natural language. Uses the official LinkedIn REST API with OAuth 2.0.
Updated 4 months ago (2026-05-19 07:19 UTC)
9
84 npm
2
MIT
linkedin-mcp-server
Social Media Communication
greg0r1
A
license
A
quality
D
maintenance
Enables Claude Desktop to manage your LinkedIn profile and company pages, including posting, reading posts, and fetching profile information.
Updated 8 months ago (2026-01-10 11:46 UTC)
7
84 npm
4
MIT
LinkedIn MCP Server
Social Media Communication
rgthelen
A
license
A
quality
D
maintenance
Enables Claude to interact with LinkedIn for posting, commenting, sharing media, and viewing feed and profile.
Updated a year ago (2025-08-15 20:21 UTC)
9
84 npm
3
MIT