按视频页面链接读取好看视频一级评论，支持分页；附带的回复仅为预览。另一种输入使用 haokan_get_video_comments_by_video_id。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 好看视频页面链接，格式为 https://haokan.baidu.com/v?vid=数字ID，可取视频搜索结果的 share_url。 | |
| page_token | No | 分页令牌，首次留空；续页原样传回 next_page_token，保持同一视频。 |
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | 当前页一级评论，保持平台顺序。 | |
| points | Yes | 本次成功调用的积分消耗与调用完成时的账户积分余额。 | |
| comment_count | Yes | 平台展示的评论总数，不等于当前页一级评论数量。 | |
| next_page_token | Yes | 下一页分页令牌；为空表示没有下一页。 |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint/openWorldHint, it discloses two behavioral traits that matter: results are paginated, and any attached replies are only previews (not full reply data). It does not mention rate limits or auth, but the pagination and reply-preview semantics are the key operational facts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight clauses: scope/pagination/preview first, then the alternative-tool pointer. No filler, front-loaded, and every clause carries actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation; the description supplies the remaining essentials — pagination behavior, preview-only replies, and the by_video_id alternative. Only minor gaps (e.g. what determines a valid URL, reply-tool routing) remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters (url, page_token) are documented in the schema, including the next_page_token round-trip. The description only echoes that pagination is supported, adding no syntax or format detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: reads Haokan video first-level comments from a page URL. It scopes the result (first-level only, replies are preview only) and explicitly names the sibling that handles the other input form, haokan_get_video_comments_by_video_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the input-context condition clearly: use this when you have a page link, and use haokan_get_video_comments_by_video_id for the other input. It lacks explicit when-not-to-use guidance (e.g. whether replies require the dedicated replies tool), but the routing is mostly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.