Taplio for LinkedIn

Get posted comment

get_comment

Read-onlyIdempotent

Fetch one comment the user posted on LinkedIn, by its comment_urn, with its stats: impressions, likes, replies and reactions by type. Covers comments posted through Taplio, the Taplio app or directly on LinkedIn. Stats come from a daily sync, so a comment posted since the last sync has none yet. Comments recorded before Taplio stored the urn have no comment_urn and cannot be fetched here.

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": {
      "comment_urn": "<comment_urn>"
    },
    "name": "get_comment"
  }
}

Input Schema

Name	Required	Description	Default
`post_urn`	No	The urn of the post the comment is on. Only needed when the comment urn does not name its post.
`comment_urn`	Yes	The comment urn, from list_comments or a posted comment draft, e.g. urn:li:comment:(activity:123,456).

Output Schema

Name	Required	Description	Default
`stats`	No
`content`	Yes
`post_urn`	Yes
`posted_at`	Yes
`comment_urn`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world, so the description adds genuinely new behavior: stats are populated by a daily sync, meaning freshly posted comments return zero stats — a freshness caveat the annotations do not convey. Data-availability limits (legacy comments without urns) are also disclosed, though error behavior for unknown urns is not.

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?

Four short sentences, front-loaded with what is fetched and what is returned, followed by source coverage, freshness, and availability constraints. No sentence is redundant; each adds a distinct operational fact.

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 two-parameter read with a 100%-covered schema, an output schema, and full annotations, the description covers exactly the gaps structured data cannot: source coverage, sync lag, and un-fetchable legacy records. Nothing an agent needs to call it correctly is missing.

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 comment_urn and the conditional post_urn are already documented in the schema, including the example urn format. The description names comment_urn but adds no meaning beyond it and never mentions post_urn, so the baseline 3 applies.

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 and resource ('Fetch one comment the user posted on LinkedIn, by its comment_urn') and enumerates what comes back (impressions, likes, replies, reactions by type). It does not explicitly name the sibling it contrasts with (list_comments for many, get_comment_draft for drafts), so an agent must infer the single-vs-list boundary.

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?

Provides concrete eligibility context: comments posted via Taplio, the app, or LinkedIn directly are covered, while pre-urn legacy comments 'cannot be fetched here' — an explicit when-not condition. It lacks a direct pointer to the alternative (list_comments) for discovering comment_urn values, leaving the workflow inference to the agent.

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.