SocialDataX YouTube MCP

youtube_get_video_comment_replies

Read-only

根据 reply_token 获取 YouTube 评论回复；用户已提供有效 reply_token 时直接使用；已有 YouTube 视频链接但缺少 reply_token 时，调用 youtube_get_video_comments_by_url 获取一级评论；缺少视频定位信息时向用户索取；不要传一级评论或回复项的 comment_id；支持 page_token 翻页。

Input Schema

TableJSON Schema

Name	Required	Description	Default
`page_token`	No	YouTube 评论回复分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一 reply_token 对应的评论回复续页；更换 reply_token 时，请清空 page_token 后从第一页重新读取评论回复。继续翻页时，reply_token 仍传同一条一级评论的原始 reply_token，同时把上一页返回的完整 next_page_token 原样作为 page_token 传回。
`reply_token`	Yes	读取某条 YouTube 视频一级评论回复所需的不透明令牌；用户已提供时直接原样使用；否则从 youtube_get_video_comments_by_url 返回的 items[*].reply_token 原样复制。只有有效且非空的 reply_token 才调用本工具；不要传 comment_id、video_url、video_id、频道链接、播放列表链接或搜索页链接。

Output Schema

TableJSON Schema

Name	Required	Description
`items`	Yes	当前页 YouTube 评论回复列表；当前页可能为空，是否可继续翻页以 next_page_token 是否为空为准。
`points`	Yes	本次成功调用的积分消耗与调用完成时的账户积分余额。
`next_page_token`	Yes	下一页评论回复不透明分页令牌；为空表示没有更多评论回复。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回；只用于同一 reply_token 对应的评论回复续页；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成。

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds behavioral context beyond annotations: it specifies pagination support, the requirement to preserve reply_token untouched, and the routing behavior to the sibling tool. It does not discuss errors or rate limits, but those are not critical gaps.

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 a single dense paragraph of semicolon-separated directives, purpose first, followed by routing rules and exclusions. It is efficient but packs several conditions together, making it slightly less scannable than a short structured list would be.

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 tool with rich schema descriptions, output schema present, and sibling context, nothing essential is missing. The description covers the main workflow, the relationship to youtube_get_video_comments_by_url, user interaction when location info is missing, and pagination constraints.

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?

Schema description coverage is 100%, so the heavy lifting is already done by the schemas for reply_token and page_token. The description still adds value by telling the agent where reply_token comes from (items[*].reply_token from the sibling tool), when to reset page_token, and which identifiers not to pass.

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 opens with a specific action and resource: '根据 reply_token 获取 YouTube 评论回复' (get YouTube comment replies by reply_token). It also explicitly distinguishes itself from the sibling youtube_get_video_comments_by_url by stating when that sibling should be used instead, and clarifies that comment_id must not be passed.

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?

Usage conditions are explicit: use directly when a valid reply_token is provided, call youtube_get_video_comments_by_url when only a video link exists, ask the user for missing video identification, and never pass comment_id. This fully covers when, when-not, and alternatives.

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

All SocialDataX YouTube MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Most tools target clearly distinct resources and actions: points, channel info, channel videos, video detail, comments, replies, search, and speech-text jobs. The two submit speech-text tools (by URL vs by video ID) are similar but differentiated by input type, so they are not truly ambiguous.

Naming Consistency5/5

Tool names consistently follow a snake_case verb_object_by_input pattern, with a service prefix. Even longer names like youtube_get_user_posted_videos_by_channel_url are predictable and parallel to other URL-based getters.

Tool Count5/5

Ten tools is a well-scoped size for a YouTube data access server. Each tool covers a distinct operation or async workflow step without feeling bloated or sparse.

Completeness4/5

The set covers the core YouTube read workflows well: channel info, channel videos, video details, search, comments, replies, and async speech-text extraction. Minor gaps exist, such as no direct tool for fetching all replies without a reply_token and no explicit channel info by video ID, but the provided flow works around these.

Resources

Need Help?