Skip to main content
Glama

comment_post

Post a comment on a LinkedIn post on behalf of the connected account. Use to write a new top-level comment on a post; to answer an existing comment use reply_comment. Counts against the daily comments quota; the text is public, preview it with the user.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "account_id": "<account_id>",
      "post_url_or_urn": "<post_url_or_urn>",
      "text": "<text>"
    },
    "name": "comment_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
textYesComment text.
page_idNoAct as this company page instead of the member: page_id (or vanity name) from list_managed_pages. The account must be an admin of the page with a role that allows the action. Omit to act as the member.
mentionsNoPeople to @mention. Write each name in text exactly as given here, without '@' (the full name, or the first name alone for a short mention); it becomes a link to the profile. Without this, '@Name' in the text would stay plain text, so a comment with '@Name' and no mention for it is refused before anything is sent: pass the mention, or drop the '@'. The result's mentions field says whether LinkedIn kept them: applied, not_applied (mentions_not_applied lists the names left as plain text; the comment is posted all the same, do not post it again) or unverified.
account_idYesReach id of the LinkedIn account to act on, from list_accounts.
idempotency_keyNoOptional. A key you choose (a UUID is fine) that names this exact call. If you retry with the same key and the same arguments, the first call's result is returned and nothing is done twice on LinkedIn. Reusing a key with different arguments is refused. Keys expire after 24 hours.
post_url_or_urnYesLinkedIn post URL, slug, or URN.

Output Schema

NameRequiredDescriptionDefault
mentionsNoOnly when mentions were passed: whether LinkedIn kept them as links.
commentedNo
mentions_not_appliedNoNames LinkedIn left as plain text. The comment is posted: do not post it again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / mentions
      Added value: +{
      +  "description": "People to @mention. Write each name in text exactly as given here, without '@' (the full name, or the first name alone for a short mention); it becomes a link to the profile. Without this, '@Name' in the text would stay plain text, so a comment with '@Name' and no mention for it is refused before anything is sent: pass the mention, or drop the '@'. The result's mentions field says whether LinkedIn kept them: applied, not_applied (mentions_not_applied lists the names left as plain text; the comment is posted all the same, do not post it again) or unverified.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "linkedin_id": {
      +        "description": "fsd_profile id (e.g. actor_linkedin_id, linkedin_id from scrape_post), vanity name or profile URL.",
      +        "type": "string"
      +      },
      +      "name": {
      +        "description": "The name as written in text, e.g. 'Jane Doe' or 'Jane'.",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "name",
      +      "linkedin_id"
      +    ],
      +    "type": "object"
      +  },
      +  "maxItems": 20,
      +  "type": "array"
      +}
    • addedOutput schema / properties / mentions
      Added value: +{
      +  "description": "Only when mentions were passed: whether LinkedIn kept them as links.",
      +  "enum": [
      +    "applied",
      +    "not_applied",
      +    "unverified"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / mentions_not_applied
      Added value: +{
      +  "description": "Names LinkedIn left as plain text. The comment is posted: do not post it again.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / page_id
      Added value: +{
      +  "description": "Act as this company page instead of the member: page_id (or vanity name) from list_managed_pages. The account must be an admin of the page with a role that allows the action. Omit to act as the member.",
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare a mutating, non-idempotent, open-world call, and the description adds real context beyond them: consumption of the daily comments quota and the fact that the text is publicly visible and should be user-previewed. It does not describe failure modes such as what a quota exhaustion error looks like, so it stops short of the top mark.

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 compact sentences, each carrying a distinct load: purpose, sibling routing, and constraints. Front-loaded with the action and no redundant restatement of the name or title.

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 6-parameter write tool with an output schema, the definition covers routing, side effects, quota cost, and the public-visibility risk. Return-value details are delegated appropriately to the output schema and the mentions field documentation.

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 adds meaning for 'text' by tying it to public visibility and mentioning the '@Name' interplay that must be resolved with the mentions array. The page_id and idempotency_key semantics are left entirely to the schema, which already documents them well.

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?

States a specific verb and resource ('Post a comment on a LinkedIn post') plus the acting identity ('on behalf of the connected account'). It explicitly contrasts with the sibling reply_comment, so an agent can route between the two without opening either 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?

Gives the selection rule directly: top-level comment here, answering an existing comment via reply_comment. It also adds an operational precondition ('preview it with the user') and a quota condition, covering when to use and when to be careful.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources