Skip to main content
Glama

Get a comment's replies

get_comment_replies

Use when a comment get_comments returned has a thread (reply_count > 0 on TikTok and Facebook; Instagram may say 0 and still have one) and you need its replies. Not for top-level comments: use get_comments first; a comment it has not listed is comment_not_found, uncharged. Price: 3 credits per page. Pass the video (URL or platform + id) and comment_id. limit 1-100 (default 25); next_cursor is null at the end. A platform without replies is unsupported_platform.

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_id": "<comment_id>"
    },
    "name": "get_comment_replies"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoThe platform's own video id
urlNoTikTok, Instagram, YouTube or Facebook video URL. Pass this or platform + id
limitNo
cursorNonext_cursor from a previous get_comment_replies for the same comment, for the next page.
estimateNoQuote the price in Credits: no Run, no charge
platformNo
comment_idYesA comment's id, as get_comments returned it.
max_creditsNo
idempotency_keyNoReuse on a retry: replays the original Run, not charged again

Output Schema

NameRequiredDescriptionDefault
runNo
cachedNo
resultNo
poll_urlNo
estimate_creditsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / estimate / description
      Previous value: -"Return the price, in Credits, without running the operation or creating a Run"New value: +"Quote the price in Credits: no Run, no charge"
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Reuse the same key when retrying: a repeat returns the original Run and is not charged again"New value: +"Reuse on a retry: replays the original Run, not charged again"
    • changedOutput schema / properties / run / additionalProperties
      Previous value: -trueNew value: +{}
    • removedOutput schema / properties / run / properties
      Removed value: -{}
  2. Changed1 schema field changed
    • addedInput schema / properties / max_credits
      Added value: +{
      +  "minimum": 0,
      +  "type": "integer"
      +}
  3. Changed1 schema field changed
    • addedOutput schema / properties / poll_url
      Added value: +{
      +  "format": "uri",
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": true,
      +  "properties": {
      +    "cached": {
      +      "type": "boolean"
      +    },
      +    "estimate_credits": {
      +      "type": "integer"
      +    },
      +    "result": {
      +      "$ref": "#/properties/run"
      +    },
      +    "run": {
      +      "additionalProperties": true,
      +      "properties": {},
      +      "type": "object"
      +    }
      +  },
      +  "type": "object"
      +}
  5. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (destructiveHint false, openWorldHint true, idempotentHint false), and the description adds value beyond them: per-page pricing at 3 credits, the uncharged failure path, the terminal condition (next_cursor null), and unsupported_platform for platforms lacking replies. The one gap is that the description never reconciles the stated next_cursor with the schema's `cursor` parameter, which slightly undersells how paging actually works.

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?

It is front-loaded with the selection condition, then pricing, then parameters, and almost every clause carries a distinct fact. It is dense but not padded; the only wrinkle is the use of next_cursor terminology that does not match the `cursor` parameter name.

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 9-parameter, charged, paginated tool it covers the essentials — gating condition, cost, error names, pagination end, unsupported platforms — and an output schema exists so return values need not be spelled out. The remaining incompleteness is how a caller should pass next_cursor back into `cursor` and what max_credits/estimate do in practice.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema coverage at 67%, the description compensates by explaining that a video is identified either as a URL or as platform + id, that limit runs 1–100 with a default of 25 (the default is not in the schema), and what the cursor terminates on. It says nothing about max_credits or estimate beyond what the schema already declares, and the next_cursor/cursor naming is not fully aligned.

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 first sentence names a specific verb and resource (replies to a comment) and pins the precondition (reply_count > 0 on a comment returned by get_comments). The second sentence explicitly excludes top-level comments and names get_comments as the tool to use instead, so the agent can separate it from the sibling without opening either schema.

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

Usage Guidelines5/5

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

It states when to use (comment has a thread), when not to (top-level comments go to get_comments), encodes the redirect as a concrete error (comment_not_found, uncharged), and flags the platform edge case where Instagram reports 0 replies but has a thread. That is explicit when/when-not/alternative guidance.

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