Skip to main content
Glama

SocialDataX X / Twitter MCP

x_get_post_comment_replies_by_comment_id

Read-only

根据 X 帖子 ID 和一级评论 ID 获取公开评论回复列表;用户已提供完整合法的 ID 组合时直接使用;已有 post_id 或帖子链接但缺少必需 ID 时,调用对应一级评论工具补全;缺少帖子定位信息时向用户索取;不要传评论回复结果里的 comment_id 或评论链接。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
post_idYesX 帖子 ID;用户已提供时直接使用,否则请原样复制获取一级评论时使用的 post_id,或评论列表 items[*].post_id;必须是数字字符串;不要传评论 ID、帖子链接、用户名或分享文案。
comment_idYesX 一级评论 ID;用户已提供时直接使用,否则请原样复制 x_get_post_comments_by_post_id 或 x_get_post_comments_by_post_url 返回的 items[*].comment_id;不要传帖子 ID、评论回复结果里的 items[*].comment_id、评论链接、用户主页链接或分享文案。
page_tokenNoX 评论回复列表分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回;page_token 是不透明分页令牌;不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成,不得用省略号替换中间内容。只能用于同一帖子下同一条一级评论的回复列表;切换 post_id 或 comment_id 时请清空 page_token 后从第一页重新获取。

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYes当前页评论回复列表;当前页可能为空,是否可继续翻页以 next_page_token 是否为空为准。
pointsYes本次成功调用的积分消耗与调用完成时的账户积分余额。
next_page_tokenYes下一页不透明分页令牌;为空表示没有更多评论回复。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回;只用于当前帖子下同一条一级评论的评论回复列表续页;不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成,不得用省略号替换中间内容。

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already indicate read-only and open-world behavior; the description adds useful context by specifying that only public replies are returned and by warning against feeding reply-level comment IDs or comment links back into this tool. It does not discuss error or rate-limit behavior, but the annotations and output schema reduce the need for that.

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?

The description is a single compact sentence with semicolon-separated conditions, front-loading the core purpose and then giving concise routing rules. There is no filler or redundant restatement of the tool name.

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 present, annotations for read-only/open-world behavior, and 100% schema coverage, the description covers the crucial workflow decisions: when to use directly, when to call another tool, when to ask the user, and what not to pass. The schema additionally covers page_token handling, making the definition complete for agent invocation.

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%, and the parameter descriptions already explain the required ID formats, sources, and forbidden values. The tool description mostly restates workflow decisions rather than adding new per-parameter meaning, so baseline 3 is appropriate.

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 identifies a specific operation: retrieving public comment replies for a given X post ID and first-level comment ID. It clearly distinguishes this from sibling first-level comment tools by stating it operates on replies and by warning not to use reply-result comment IDs.

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?

The description explicitly states when to call this tool directly, when to call a first-level comment tool to fill in missing IDs, when to ask the user for post locator information, and what not to pass as an argument. These routing rules leave little ambiguity for an agent.

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.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools are clearly distinguished by resource, action, and identifier type (e.g., by_post_id vs by_post_url). The descriptions explicitly state when to use each, reducing ambiguity, but the high number of near-duplicate variants for user/posts/detail actions can still cause careful selection to be needed.

Naming Consistency4/5

The X tools follow a consistent pattern: x_get_<resource>_by_<identifier>, x_search_posts, and x_submit_x_by_<identifier>. The single socialdatax_get_points_balance tool uses a different prefix and pattern, creating a minor but noticeable inconsistency.

Tool Count4/5

16 tools is slightly above the ideal range, but the count is justified by the multiple identifier variants (ID, URL, username) for the same resource. Each tool maps to a specific input scenario, so the count feels intentional rather than bloated.

Completeness4/5

The server covers core X/Twitter read workflows: user info, user posts, post details, comments, comment replies, search, and the video speech text feature. Common gaps like followers/following or trending topics exist, but they are outside the apparent scope of the tool set and do not cause dead ends in the main use cases.

Resources