Skip to main content
Glama

Nilyo

by com.nilyo
OverviewDiscussionsAdmin

Posts: Update comment

social_update_comment
Destructive

Edit an existing comment. Required chain when starting from human text: resolve post -> post.id -> list comments -> comment.id -> edit. post_id and comment_id are different ID namespaces. 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. Comment ID: Exact comment id scoped to the identified post. Obtain with: linkedin_list_post_comments(post_id) -> comment.id; instagram_list_post_comments(post_id) -> comment.id Never pass: comment text, post_id.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesFinal replacement comment text explicitly requested/approved by the user.
post_idYesExact provider post ID. Resolve/list the post first; never pass post text, author ID or a human description. 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.
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.
comment_idYesExact comment ID belonging to the already resolved post_id. Obtain by listing comments on that post; never pass comment text or post_id here. Comment ID: Exact comment id scoped to the identified post. Obtain with: linkedin_list_post_comments(post_id) -> comment.id; instagram_list_post_comments(post_id) -> comment.id Never pass: comment text, post_id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already indicate this is not read-only and is destructive; the description adds meaningful context by explaining that post_id and comment_id belong to different ID namespaces and must be sourced through specific resolver/list tools. It also stresses that text must be 'explicitly requested/approved by the user', which is useful safety behavior beyond the annotations.

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

Conciseness2/5

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

The description is substantially repetitive: the full ID-sourcing guidance appears both in the main description and again verbatim inside the post_id and comment_id schema descriptions. The important workflow is front-loaded, but the bloated, run-on phrasing and duplicated content hurt readability.

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 4-parameter mutation tool with no output schema, the description covers the full invocation workflow, ID provenance, account disambiguation, and prohibited input types. It is nearly complete, though it never states what the caller should expect in the response after a successful edit.

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 documents all parameters thoroughly. The description repeats most of that information rather than adding unique parameter-level meaning; the only marginal addition is the explicit 'different ID namespaces' warning, but it is not enough to push beyond baseline.

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 phrase 'Edit an existing comment' names a specific verb and resource, and the title 'Posts: Update comment' reinforces the operation. It is clearly distinguished from siblings like social_delete_comment, linkedin_comment_on_post, and social_update_post by stating exactly which mutation it performs.

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 gives an explicit required chain: resolve post -> post.id -> list comments -> comment.id -> edit, and warns against passing post text, author IDs, or URLs. It does not explicitly name alternative create/delete comment tools, but the when-to-use and when-not-to-use guidance is clear enough for an agent to follow.

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources