Skip to main content
Glama

Flux LinkedIn MCP

LinkedIn Post Comments

linkedin_post_comments

Fetch the people who commented on a single LinkedIn post (and their comment text). Costs 5 credits per call. Each comment is persisted to post_engagements with the commenter and full comment text.

Input Schema

NameRequiredDescriptionDefault
refreshNoBypass the cache and re-fetch from LinkedIn (costs 5 credits). Default false: a previously-fetched result is returned free, with how long ago it was retrieved.
post_urlYesPublic LinkedIn post URL (e.g. https://www.linkedin.com/feed/update/urn:li:activity:1234)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior3/5

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

No annotations exist, so the description bears the full behavioral burden. It does disclose two important traits: a 5-credit cost and that each comment is persisted to post_engagements, which is genuinely non-obvious side-effect information. However, it says 'costs 5 credits per call' without noting the cache path that makes repeat calls free, and omits any auth or rate-limit context.

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?

Three short sentences with no filler, and the core capability is stated first. The cost statement earns its place but is slightly imprecise relative to the refresh parameter, which is the only real deduction.

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 two-parameter read tool with no output schema and no annotations, the description covers purpose, cost and a persistence side effect. The notable gap is the absence of any mention of result limits or pagination, so an agent cannot tell how many comments come back.

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 post_url and refresh are fully documented in the schema, establishing the baseline of 3. The description adds no parameter-level detail beyond the ambiguous per-call credit claim, which actually conflicts slightly with the schema's note that cached results are free.

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?

The description names a specific verb and resource: fetching the commenters on a single LinkedIn post plus their comment text. That is clearly distinct from siblings like linkedin_post_reactions (reactions) and linkedin_profile_comments (comments tied to a profile), though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The word 'single' implies the tool takes one post rather than a set, which is useful scoping. But the description never states when to prefer this over linkedin_post_reactions or linkedin_profile_comments, and gives no exclusions or prerequisites.

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