Skip to main content
Glama

Nilyo

by com.nilyo
OverviewDiscussionsAdmin

LinkedIn: Comment on post

linkedin_comment_on_post
Destructive

Publish a comment/reply on a LinkedIn post on behalf of the user. Requires post_id. Use after reading the post/comments and only when the user has asked to publish the final reply.

Input Schema

NameRequiredDescriptionDefault
textYesLinkedIn Classic mentions belong in text: @ followed by the resolved person's Classic ACo... ID or the company's numeric ID (for example @1441). Resolve people with linkedin_get_profile_from_url/linkedin_resolve_person and companies with linkedin_resolve_company/linkedin_search_companies; disambiguate every target before publishing. Never use a display name, profile URL, company slug, URN, Sales Navigator or Recruiter ID as a mention. Example after resolving both targets: 'Thanks @ACo_RESOLVED_MEMBER for working with @1441.' The API replaces each token with the target's name and mention metadata; no separate mentions field is needed. Approve the final text and mentioned identities before the write; never retry an ambiguous write automatically.
post_idYesExact provider post ID returned by post search/list/get. Never pass post text, author ID or URL. Post ID: Exact provider post id; LinkedIn commonly uses a preformatted/base64-style post ID. Obtain with: linkedin_search_posts -> result.id; linkedin_list_user_posts -> result.id; instagram_list_user_posts -> result.id Never pass: post text, author user ID, URL unless a resolver tool explicitly accepts it.
account_idNoOptional Nilyo connection ID (unipile_account_id from list_connected_accounts). Omit when the user has one account for this provider. When several exist, Nilyo never guesses: list them (display name, identifier, provider user ID), choose the one the user named or ask, and pass its ID here.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / text / description
      Added value: +"LinkedIn Classic mentions belong in text: @ followed by the resolved person's Classic ACo... ID or the company's numeric ID (for example @1441). Resolve people with linkedin_get_profile_from_url/linkedin_resolve_person and companies with linkedin_resolve_company/linkedin_search_companies; disambiguate every target before publishing. Never use a display name, profile URL, company slug, URN, Sales Navigator or Recruiter ID as a mention. Example after resolving both targets: 'Thanks @ACo_RESOLVED_MEMBER for working with @1441.' The API replaces each token with the target's name and mention metadata; no separate mentions field is needed. Approve the final text and mentioned identities before the write; never retry an ambiguous write automatically."
  2. Changed1 schema field changed
    • changedInput schema / properties / post_id / description
      Previous value: -"Exact provider post ID returned by post search/list/get. Never pass post text, author ID or URL. Post ID: Exact provider/Unipile post id; LinkedIn commonly uses a preformatted/base64-style post ID. Obtain with: linkedin_search_posts -> result.id; linkedin_list_user_posts -> result.id; instagram_list_user_posts -> result.id Never pass: post text, author user ID, URL unless a resolver tool explicitly accepts it."New value: +"Exact provider post ID returned by post search/list/get. Never pass post text, author ID or URL. Post ID: Exact provider post id; LinkedIn commonly uses a preformatted/base64-style post ID. Obtain with: linkedin_search_posts -> result.id; linkedin_list_user_posts -> result.id; instagram_list_user_posts -> result.id Never pass: post text, author user ID, URL unless a resolver tool explicitly accepts it."
  3. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the write/non-idempotent profile is covered. The description adds a consent guardrail ('only when the user has asked to publish the final reply'), which is useful, but it omits post-publication behaviors (that a comment can later be edited/deleted via social_update_comment/social_delete_comment) and any rate or visibility 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?

Two short sentences, front-loaded with the action and followed by the guardrail. Every clause earns its place and nothing is redundant with the schema.

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 destructive write with no output schema and full parameter documentation, the description covers the action, the required identifier, and the consent precondition, while annotations carry the safety profile. It is essentially complete, with only minor gaps around alternatives and post-publication editability.

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 the schema already fully documents post_id, text, and account_id, including the mention-token mechanics and how to obtain a post ID. The description only repeats 'Requires post_id' and adds no meaning beyond the structured field.

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?

States a specific verb+resource (publish a comment/reply on a LinkedIn post) and adds the scope 'on behalf of the user' and a required identifier. It clearly says what happens, but it conflates 'comment' and 'reply' and does not distinguish itself from the sibling linkedin_reply_to_comment, which is a plausible alternative for the same action.

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?

Gives real when-to-use context: 'Use after reading the post/comments and only when the user has asked to publish the final reply,' establishing a read-then-write ordering and a consent gate. It stops short of naming the alternatives (linkedin_reply_to_comment, linkedin_create_post) or stating 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.

All Nilyo toolsInspect
Try in Browser
Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources