Taplio for LinkedIn

List posted comments

list_comments

Read-onlyIdempotent

List the comments the user posted on other people's LinkedIn posts, newest first, whether they went out through Taplio, the Taplio app or directly on LinkedIn, each with its stats: impressions, likes, replies and reactions by type. Stats come from a daily sync, so a comment posted since the last sync has none yet. Comments recorded before Taplio stored the urn come back without a comment_urn and cannot be fetched with get_comment. Returns the user's comments on the posts they most recently commented on, up to 100 posts; a post they commented on several times returns all of those comments, so the list can hold more than 100.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_comments"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Max posts to return comments from, newest first. Defaults to 25 posts, capped at 100 posts. Every comment the user left on a post comes back with it, so the list can hold more comments than this.
`post_urn`	No	Only return the user's comments on this LinkedIn post urn. Omit for every post.

Output Schema

Name	Required	Description	Default
`items`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already establish readOnly/idempotent/closed-world, and the description goes well beyond them: stats lag behind a daily sync, comments recorded before the urn was stored lack comment_urn and break downstream get_comment calls. The pagination quirk (limit counts posts, not comments, so results can exceed 100) is a genuinely non-obvious behavioral trait disclosed up front.

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 front-loaded with what the tool returns and its ordering, then adds caveats in a logical sequence. It runs long and partly duplicates the schema on the 100-post cap, but every sentence carries real information rather than filler.

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?

With an output schema handling return shape and annotations covering safety, the remaining burden is behavioral: data freshness, urn gaps, and the posts-vs-comments limit semantics. All three are covered, leaving nothing an agent needs in order to call this correctly.

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 both limit and post_urn are already documented, including the posts-vs-comments counting subtlety and the default of 25 / cap of 100. The description restates the same semantics without adding syntax or format detail beyond the schema, so the 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 gives a specific verb and resource ('List the comments the user posted on other people's LinkedIn posts') plus ordering ('newest first') and source scope (Taplio, the Taplio app, or directly on LinkedIn). It also separates itself from the sibling get_comment by noting that pre-urn comments 'cannot be fetched with get_comment', so an agent can tell this aggregate lister apart from the single-item fetch.

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?

Usage context is clear: this is the aggregate view of comments already posted elsewhere, as opposed to drafts, and the daily-sync caveat tells the agent when stats will be missing. What's missing is an explicit redirect to the draft-listing siblings (list_comment_drafts / list_comment_feeds) for the not-yet-posted case, which the description never names.

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

All Taplio for LinkedIn tools Inspect

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.