douyin-ops-mcp

Overview Schema Source Related Servers Discussions Admin

douyin_comments

Fetches a Douyin post's comments with likes, author-reply flags, IP locations, and top sub-replies to uncover user needs, content ideas, and potential customers to engage.

Instructions

读一条作品的评论区（含点赞数、作者回复标记、IP 属地、前 3 条二级回复）。用来抓用户真实需求、找选题、找可以互动的潜在客户。

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": {
      "target": "<target>"
    },
    "name": "douyin_comments"
  }
}

Input Schema

Name	Required	Description
`count`	No	条数（默认 20）
`cursor`	No	翻页游标
`target`	Yes	作品链接或作品 ID

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations carry only a title, so the description carries the burden, and it does disclose the response shape (like counts, author-reply flags, IP region, first 3 nested replies) and implies a read-only operation. It omits authentication requirements (login), rate limiting, whether pagination is exhausted via cursor, and how many comments exist in total.

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?

Two short sentences with the core action front-loaded and no filler. The second sentence is useful context but does not help select the tool, so it is not fully earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, listing the returned fields is valuable, but for a paginated comment reader the description does not explain paging (cursor/count interaction), reply expansion limits, or its relationship to the comment-replies and comments-list siblings.

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 the baseline is 3. The description adds only marginal meaning, suggesting count governs top-level comments while nested replies are capped at 3, but it never explains cursor behavior or the accepted formats for target beyond the schema's own note.

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 states a specific verb and resource ("读一条作品的评论区") and enumerates the returned fields (点赞数、作者回复标记、IP 属地、前 3 条二级回复). However, it never distinguishes itself from the close siblings douyin_comments_list and douyin_comment_replies, which an agent could easily confuse with it.

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

Usage Guidelines2/5

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

The second sentence gives motivations (抓用户真实需求、找选题、找潜在客户) rather than conditions for choosing this tool. There is no guidance on when to prefer douyin_comments_list or douyin_comment_replies, no pagination/cursor advice, and no prerequisites.

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