How do I use @isteam/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., "@@isteam/linkedin-mcp create a post announcing our new product launch" 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.

@isteam/linkedin-mcp

by isteamhq

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

@isteam/linkedin-mcp

MCP server for LinkedIn — post, comment, react, and manage content via AI agents.

Built by is.team — the AI-native project management platform.

Quick Start

Add to your MCP config (.mcp.json for Claude Code, or Claude Desktop settings):

{
  "mcpServers": {
    "linkedin": {
      "command": "npx",
      "args": ["-y", "@isteam/linkedin-mcp"],
      "env": {
        "LINKEDIN_ACCESS_TOKEN": "your-access-token",
        "LINKEDIN_PERSON_ID": "your-person-id"
      }
    }
  }
}

Related MCP server: LinkedIn MCP Server

Tools (10)

Content & Engagement

Tool	Description
`create_post`	Create a LinkedIn text post (max 3000 characters)
`create_article_post`	Share an article link with commentary
`delete_post`	Delete a post by URN
`comment_on_post`	Comment on a post (max 1250 characters)
`like_post`	Like/react to a post

Profile & Analytics

Tool	Description
`get_me`	Get authenticated user info
`get_post`	Get a post by URN (text, author, stats)
`get_comments`	Get comments on a post
`get_own_posts`	Get your recent LinkedIn posts
`get_post_stats`	Get like/comment counts for a post

Environment Variables

Variable	Required	Description
`LINKEDIN_ACCESS_TOKEN`	Yes	OAuth 2.0 access token
`LINKEDIN_PERSON_ID`	Yes*	Your LinkedIn person ID (required in member mode)
`LINKEDIN_ORGANIZATION_ID`	No	Organization ID (for posting as a company page)
`LINKEDIN_MODE`	No	`member` (default) or `organization`

*Required when LINKEDIN_MODE is member (default).

Getting your credentials

Create an app in the LinkedIn Developer Portal
Request the w_member_social and r_liteprofile OAuth scopes
Complete the OAuth 2.0 flow to get an access token
Get your person ID from the /v2/userinfo endpoint

Organization mode

To post as a company page, set LINKEDIN_MODE=organization and provide LINKEDIN_ORGANIZATION_ID:

{
  "env": {
    "LINKEDIN_ACCESS_TOKEN": "your-access-token",
    "LINKEDIN_PERSON_ID": "your-person-id",
    "LINKEDIN_ORGANIZATION_ID": "your-org-id",
    "LINKEDIN_MODE": "organization"
  }
}

Rate Limits & Agent Safety

LinkedIn API enforces per-endpoint rate limits:

Endpoint	Limit	Notes
`POST /rest/posts` (create post)	1 req/sec, ~100/day	Stricter daily cap on content creation
`POST /rest/socialActions/.../comments`	2 req/sec
`POST /rest/reactions` (like)	1 req/sec
`GET` endpoints (posts, comments, stats)	~100 req/hour	Per authenticated user
General throttle	~60 req/min	Varies by endpoint scope

Idempotency note: LinkedIn does not deduplicate identical posts. If your agent retries on timeout, it may create duplicate content. Use get_own_posts to verify before retrying a create operation.

Backoff: When rate-limited, the API returns 429 with a Retry-After header (seconds). Wait the specified duration before retrying.

Usage Examples

Share a thought leadership post:

"Post on LinkedIn: AI agents are changing how teams collaborate. At is.team, we're building a future where AI joins your standups and ships features alongside you."

Share an article:

"Share this article on LinkedIn with a summary: https://example.com/article-about-ai"

Engage with your network:

"Get my recent LinkedIn posts and show their engagement stats"

About is.team

is.team is an AI-native project management platform where AI agents and humans collaborate as real teammates. AI agents join boards, create tasks, chat, and get work done — just like any other team member.

Part of the is.team open-source MCP ecosystem:

@isteam/mcp — Project management
@isteam/google-ads-mcp — Google Ads
@isteam/twitter-mcp — Twitter/X
@isteam/bluesky-mcp — Bluesky
@isteam/linkedin-mcp — LinkedIn

License

MIT

Available Tools

10 tools

comment_on_postA

Comment on a LinkedIn post (max 1250 chars). Requires post URN — use WebSearch to find posts, then get_post to get the URN.

ParametersJSON Schema

Name	Required	Description	Default
`post_urn`	Yes	URN of the post to comment on
`text`	Yes	Comment text (max 1250 chars)

TDQS

A3.9/5.0

Behavior2/5

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

No annotations exist, placing full burden on description. It only mentions max length but fails to disclose important behaviors like visibility, editability, rate limits, or authentication needs.

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 concisely convey purpose, constraint, and usage guidance. No redundant information.

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?

While the tool is simple, the description omits details about post-comment behavior (e.g., public visibility, inability to edit). Moderate completeness for a write action.

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%, so baseline is 3. The description adds context about obtaining the URN but does not significantly enhance parameter 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 clearly states the action 'Comment on a LinkedIn post' and specifies the max length constraint. It distinctly identifies the tool's purpose among siblings like 'create_post' or 'delete_post'.

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

Usage Guidelines5/5

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

The description explicitly instructs to use WebSearch and get_post to obtain the post URN, providing clear guidance on prerequisites and workflow.

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

create_article_postC

Share an article link on LinkedIn with commentary

ParametersJSON Schema

Name	Required	Description
`text`	Yes	Commentary text for the article share
`article_url`	Yes	URL of the article to share
`article_title`	No	Title for the article card
`article_description`	No	Description for the article card

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description bears full burden. It lacks disclosure of side effects (e.g., public posting), authentication requirements, or rate limits. Minimal behavioral context beyond the basic 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?

Single sentence, 8 words, no fluff. Every word carries meaning. Appropriately concise for the tool's simplicity.

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

Completeness2/5

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

Despite simplicity, the description omits important context: how article card fields (title, description) interact, URL validation, and posting behavior. For a social media post tool, more detail is needed.

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 minimal value beyond schema; 'commentary' and 'article share' are implied. No additional format or usage details.

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

Purpose4/5

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

The description clearly states the action ('share'), resource ('article link'), and context ('on LinkedIn with commentary'). It distinguishes from sibling tools like create_post (generic post) and comment_on_post, though not explicitly.

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?

No guidance on when to use this tool versus alternatives (e.g., create_post, comment_on_post). No prerequisites or conditions provided.

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

create_postA

Create a LinkedIn text post (max 3000 chars)

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Post text (max 3000 chars)

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 full burden. It only discloses the max character limit (already in schema) and implies creation is destructive. It omits critical details like authentication requirements, idempotency, rate limits, or success/failure behavior. This is insufficient for a mutation 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 a single, well-structured sentence that conveys the core purpose and key constraint (max 3000 chars) without superfluous words.

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 has only one parameter and no output schema, the description is somewhat complete but lacks expected details for a creation tool, such as what the response contains (e.g., post ID) or confirmation of success.

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% for the single parameter, so baseline is 3. The description adds no additional semantic information beyond what the schema provides (the parameter name 'text' and its constraints).

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 text post, specifying the resource (text post) and action (create). It distinguishes from the sibling tool 'create_article_post', which handles article posts, making the purpose unambiguous.

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 the tool is for text-only posts, and the sibling name 'create_article_post' provides contrast. However, it lacks explicit guidance on when not to use this tool (e.g., for posts with media or links) or mention of alternatives.

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

delete_postB

Delete a LinkedIn post by URN

ParametersJSON Schema

Name	Required	Description	Default
`post_urn`	Yes	URN of the post to delete (e.g. urn:li:share:123456)

TDQS

B3.2/5.0

Behavior2/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. It states the action but does not disclose any side effects (e.g., permanence, cascading effects, auth requirements, rate limits). For a destructive mutation, this is insufficient.

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?

Single sentence, no wasted words. Fits the tool's simplicity. Appropriate length.

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

Completeness2/5

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

For a simple destructive operation with no output schema, the description is too minimal. It lacks context on success/failure, permanence, or authorization requirements, making 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?

Schema coverage is 100%, so baseline is 3. The description adds 'by URN' which is already in the schema's description. No additional meaning beyond what the schema provides.

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' and identifies the resource 'LinkedIn post' with the method 'by URN'. It clearly distinguishes from sibling tools like create_post, comment_on_post, etc., 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 Guidelines2/5

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

No guidance on when to use this tool vs alternatives, nor any warnings or prerequisites. The context is implied (delete a post) but no exclusions or when-not-to-use.

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

get_commentsC

Get comments on a LinkedIn post

ParametersJSON Schema

Name	Required	Description	Default
`post_urn`	Yes	URN of the post to get comments for
`count`	No	Number of comments to fetch

TDQS

C2.6/5.0

Behavior1/5

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

No annotations are provided, so the description must disclose behavioral traits. It only says 'Get comments on a LinkedIn post' with no mention of authentication, rate limits, or any side effects. This fails to inform the agent of important operational context.

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

Conciseness3/5

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

The description is extremely short (5 words), which is concise but at the expense of completeness. It lacks structure such as examples or sections, and while every word earns its place, the overall informativeness is minimal.

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

Completeness2/5

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

Given the tool has no output schema, no annotations, and only two parameters, the description should provide more context about the return format or behavior. It is incomplete for a tool that retrieves data, leaving the agent uninformed about what the response contains.

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 covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no additional semantics beyond what the schema already provides, so it neither improves nor detracts.

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

Purpose4/5

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

The description clearly states the verb 'Get' and the resource 'comments on a LinkedIn post', making the tool's purpose unambiguous. However, it does not differentiate from sibling tools like 'get_post' or 'get_post_stats', which are also simple retrieval operations.

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?

No guidance is provided on when to use this tool versus alternatives such as 'get_post' or 'get_post_stats'. There is no mention of prerequisites, context, 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.

get_meA

Get authenticated LinkedIn user info

ParametersJSON Schema

Name	Required	Description	Default
No parameters

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 any behavioral traits such as authentication needs, rate limits, or data freshness. It simply states the action without additional 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?

The description is extremely concise: one sentence that directly states the tool's purpose with no superfluous content.

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 is minimally complete. It states what the tool does but lacks details about the return structure or any side effects. Adequate but could be more informative.

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 no parameters, so the schema coverage is 100%. The description does not need to add parameter meaning; a baseline score of 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 'Get authenticated LinkedIn user info' uses a specific verb ('get') and a clear resource ('authenticated LinkedIn user info'), clearly distinguishing it from sibling tools like get_post or get_comments.

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?

No explicit guidance on when to use this tool versus alternatives, but the purpose implies it's for retrieving the current user's profile info. There are no exclusions or when-not statements.

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

get_own_postsB

Get your own recent LinkedIn posts

ParametersJSON Schema

Name	Required	Description	Default
`count`	No	Number of posts to fetch

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It merely states a read operation but omits details like pagination, sorting (by recency?), or any immutability guarantees.

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 exceptionally concise (6 words) and directly conveys the core functionality without extraneous 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?

Given the tool's simplicity (one parameter, no output schema), the description is nearly complete. It could mention that posts are returned in reverse chronological order, but the brevity is acceptable.

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% for the single parameter 'count', which is described as 'Number of posts to fetch'. The tool description adds no additional 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 clearly states the tool retrieves the user's own recent LinkedIn posts, specifying a distinct resource (own posts) that differentiates it from sibling tools like get_post or get_comments.

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?

No guidance is provided on when to choose this tool over alternatives like get_post or get_comments. The description lacks context for optimal use cases or exclusions.

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

get_postA

Get a LinkedIn post by URN (text, author, stats)

ParametersJSON Schema

Name	Required	Description	Default
`post_urn`	Yes	URN of the post (e.g. urn:li:share:123456 or urn:li:ugcPost:123456)

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It mentions returned fields but does not describe error handling, authentication needs, or any side effects (though read-only). Minimal transparency.

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?

Single sentence, front-loaded with purpose and key details. No wasted words.

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 retrieval tool with one parameter and no output schema, the description adequately covers what is returned. Could specify error behavior but is largely 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?

With 100% schema coverage, baseline is 3. The description adds examples of valid URN formats (e.g., urn:li:share:123456), which clarifies parameter usage beyond the schema's brief 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?

The description clearly states the action (Get), the resource (LinkedIn post), and the key returned fields (text, author, stats). It distinguishes from siblings like get_post_stats (stats only) or get_own_posts (list).

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 (get by URN) but does not explicitly state when to use versus alternatives like get_post_stats or create_post. No guidance on prerequisites or when not to use.

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

get_post_statsB

Get like/comment counts for a LinkedIn post

ParametersJSON Schema

Name	Required	Description	Default
`post_urn`	Yes	URN of the post

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must cover behavioral traits, but it only states the action without specifying scope (e.g., own vs any post), data freshness, rate limits, or required permissions.

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

Conciseness4/5

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

The description is extremely concise, using 5 words to convey purpose; it is front-loaded and efficient, though slightly more detail on usage could be added without sacrificing brevity.

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

Completeness2/5

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

Given the simple tool (1 param, no output schema), the description fails to address return value format, error cases, or any context beyond the basic action, resulting in incomplete guidance.

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 single parameter is fully described in the input schema (URN of the post), and the tool description adds no additional semantic value beyond what the schema already provides, meeting baseline for high 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 states the tool retrieves like and comment counts for a LinkedIn post, differentiating it from sibling tools like get_post (full post details) and get_comments (comment list).

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?

No usage guidelines are provided; there is no indication of when to use this tool over alternatives like get_post or when not to use it, leaving the agent without decision support.

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

like_postA

Like/react to a LinkedIn post

ParametersJSON Schema

Name	Required	Description	Default
`post_urn`	Yes	URN of the post to like

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, and the description only mentions 'like/react' without disclosing whether it supports multiple reaction types, idempotency, or notification effects. The description carries the burden but is insufficient.

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?

Single sentence, no wasted words. Front-loaded with the core action.

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?

Given the simple single-parameter tool with no output schema, the description is largely complete. However, it lacks details on reaction types or whether the tool can be used for other reactions beyond a simple like.

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 covers 100% of parameters with a description. The tool description adds no extra meaning beyond the schema, so baseline of 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?

The description clearly states the verb 'like/react' and the resource 'LinkedIn post', distinguishing it from sibling tools like comment_on_post or create_post.

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?

No explicit guidance on when to use this tool versus alternatives like comment_on_post or other reaction tools. Usage is implied but not stated.

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.

10 tool updatesv1.0.1May 28, 2026
- First observedcomment_on_post
- First observedcreate_article_post
- First observedcreate_post
- First observeddelete_post
- First observedget_comments
- First observedget_me
- First observedget_own_posts
- First observedget_post
- First observedget_post_stats
- First observedlike_post

Install Server

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

TDQS

A3.6/5.0

Scored 2026-05-28 19:15 across 10 tools

Disambiguation5/5

Each tool targets a distinct action (e.g., create vs delete vs get stats) with clear boundaries. No two tools overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., create_post, delete_post, get_comments) with underscores, making them predictable.

Tool Count5/5

10 tools cover the essential LinkedIn post lifecycle (CRUD plus comments, likes, stats) without being excessive or insufficient.

Completeness4/5

Missing an update/edit post tool, and repost/share functionality is absent. However, core operations are well-covered, and the gap is minor.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

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
198
Fintalio LinkedIn MCP
com.fintalio
LinkedIn outreach MCP server — 19 tools for AI agents to prospect, sequence, and manage contacts.
Communication CRM Social Media
2
LeadDelta MCP ServerOAuth
io.github.LeadDelta
MCP server for LeadDelta — manage LinkedIn connections and CRM data via AI assistants.
Customer Data Platforms Social Media Marketing
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

LinkedIn MCP Server
Social Media Browser Automation
selvin-paul-raj
A
license
A
quality
D
maintenance
Fully featured MCP server that provides automation tools for LinkedIn, supporting browser-based scraping and API-based operations for content management, media uploads, and reactions.
Updated 3 months ago (2026-06-04 11:54 UTC)
6
3
MIT
LinkedIn MCP Server
Social Media Search Project Management
wlyonscat
A
license
Not graded
quality
D
maintenance
An MCP server that enables AI assistants to interact with LinkedIn, including job search, profile viewing, resume/cover letter generation, and application tracking.
Updated 5 months ago (2026-04-01 03:22 UTC)
MIT
linkedin-automation-mcp
Social Media Browser Automation AI & Machine Learning
Rohan797217
A
license
Not graded
quality
C
maintenance
AI-powered LinkedIn automation server for content generation, profile/company data extraction, and connection request automation, integrating with MCP clients like Claude Desktop.
Updated 2 months ago (2026-07-05 12:05 UTC)
MIT
linkedin-outreach-agent
Social Media Communication Browser Automation
jsilets
A
license
Not graded
quality
A
maintenance
An MCP server that enables agent-driven LinkedIn outreach across multiple accounts, with a safety gate for human approval and LLM-powered personalization.
Updated a month ago (2026-07-31 17:57 UTC)
1
Apache 2.0