How do I use linkedin-mcp-server?

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-server Publish a LinkedIn post announcing our summer sale" 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 N-Graves

Overview Schema Source Related Servers Score Discussions

TypeScript

Remote

linkedin-mcp-server

A Model Context Protocol server for the LinkedIn API.

MIT licensed.

Install

npm install -g @nasdigitaluk/linkedin-mcp

Related MCP server: LinkedIn MCP Server

Configuration

{
  "env": {
    "LINKEDIN_ACCESS_TOKEN": "your-token",
    "LINKEDIN_API_VERSION": "202606"
  }
}

LINKEDIN_API_VERSION is optional; it overrides the pinned default. Read on for why it exists.

A token can be obtained from LinkedIn's own OAuth Token Generator in the developer portal — no need to build a redirect flow for a single-account integration.

⚠️ Comments are unreachable, and no scope fixes it

Both directions of the comments API return 403 ACCESS_DENIED:

partnerApiSocialActions.CREATE.20260601
partnerApiSocialActions.GET_ALL.20260601

That is the LinkedIn Partner Program gate, not a missing scope — it happens with w_member_social already granted, which LinkedIn's own documentation implies is sufficient. It is not, for a standard app.

This server therefore ships no comment tool. A tool that fails only after the post is already public is worse than not having one: the usual pattern for LinkedIn is to put the outbound link in the first comment, and discovering at that moment that you cannot is the worst possible time. Post the comment by hand.

It is written down here so nobody has to rediscover it against a live account.

⚠️ The version header is a time bomb, so it is configurable

Every /rest/* call needs a LinkedIn-Version: YYYYMM header, and LinkedIn retires versions after roughly a year. "Roughly" is doing real work in that sentence: 202512 was already retired while 202506 was still being sent.

When it goes stale, every /rest/* call returns 426 NONEXISTENT_VERSION — which means post creation is broken, not merely whatever call happened to surface it.

So:

the version is overridable with LINKEDIN_API_VERSION, no release needed;
a 426 is turned into a message naming the cause and the fix, rather than a bare status.

⚠️ There is no draft state

LinkedIn's Posts API has no unpublished lifecycle. A successful create is immediately live. Any human approval step has to happen before linkedin_create_post is called — there is nothing to review afterwards except a post that is already out.

Images: three steps, in the right order

LinkedIn's Images API hands back a single-use uploadUrl and the URN the image will have before the bytes have been uploaded. Using that URN early attaches an image that is not there yet.

Here the sequence is: initialise, PUT the bytes, confirm, then create the post. An image LinkedIn rejects fails before anything is published, which matters because a LinkedIn post cannot be edited afterwards to add media.

The byte upload goes to a LinkedIn-supplied absolute URL outside the API host and sends raw bytes rather than JSON, so it is a direct fetch — with its own timeout, so it cannot hang the tool call.

The post URN comes back in a header

A successful create returns an empty body and puts the new post's URN in the x-restli-id response header. A client that only reads bodies cannot tell you what it just published, so this one reads the header and hands back the URN and a link.

Tools

Tool
`linkedin_get_me`	The authenticated member.
`linkedin_create_post`	Publish. Immediately live, no draft.
`linkedin_delete_post`	Delete your own post. Irreversible.
`linkedin_call`	Anything else on the API.

What is NOT covered

LinkedIn publishes no machine-readable spec, and much of its API is gated behind partner programmes that no amount of scope-granting opens. So this server does not claim complete coverage — it wraps what a standard developer app can verifiably do, and offers linkedin_call as a documented passthrough for the rest.

Claiming a complete catalogue here would be a claim that cannot be checked and would quietly stop being true.

Read-only and no-destructive modes

MCP_READ_ONLY=1       refuse anything that changes state
MCP_NO_DESTRUCTIVE=1  allow posting, refuse deletes

Testing

npm test                                              # 10 tests
SMOKE_ENV='{"LINKEDIN_ACCESS_TOKEN":"x"}' npm run smoke   # real MCP over stdio

Built on

@nasdigitaluk/mcp-server-core.

Licence

MIT.

Available Tools

4 tools

linkedin_callA

Call any LinkedIn endpoint directly. LinkedIn publishes no machine-readable spec, so this server does not claim a complete catalogue — this is how you reach the rest of the API. Paths are relative to https://api.linkedin.com. A /rest/ path automatically gets the version and protocol headers.

⚠️ Comments are NOT reachable, whatever scopes you hold. See the README.

ParametersJSON Schema

Name	Required	Description	Default
`body`	No
`path`	Yes	e.g. /rest/posts or /v2/userinfo
`query`	No
`method`	No		GET

TDQS

A3.8/5.0

Behavior3/5

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

Discloses automatic header injection for /rest/ paths and a hard limitation on Comments, but with no annotations it leaves other behaviors (auth failures, error format, side effects of POST/PUT/DELETE) undocumented.

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?

Compact and focused: two short paragraphs plus a warning. No filler or redundant explanation.

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?

Provides essential context for a generic endpoint tool, including base URL and a negative scope, but lacks examples, response format, or error handling guidance that would make it fully self-contained.

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

Parameters2/5

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

Only the path parameter receives meaningful description (relative URLs and /rest/ header behavior); body and query are left generic, and method relies on its enum. Schema coverage is only 25%, and the description does not compensate for the remaining parameters.

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?

Clearly states it calls any LinkedIn endpoint directly, positioning it as a catch-all beyond specialized siblings. The phrase 'rest of the API' distinguishes it from the listed specific tools.

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?

Explains when to use it (to reach endpoints not covered by the catalog) and explicitly warns that Comments are not reachable. Could be more explicit about preferring sibling tools when they match, but the context makes the intended use clear.

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

linkedin_create_postA

Publish to LinkedIn. ⚠️ There is NO draft state — LinkedIn's Posts API has no unpublished lifecycle to fall back on, so this goes live the moment it succeeds. Any human approval has to happen BEFORE this is called, never after.

An image is uploaded and confirmed first, so a picture LinkedIn rejects fails before anything is published — a LinkedIn post cannot be edited afterwards to add media.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Post commentary. LinkedIn's limit is 3000 characters.
`image_path`	No	Local .png/.jpg/.gif to attach. Uploaded before the post is created.
`visibility`	No		PUBLIC
`image_alt_text`	No

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses irreversibility (no draft state, goes live on success), approval ordering, image upload/validation before publish, and that media cannot be added later via edit. This is high-value behavioral context beyond the 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?

Three sentences, front-loaded with the core action, followed by two dense warnings that each earn their place. No filler or repetition of schema details.

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?

The critical context for a publish operation is covered: no draft, approval before, image failure behavior, and post-edit limitation. The only gap is that the return value/output is not described, which matters given there is no output schema.

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 already documents text and image_path, and the description adds useful behavioral semantics for image_path (uploaded and confirmed first, cannot add media later). However, visibility and image_alt_text are left to inference despite 50% schema coverage, and the description doesn't explain their role.

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 opening phrase 'Publish to LinkedIn' names a specific verb and resource, making the operation unambiguous. It is clearly distinct from siblings linkedin_get_me (read), linkedin_delete_post (destructive), and linkedin_call (raw API).

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 explicit workflow guidance: approval must happen before the call because there is no draft lifecycle, and the post goes live immediately. It doesn't explicitly contrast with sibling tools, but the context is strong enough for an agent to know when this tool is appropriate.

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 one of your own posts by URN. Irreversible.

ParametersJSON Schema

Name	Required	Description	Default
`post_urn`	Yes	e.g. urn:li:share:7123456789

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full disclosure burden. It states the operation is 'Irreversible,' which is the single most important behavioral trait for a destructive tool, and it scopes the action to the user's own posts. It does not mention error conditions, permissions, or side effects, but the critical permanence warning is present.

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 with zero filler: the verb and resource are front-loaded, the identification method is stated, and the irreversibility warning is appended. Every word 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 single-parameter destructive tool with no output schema and no annotations, the description covers the essential ground: what is deleted, whose post, how to identify it, and that it cannot be undone. The only gaps are the return value on success and failure cases, which are minor for a tool this simple.

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% — the schema already documents post_urn with a concrete example format (urn:li:share:7123456789). The description's 'by URN' merely reinforces what the schema states and adds no new semantic meaning. The baseline 3 applies because the schema carries the documentation burden.

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 ('Delete') with a precise resource ('one of your own posts') and the identification method ('by URN'). The 'your own' scope clearly differentiates it from any broader deletion capability and from siblings like linkedin_create_post, linkedin_get_me, and the generic linkedin_call. There is no ambiguity about what the tool does.

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 usage context is implied: the agent should use this when a user wants to remove one of their own posts. The 'your own' constraint provides a mild exclusion, but the description does not explicitly name alternatives or state when not to use this tool versus linkedin_create_post or linkedin_call. Guidance is adequate but inferred rather than stated.

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

linkedin_get_meB

The authenticated member — id, name and email if the token carries the scope.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

There are no annotations, so the description bears full responsibility for behavioral transparency. It mentions the condition for email retrieval ('if the token carries the scope') but does not disclose potential errors, rate limits, authentication requirements, or any side effects. The read-only nature is implied but not explicitly stated.

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, concise sentence that conveys all essential information without padding. It avoids unnecessary details and is well-structured for quick comprehension.

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?

The description provides sufficient context for the tool's expected behavior: it returns the member's id, name, and email (under a scope condition). Since there is no output schema, this explanation of the return content is valuable. It does not cover error cases or output formatting, but for a simple retrieval tool, this is reasonably complete.

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 tool has zero parameters, and the schema coverage is therefore 100% (empty). The description adds no additional meaning beyond the absence of parameters, which is already evident from the empty schema. This meets the baseline but does not exceed it.

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 purpose: retrieving the authenticated member's id, name, and email (with a scope condition). It identifies the specific resource ('me') and the data returned, leaving no ambiguity about what the tool does.

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

Usage Guidelines2/5

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

The description gives no explicit guidance on when to use this tool versus its siblings (e.g., linkedin_call or linkedin_create_post). While the purpose is self-evident, it does not mention alternatives or situations where another tool would be preferred, so the guidance is only implicit.

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.

4 tool updatesv1.0.0Sep 7, 2026
- First observedlinkedin_call
- First observedlinkedin_create_post
- First observedlinkedin_delete_post
- First observedlinkedin_get_me

Install Server

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

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct operation: profile retrieval, post creation, post deletion, and raw API access. The generic linkedin_call is clearly a fallback for reaching untapped endpoints, so there is no meaningful overlap with the specialized tools.

Naming Consistency5/5

All tools share the linkedin_ prefix and follow a consistent verb-based pattern: get_me, create_post, delete_post, call. The generic call still fits the verb scheme, so there is no naming convention mixing.

Tool Count5/5

Four tools is well-scoped for a server that covers profile lookup and post creation/deletion, backed by a raw API fallback. This is within the ideal range and each tool earns its place.

Completeness3/5

The server covers basic profile access and post create/delete, but lacks convenient read operations like get_post or list_posts. The raw linkedin_call can fill the gap, but agents are forced to use it for standard tasks, and comments are explicitly unsupported.

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

SalesTouchOAuth
io.salestouch
Give AI agents the LinkedIn tools to find, qualify, engage, and follow up with prospects.
Social Media CRM Autonomous Agents
22
ContentIn — LinkedIn Ghostwriter A
io.contentin
Write LinkedIn posts in your voice: ideas, drafts, scheduling, analytics from your personal AI.
Social Media Marketing
81
crispyOAuth
sh.crispy
Full LinkedIn access for AI agents: leads, messaging, and campaigns with safe limits built in.
Social Media CRM Communication
2
innernoteOAuth
space.innernote
Draft, reshape and schedule LinkedIn posts in the writer's own voice, not a generic AI one.
Social Media Marketing
1

Related MCP Servers

LinkedIn MCP Server
Social Media Communication
ahmedselimmansor-ctrl
F
license
A
quality
D
maintenance
Enables LLMs and agents to interact with LinkedIn's REST API for managing profiles, creating posts, viewing connections, and overseeing organizations.
Updated 4 months ago (2026-05-16 03:58 UTC)
5
2
-
LinkedIn MCP Server
Social Media Communication
fredericbarthelet
A
license
Not graded
quality
D
maintenance
Enables interaction with LinkedIn's Community Management API, allowing users to retrieve profile information and create posts via natural language.
Updated a year ago (2025-03-19 17:44 UTC)
113
39
MIT
LinkedIn MCP Server
Social Media Communication
quinnjr
A
license
B
quality
C
maintenance
Enables AI agents to manage LinkedIn profiles, posts, connections, skills, education, and certifications through the LinkedIn API.
Updated a month ago (2026-08-03 15:06 UTC)
18
176
64
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
113
3
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/N-Graves/linkedin-mcp-server'

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