Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@linkedin-mcp Post this image to LinkedIn with caption 'Happy Monday!'"
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.
A local MCP (Model Context Protocol) server that lets Claude log in to LinkedIn and publish image posts to your personal profile feed, backed by LinkedIn's REST Images API and Posts API.
Scope: two tools, linkedin_login and create_image_post. No org/company
page posting, no scheduling, no carousels.
Go to https://www.linkedin.com/developers/apps and click Create app. LinkedIn requires every app to be linked to a LinkedIn Page, even for personal-profile posting -- create a minimal Page first if you don't have one.
Fill in the app name, select the Page, upload a logo (required), accept the agreement, and click Create app.
In the Products tab, add:
Sign In with LinkedIn using OpenID Connect (grants openid,
profile, email) -- self-serve, instant.
Share on LinkedIn (grants w_member_social) -- self-serve, instant.
In the Auth tab, under OAuth 2.0 settings, add an Authorized redirect
URL that exactly matches LINKEDIN_REDIRECT_URI below (default
http://localhost:3000/callback, including the path -- must match
byte-for-byte).
Copy the Client ID and Client Secret from the Auth tab.
Known risk to watch for: the Microsoft Learn docs for /rest/images and
/rest/posts live under "Community Management API," which normally needs a
separate LinkedIn approval. Posting to your own profile with w_member_social
OpenID scopes has historically worked without that approval, but if your
first create_image_post call comes back with a 403, that's the signal your
app needs the Community Management API product added in the developer
portal (approval-gated, outside this code's control).
Related MCP server: linkedin-mcp
npm install
npm run buildAdd to claude_desktop_config.json:
{
"mcpServers": {
"linkedin": {
"command": "node",
"args": ["/absolute/path/to/linkedin-mcp/dist/index.js"],
"env": {
"LINKEDIN_CLIENT_ID": "xxxx",
"LINKEDIN_CLIENT_SECRET": "xxxx",
"LINKEDIN_REDIRECT_URI": "http://localhost:3000/callback"
}
}
}
}Add the same shape to your project or user .mcp.json, or run:
claude mcp add linkedin node /absolute/path/to/linkedin-mcp/dist/index.js \
--env LINKEDIN_CLIENT_ID=xxxx \
--env LINKEDIN_CLIENT_SECRET=xxxx \
--env LINKEDIN_REDIRECT_URI=http://localhost:3000/callbackRestart the client after editing config. You should see the server connected
with two tools: linkedin_login and create_image_post.
See .env.example for the full list. Only LINKEDIN_CLIENT_ID
and LINKEDIN_CLIENT_SECRET are required; everything else has a sane default.
Tokens are persisted to ~/.linkedin-mcp/tokens.json (mode 600) so you only
need to log in once per ~60-day LinkedIn access token lifetime.
In a Claude conversation:
"Log in to LinkedIn" -> calls linkedin_login, opens your browser, and
completes the OAuth flow. Calling it again when already logged in is a
no-op unless you pass force: true.
"Post this image to LinkedIn with caption ..." -> calls create_image_post
with imagePath or imageUrl, text, and optionally altText /
visibility.
npm run dev # run directly via tsx, without buildingAll logging goes to stderr (console.error) -- stdout is reserved for the
MCP JSON-RPC protocol stream over stdio.
Publish an image with text to the logged-in user's personal LinkedIn feed. Requires linkedin_login to have been run first. Provide exactly one of imagePath or imageUrl.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The post commentary/text. | |
| altText | No | Alt text for accessibility. | |
| imageUrl | No | Remote URL of the image to fetch and post. | |
| imagePath | No | Local filesystem path to the image. | |
| visibility | No | Post visibility. | PUBLIC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it posts to personal feed and requires prior login. Could be improved by mentioning posting side effects (e.g., immediate publication) or failure scenarios, but adequate given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Front-loaded with action and target. Every word is purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites and parameter constraints, but does not describe return values (e.g., post ID, success indicator). Given low complexity and no output schema, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value beyond schema by specifying mutual exclusivity of 'imagePath' and 'imageUrl', which schema does not enforce. Schema coverage is 100%, so description augments rather than repeats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb ('publish'), resource ('image with text'), and target ('logged-in user's personal LinkedIn feed'). Distinguishes from sibling 'linkedin_login' by making it a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states prerequisite ('Requires linkedin_login to have been run first') and parameter constraint ('Provide exactly one of imagePath or imageUrl'). Provides clear guidance for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Authenticate with LinkedIn via OAuth. Opens a browser for the user to log in and grant permissions. Only needed once -- tokens persist across sessions -- unless the token has expired or force is set.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Re-authenticate even if a valid session already exists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it opens a browser for OAuth, and tokens persist across sessions. It also explains the effect of the `force` parameter. However, it does not mention potential errors (e.g., user cancellation) or that the token is likely stored for future use, and there is no output schema. Despite no annotations, the description carries the burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the core function, second gives key usage guidance. No filler, every word adds value. Appropriate length for a simple authentication tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no output schema), the description covers the purpose, usage context, and parameter behavior adequately. It lacks details on failure modes or token scope, but is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the `force` parameter fully (boolean, description). The description adds context by tying `force` to re-authentication when token expires, reinforcing the parameter's purpose. With 100% schema coverage, the description adds meaningful extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Authenticate' and resource 'LinkedIn via OAuth', and mentions opening a browser for user login and permission grant. It is distinct from the only sibling 'create_image_post', which is a content creation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use: for authentication, emphasizing that it's only needed once due to token persistence. It explains when to use the `force` parameter. However, it does not explicitly state when not to use or mention alternatives, though the sibling tool is unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0create_image_postlinkedin_loginThe two tools have completely distinct purposes: one handles authentication, the other handles posting. There is no overlap or ambiguity between them.
Naming conventions are inconsistent: 'create_image_post' follows a verb_noun pattern while 'linkedin_login' follows a noun_noun pattern. However, both names are clear and understandable.
With only 2 tools, the server feels thin for a social media platform, but it may be intentionally scoped to image posting only. The count is borderline acceptable.
The server covers the basic workflow of authentication and posting an image, but lacks operations like updating, deleting, or retrieving posts. Notable gaps exist for a complete CRUD surface.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
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.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/egig/linkedin-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
