mcp-server-linkedin

Overview Schema Source Related Servers Discussions Admin

Comment On Post

comment_on_post

Destructive

Posts a comment on a LinkedIn post as the signed-in account, using the post permalink to verify the target before typing; set confirmation off to preview the post text.

Instructions

Comment on a LinkedIn post as the signed-in account.

The post is identified by its permalink, and the permalink alone decides where the comment lands: the tool navigates there and refuses to type unless the browser's own address is still that post. Pass a reference exactly as get_feed, search_posts or get_company_posts returned it in references. Note that search_posts appends permalinks without aligning them to result order, so a permalink taken from a search must be matched to the post you meant some other way before commenting: dry run it first and read the excerpt back, which is the post's own text from the page the comment would land on.

Only the post's own comment box is used, and only while it is the single comment box open on the page and already empty. Text someone else typed is never overwritten, and a reply to an existing comment is not reachable from here.

With confirm_comment False this is a read: it reports whether the post accepts a comment from this account, hands back an excerpt of that post's text, and returns dry_run without typing anything. This is a write operation when confirm_comment is True.

Commenting is rate-limited by LinkedIn and automated commenting at volume is what account restrictions are for. Treat each call as a deliberate act the user asked for, not as a loop to run over a list.

Input Schema

Name	Required	Description
`post`	Yes	The post's permalink or entity URN. Accepts ``urn:li:activity:…``, ``/feed/update/<urn>/``, ``/posts/<slug>`` and the full URL form of either.
`comment`	Yes	Comment text. LF, CRLF and CR all end a line; an empty line separates paragraphs and is kept. Whitespace-only lines count as empty, and leading and trailing whitespace of the whole comment is removed, as LinkedIn does when posting. Tab, other control characters, DEL, U+0085, U+2028 and U+2029 are refused.
`confirm_comment`	Yes	Must be True to post the comment

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv4.28.0Nov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say openWorldHint and destructiveHint; the description adds the real behavioral picture: navigation to the permalink, a refusal to type unless the browser URL still matches, a guarantee not to overwrite someone else's text, use of the single empty comment box, and a dry-run branch that is a pure read. It also discloses LinkedIn-side rate limiting and the account-restriction risk, which no annotation conveys.

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?

Purpose and the permalink-verification rule are front-loaded, and the paragraph breaks separate identity, mechanism, dry-run semantics, and risk. It is dense and longer than most definitions, but nearly every sentence carries operational information (the search_posts caveat in particular); a little tightening of the permalink paragraph would earn a 5.

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?

Even though an output schema exists, the description explains the dry_run and excerpt returns that an agent must interpret, covers the destructive branch, the failure/refusal conditions, and the rate-limit envelope. For a destructive, open-world browser-driven action with three required parameters, nothing an agent needs to call it safely is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description genuinely exceeds the schema: it explains that confirm_comment=False yields a read with excerpt and dry_run rather than merely being a flag, and it adds the search_posts permalink-order mismatch caveat for the post parameter that the schema does not mention. It stops short of restating accepted permalink forms, which is fine since the schema already lists them.

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 sentence names a specific verb and resource ('Comment on a LinkedIn post') and constrains the actor ('as the signed-in account'). It also explicitly delimits scope by ruling out replies to existing comments, so an agent can distinguish it from messaging and other post tools without opening the schema.

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?

It names the sibling tools that produce valid inputs (get_feed, search_posts, get_company_posts), explains the field to take the reference from, and flags the search_posts ordering pitfall with a concrete verification recipe (dry run, read the excerpt). It also states the exclusion (replies not reachable) and warns against looping automated calls, so when-to-use and when-not-to-use are both explicit.

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