SocialDataX 好看视频 Haokan MCP

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 that results are paginated and that the ID must be a top-level comment rather than a reply's own ID, but both of those facts are also spelled out in the schema's field descriptions, so the incremental behavioral value beyond structured data is modest and it says nothing about ordering or result size.

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?

A single front-loaded sentence that leads with the operation and parameters, then adds the sibling reference as a semicolon clause. There is no filler, though the semicolon-joined tail packs three separate ideas and would read slightly better as two clauses.

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?

The tool is a read-only paginated list with a complete input schema, full annotation coverage, and an output schema, so the description does not need to explain return values. Purpose, identifier provenance, pagination, and the alternative entry point are all present, leaving nothing an agent needs in order to call it correctly.

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 description coverage is 100%, with url, comment_id and page_token each documented in detail, including the expected URL format and the continuation-token contract. The description restates the provenance of comment_id but adds no syntax, format, or edge-case information the schema does not already contain, so it sits at the baseline for a fully documented schema.

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?

The description names a specific verb and resource (读取完整回复列表 / read a complete reply list) plus the two identifiers it keys on (video page URL and top-level comment ID), so the agent knows exactly what the call returns. It also names the sibling entry point haokan_get_comment_replies_by_video_id, making it distinguishable from the near-duplicate tool without opening a schema.

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 where comment_id comes from (the video comment list) and points at the alternative entry point for the video-ID path, which tells the agent how to pick between the two near-identical siblings. It stops short of an explicit rule such as 'use this tool when you have a URL, otherwise use the video_id variant', leaving the selection slightly inferential.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and scope are covered structurally. The description adds that results are paginated and that the list is 'complete', but the actual paging mechanics are documented in the schema's page_token, so the added behavioral content is thin. It says nothing about ordering, maximum page size, or what happens with an expired token.

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?

A single sentence, front-loaded with the action and required keys, followed by the sibling routing note. No padding 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.

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

With full schema coverage, explicit annotations, and an output schema, the description only needs to add entry-point routing and pagination awareness — both present. It is slightly thin on the prerequisite chain (you must first call the video-comments tool), which an agent must infer from 'comment_id 取视频评论列表'.

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 description coverage is 100%, so all three parameters are already well documented, including the warning not to pass a reply's own ID. The description's note that comment_id comes from the video comment list duplicates the schema rather than extending it. Baseline 3 applies when the schema does the heavy lifting.

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?

The description states a specific verb (读取) and resource (完整回复列表) plus two identifying keys (video ID, 一级评论 ID), and explicitly distinguishes this entry point from the sibling haokan_get_comment_replies_by_url. An agent can tell it apart from the URL-based 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.

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

It routes the agent: comment_id must come from the video comment list, and the URL-based alternative is named for the other entry path. What is missing is an explicit statement of when to prefer this over by_url (i.e., only when you already hold numeric IDs) — the implication is clear but not spelled out.

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

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

Annotations already cover the read-only and open-world profile, and the description adds scope constraints beyond them: no pagination (so the agent should not attempt page/offset arguments) and no hot-video payloads. It does not discuss freshness, region, or rate limits, but for a zero-parameter read that is a minor gap.

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?

A single front-loaded sentence with a semicolon-delimited scope exclusion; every clause carries information and nothing is redundant. The positive capability is stated before the limitations, which is the right ordering.

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?

For a zero-parameter read with an output schema already documenting return shape, the description covers what is fetched and what is explicitly out of scope. Only secondary operational context such as data freshness or regional scoping is absent, which is minor at this complexity.

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?

The tool takes no parameters, so the baseline is 4; there is nothing for the description to clarify beyond the useful note that pagination is unsupported. The schema already enforces additionalProperties=false with an empty property set.

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?

States a specific verb and resource — retrieves Haokan Video's current search hot words together with their heat values — and preempts the most likely confusion by declaring it does not return hot video lists. An agent can distinguish it from haokan_search_videos and haokan_search_suggestions without opening any schema.

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?

Usage is implied by the resource description (call it when trending search terms are needed), and the negative clause hints that a different tool covers hot videos. However, no sibling is named as an alternative and no explicit when-not condition is given, so the routing is left partly to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description still earns credit for disclosing return scope (no posted-videos list), which is a behavioral fact not expressed in the annotations or input schema.

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?

Three short clauses separated by semicolons: what it does, when to pick the sibling, and what is out of scope. Front-loaded with the action, zero filler.

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?

A single required parameter fully documented in the schema, an output schema that carries return values, and annotations covering safety and openness leave nothing an agent needs missing. The description's only job, disambiguation, is done.

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 the schema's url description already specifies the https://haokan.baidu.com/author/{id} format plus where to source profile_url values. The description's '按用户主页链接' adds no meaning beyond that, so the baseline of 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?

Names a specific verb+resource combination (fetch user profile by homepage URL) and immediately scopes it against the sibling that takes a user ID. Adding that it does not return a works list further separates it from haokan_get_user_posted_videos_by_profile_url without either schema being opened.

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?

Explicitly states the selection rule: use this when you have a profile URL, and switch to haokan_get_user_info_by_user_id when you only have an ID. The exclusion of works is implied rather than routed to the sibling that does return them, so the guidance is strong but not exhaustive.

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

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

The readOnlyHint annotation already establishes this is a safe read, so the description only needs to add scope context — and it does, by disclosing that the profile response excludes the user's works list, preventing a wrong-tool selection. It says nothing about missing users, rate limits, or ID-format failure behavior, which keeps it below a 5.

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?

One compact statement with three clauses: purpose first, ID sourcing second, sibling routing third, scope exclusion last. No filler, no repetition of the tool name as a sentence, and the most decision-relevant information is front-loaded.

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?

For a single-parameter read-only lookup with a 100%-covered schema and an output schema that documents the return shape, the description covers everything an agent needs: what it returns, how to obtain the input, and which sibling to use instead. Nothing material is missing at this complexity level.

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 description coverage is 100%, and the user_id schema entry already documents the accepted sources (search results, video detail, comment authors) and the alphanumeric format in more detail than the description. The description's 'ID 可从用户搜索结果获取' is a subset restatement, so the baseline 3 is correct.

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?

The description uses a specific verb + resource (获取好看视频用户资料) qualified by the keying dimension (按用户 ID), and explicitly names the sibling it is not (haokan_get_user_info_by_url) plus the scope boundary (不返回作品列表), which also separates it from haokan_get_user_posted_videos_by_user_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 where to source the ID (用户搜索结果) and gives an explicit routing rule to haokan_get_user_info_by_url when a homepage link is held, which is strong when-to-use guidance. It stops short of saying directly 'use haokan_get_user_posted_videos_by_user_id to get works' — that alternative is only implied by the negative scope statement.

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

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 useful behavioral context: the tool supports pagination and rejects video links as input. It does not spell out what the returned list contains, but an output schema exists to carry that, so this is a modest gap rather than a serious one.

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?

A single dense sentence with the verb and resource front-loaded, followed by pagination support and the sibling routing hint. Nothing is redundant, though the clause order packs the disambiguation before the alternative is introduced, which is slightly less scannable than splitting it into two sentences.

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?

With only two parameters, 100% schema coverage, an existing output schema, and annotations covering the safety profile, the description supplies what's needed: correct input type, pagination behavior, and routing to the ID-based sibling. The return shape is left to the output schema, which is appropriate.

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 description coverage is 100%, so both parameters are fully documented in the schema, including the pagination token's continuation semantics and the profile_url format. The description only adds the negative 'don't pass a video link' hint, which the schema does not state, so it adds some meaning but the baseline of 3 applies when the schema does the heavy lifting.

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?

The description begins with a specific verb+resource pair ('按用户主页链接获取…用户发布视频列表' — get a user's posted video list by profile URL), states the scope, and explicitly distinguishes it from the sibling that takes a user ID. An agent can tell it apart from haokan_get_user_posted_videos_by_user_id 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.

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

It names the alternative tool and the exact condition that selects it ('已有用户 ID 时使用 haokan_get_user_posted_videos_by_user_id'), and adds a negative constraint ('不要传视频链接' — don't pass a video link), which covers a likely confusion with the *_by_url video tools. Both when-to-use and when-not-to-use are explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the read-only, external-data nature is known. The description adds that results are paginated, which is useful context beyond the annotations, but says nothing about ordering, rate limits, or empty-result behavior. With annotations covering the safety profile, a 3 is appropriate.

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?

One short sentence with the core action front-loaded, followed by the disambiguating routing clause. No filler or redundant restatement of the title.

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?

For a two-parameter read tool with full schema coverage, annotations, and an output schema, the description covers what is needed to call it correctly and when to prefer the sibling. Only the alternate ways of obtaining a user_id are left unstated.

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 description coverage is 100%, and the schema already documents user_id sources, the allowed pattern, and the page_token continuation rule in more detail than the description. The mention of 分页 merely echoes the page_token parameter, so baseline 3 is correct.

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?

States a precise verb and resource (retrieve the list of videos posted by a Haokan user, keyed by user ID) and explicitly names the sibling variant that takes a profile URL. An agent can select between the two 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.

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

Gives a clear routing rule: use the profile_url sibling when holding a user homepage link, and this tool otherwise. It does not spell out the other common entry point (searching users first, or deriving user_id from a video/comment author), which the schema mentions but the description leaves implicit.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds real behavioral context by stating that only top-level comments are returned, that replies are preview-only, and that pagination is supported. That replies caveat is the kind of expectation-setting detail annotations cannot convey. It does not mention rate limits or paging depth, so it is not exhaustive.

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 short clauses: the primary behavior and scope come first, then the input-mode alternative. Nothing is padded and every sentence carries load.

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?

For a two-parameter read tool with an output schema and readOnly annotations, the description covers input mode, pagination, and the reply-preview limitation. Minor gaps remain, such as page size or whether the URL must come from search results (the schema hints at share_url but the description does not reinforce it).

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?

With 100% schema description coverage, both url and page_token are already fully documented in the schema, including the format and the next_page_token round-trip rule. The description's '支持分页' only echoes the schema rather than adding format or constraint detail. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource (read top-level comments) plus a scoping constraint (by video page URL) and explicitly points to the sibling that handles the other input mode. An agent can distinguish this from haokan_get_video_comments_by_video_id 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.

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

The final sentence names the alternative tool and the condition that selects it (video-ID input), which is exactly the disambiguation an agent needs among the haokan_* siblings. It stops short of covering when-not-to-use cases such as reply retrieval, which the sibling name implies but the text does not state.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds substantive behavior beyond that: results are paginated, only first-level comments are returned, and any included replies are a preview rather than the full reply set. It does not discuss rate limits or ordering, but the key expectation-setting (scope of returned comments) is present.

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 short clauses: the capability and scope first, then the alternative-input pointer. Every clause carries information — no filler, no repetition of the title.

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?

For a simple two-parameter read tool with full schema coverage, read-only annotations, and an output schema, the description covers the essentials: what is returned, pagination, and the URL-based alternative. The only minor omission is not naming the replies tool needed to expand the previewed replies.

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 description coverage is 100%, and both parameters are documented in-schema with format, pattern, and pagination-token semantics. The description adds nothing about parameter handling beyond restating 'by video ID' and 'supports pagination', so the baseline of 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?

States a specific verb+resource: reading top-level (一级) comments of a Haokan video by numeric video ID, with pagination. It also explicitly names the sibling haokan_get_video_comments_by_url and the differentiator (URL input vs video ID), so an agent can pick between them without inspecting schemas.

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?

Gives a clear routing rule: use this tool when you have a video ID, and use haokan_get_video_comments_by_url for the URL-based input. It also signals that bundled replies are preview-only, hinting at the replies tools, though it never names haokan_get_comment_replies_by_video_id as the follow-up for full replies.

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

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

The description adds useful behavior beyond the readOnlyHint/openWorldHint annotations: it says the playback address may expire, which tells the agent not to cache or reuse it. It does not describe rate limits, failure modes for dead links, or region restrictions, so it stops short of full transparency.

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?

One compact sentence plus one caveat clause, with the output contents and the disambiguation rule front-loaded and zero filler. Every clause adds information an agent needs.

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?

Because an output schema exists, return values do not need explaining, and the description covers input form, sibling routing, and the expiry caveat. It is close to complete for a single-parameter read tool, with only edge-case failure behavior omitted.

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 the schema description already specifies the URL format and mentions share_url as a source, so the description adds no parameter meaning beyond the schema. A baseline 3 is appropriate here.

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?

The description uses a specific verb and resource ("读取好看视频详情、播放地址和作者摘要") and names the sibling it is not (haokan_get_video_detail_by_video_id). An agent can distinguish this URL-based variant from the ID-based one 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.

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

It gives an explicit selection rule: use this tool when you have a page link, and switch to haokan_get_video_detail_by_video_id when you only have a video ID. The condition and the alternative are both stated.

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

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 genuinely useful behavioral context beyond that: what the response contains (detail, playback address, author summary) and the caveat that the playback address may expire, which affects whether the agent should re-fetch.

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?

A single compact statement that front-loads the core capability, then the sibling disambiguation, then the expiry caveat. No redundant restatement of the name or title.

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?

For a one-parameter read tool with an output schema and read-only annotations, the description covers purpose, the sibling choice, and the one non-obvious operational risk (expiring playback URL). Nothing an agent needs in order to call it correctly is missing.

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 description coverage is 100% and the video_id property already documents the numeric-string format, an example, and where to obtain it from search results. The description adds nothing about the parameter beyond the schema, so the baseline of 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?

The description names a specific verb and resource ('按视频 ID 读取好看视频详情、播放地址和作者摘要') and explicitly distinguishes itself from the URL-based sibling, so an agent can pick the right tool 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.

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

It gives an explicit routing rule: when you hold a page link, use haokan_get_video_detail_by_url instead. That covers the main ambiguity against the sibling, but there is no guidance on prerequisites or on what to do when the ID is unknown.

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

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

Annotations already establish readOnlyHint and openWorldHint, so the bar is lower; the description still adds meaningful behavior beyond them by declaring that no video/user results are returned and that pagination is unsupported. That 'no pagination' constraint is the kind of trait an agent would otherwise assume wrongly for a search tool.

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?

One compact sentence with the primary action front-loaded, followed by the two exclusion clauses. No filler, and each clause carries operative 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?

For a one-parameter, read-only suggestion endpoint with annotations and an output schema, the description covers what an agent needs: purpose, exclusions, and no pagination. Only minor extras such as result language or typical suggestion count are absent.

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% for the single parameter, and the schema description already forbids links and pagination tokens. The description only restates the keyword's expansion purpose, adding little meaning beyond the schema, so the 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?

The description pairs a specific verb and resource ('获取好看视频搜索联想词') with explicit negative scoping ('不返回视频或用户结果'), which directly distinguishes it from siblings like haokan_search_videos and haokan_search_users 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.

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

It clearly states the use case ('用于补全或扩展关键词') and rules out the search-result interpretation, implicitly routing result queries to the search_videos/search_users siblings. It stops short of naming those alternatives explicitly, so it is 4 rather than 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds the useful detail that results are user summaries and that the tool paginates. It does not discuss result caps, ordering, or rate limits, but with annotations plus an output schema the remaining burden is low.

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?

A single front-loaded sentence covering purpose, return shape, pagination, and the exclusion. No filler or redundancy.

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?

With annotations covering the safety profile, an output schema covering return values, and full schema descriptions for both parameters, the description supplies everything essential for a search tool. Only the explicit sibling routing could be tightened.

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 description coverage is 100%, and the schema itself already spells out keyword semantics and the strict page_token round-trip rules. The description adds nothing about parameter meaning beyond that, 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?

States a specific verb (搜索) and resource (好看视频用户、账号或创作者), plus what is returned (用户摘要) and that pagination is supported. The closing clause "不用于搜索视频" explicitly distinguishes it from the sibling haokan_search_videos.

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?

The negative clause "不用于搜索视频" gives a clear boundary against the most likely confusion, so an agent knows to route video queries elsewhere. It stops short of naming the alternative tool or explaining when to use this instead of the URL/user-id lookup siblings, which is a minor gap.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds value beyond them by saying results are video summaries and that paging is supported, which tells the agent this is a discovery surface rather than a detail fetch. It doesn't mention result volume or ordering, but the output schema covers return shape.

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 compact clauses with the capability stated first and the exclusions second; almost no waste. The semicolon-joined density is slightly terse but remains readable and front-loaded.

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?

For a two-parameter read-only search tool with full schema coverage, annotations, and an output schema, the description covers what it does, what it returns, and what it is not for. No critical gap remains for correct invocation.

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 the schema already explains both keyword and page_token in detail, including that tokens must be passed back unmodified for the same keyword. The description only implies keyword search and pagination, adding essentially nothing beyond the structured fields, so the 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?

States a specific verb and resource ('按关键词搜索好看视频'), plus what it returns ('视频摘要') and that it supports pagination. The second clause explicitly excludes video-detail-by-URL and user lookup, which separates it from haokan_get_video_detail_by_url and haokan_search_users.

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?

Gives a clear positive condition ('用于查找视频') and explicit exclusions (reading detail of a specific video URL, finding users), which routes the agent to the right sibling family. It stops short of naming the exact alternative tools, so an agent still has to map 'find users' to haokan_search_users itself.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces that this is a read-only balance query. It adds useful context by tying the balance to the current API Key and pointing to the billing dashboard for recharges. No contradictions or hidden side effects are indicated.

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?

The description is two short sentences: the first states the core purpose, and the second provides an actionable billing link. Every word earns its place without unnecessary detail.

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?

For a zero-parameter, read-only balance query with an output schema, annotations, and a billing link, the description is fully sufficient. No additional information is needed for an agent to select and invoke it correctly.

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?

The tool has zero parameters Belarusand schema coverage is 100%, so parameter semantics are not a burden on the description. The description still adds value by explaining what the returned balance represents.

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?

The description clearly states a specific action (query) and resource (current API Key account's SocialDataX points balance), including Chinese and English terms. It is unambiguous and obviously distinct from the YouTube-focused sibling tools.

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?

The description identifies the exact context: querying the balance for the current API Key accounttons. It also provides a relevant follow-up URL for recharging. There are no competing sibling tools for balance checking, so no explicit alternatives are needed.

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