SocialDataX 快手 Kuaishou MCP

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

The description adds the limitation '当前不支持翻页' (pagination not currently supported), which goes beyond the annotations (readOnlyHint, openWorldHint). This is useful behavioral context, though no other traits are disclosed.

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 sentences, first states purpose, second states limitation. No wasted words.

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 no parameters, an output schema present, and annotations covering read-only behavior, the description is sufficient for this simple list tool. It mentions the key pagination limitation.

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?

No parameters exist (schema has 0 properties), so the description is not required to explain parameter meanings. Baseline 4 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 explicitly states '获取快手短视频热榜' (Get Kuaishou short video hot list), which clearly defines the action and resource. It distinguishes from sibling tools by focusing on the hot search list, unlike user/profile/video/comment 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?

No explicit alternatives or when-not-to-use guidance. The '当前不支持翻页' (pagination not supported) is a limitation, not usage context. Usage is implied from the name and description.

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 discloses key behaviors: supports live and fw/user share links, returns a reusable non-empty user_id on success, and rejects work links. Annotations already cover read-only safety (readOnlyHint: true), so the description adds value by detailing the return value guarantee and input constraints. No contradiction with annotations.

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 a single, well-structured sentence that front-loads the purpose and flows logically through input types, success behavior, exclusions, and usage guidance. Every clause earns its place; 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?

For a simple one-parameter read-only tool with an output schema, the description covers all necessary context: input formats, supported link types, prohibited input, output behavior (non-empty user_id), and when to use an alternative. It is complete for the tool's 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 schema already provides 100% coverage for the single parameter profile_url, with the same detailed description of accepted formats and constraints. The tool description adds no new semantic information beyond what's in the schema, so the baseline 3 applies. It simply reinforces the 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 clearly states the tool's function: '根据快手用户主页链接、短链接或分享文案获取用户资料' (get user profile from profile URL). It specifies the exact input type (profile URL, short link, share text) and distinguishes from sibling tools by mentioning the user_id entry and excluding work links. This is a specific verb+resource with clear differentiation.

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 explicitly says '如果上一步结果已返回非空 user_id，可直接使用 user_id 入口', advising to use the user_id entry (sibling tool) when a non-empty user_id already exists. It also says '不要传作品链接' (don't pass work links), providing a clear exclusion. This is explicit when-to-use and when-not-to-use guidance with a stated alternative.

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 this as a read-only operation (readOnlyHint=true). The description adds the non-empty user_id constraint, which is useful but not a deep behavioral disclosure. There is no mention of error behavior, result shape, or access requirements beyond the annotations, so it meets baseline but does not exceed it.

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 a single, concise sentence that immediately states the tool's purpose. It is front-loaded and contains no filler, making it easy for an agent to parse quickly.

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 read-only lookup tool with one parameter, an output schema, and clear annotations, the description is sufficiently complete. The schema covers input constraints, and the annotation covers safety, so the description only needs to state the primary function, which it does.

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 the parameter is fully documented in the schema. The tool description adds no additional parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate because 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 clearly states the tool's function: fetching user profile data using a non-empty Kuaishou user_id. It specifies the resource ('user profile') and the identifier type ('user_id'), which distinguishes it from sibling tools that use profile URLs or other access methods.

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 and the schema together clarify when to use this tool: when a non-empty user_id is available, potentially from previous results. The schema explicitly warns against using it when user_id is an empty string. However, no explicit mention of alternative tools (like the profile URL variant) is provided, so it lacks explicit exclusions.

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, so the safety profile is covered. The description adds useful behavioral constraints beyond annotations: it only accepts profile links that directly resolve to a non-empty user_id, rejects work links, and defines the two-step behavior for live/fw-user pages. It does not detail error behavior, but this is not required given the schema and read-only annotation.

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 front-loaded with the main purpose and then packs routing and negative constraints into compact, semicolon-joined sentences. It is efficient overall, though it repeats some schema content, creating minor redundancy rather than waste.

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?

Given the tool's complexity, the description fully covers the selection criteria, the special live/fw-user routing, the forbidden input type, and the fallback to the user_id-based tool. With input schema covering pagination and output schema covering return values, nothing essential is missing for an agent to invoke this tool 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%, and the page_token semantics are fully documented in the input schema. The tool-level description largely restates the profile_url precondition already present in the schema, so it adds no significant new parameter-level meaning beyond what structured metadata already provides.

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 the tool's action ('获取公开作品列表') and resource ('快手用户主页链接、短链接或分享文案'), distinguishing it from the user_id-based sibling tool by explicitly routing to the user_id entrance when a user_id is already available. It also adds a clear negative constraint ('不要传作品链接'), making the tool's scope unmistakable.

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 gives explicit when-to-use guidance: direct profile URLs should be passed to this tool, while live/fw-user pages require first calling the user-profile entry and then using the returned user_id. It also states the alternative ('可直接使用 user_id 入口'), giving an agent a concrete routing rule instead of leaving it 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 provide readOnlyHint=true and openWorldHint=true, so the description does not need to state that it is a read operation. It adds useful context that the list is of public works and requires a non-empty user_id, but says nothing about rate limits, response behavior, or other operational traits beyond the 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?

The tool description is one concise sentence with the key condition front-loaded. The schema parameter descriptions are detailed but purposeful, with only minor redundancy around the 'non-empty user_id' requirement.

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-only tool with a full output schema and rich parameter descriptions, the definition is largely complete. It could be strengthened by an explicit note about when to choose the profile_url sibling, but nothing essential for calling 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 both parameters are richly documented, especially page_token with explicit handling rules. The main description adds little beyond what the schema already states, so the baseline of 3 is appropriate.

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 action ('获取公开作品列表') and resource (public video list for a Kuaishou user), which is clear and distinct from the profile-URL sibling by name and input type. It does not explicitly name the alternative sibling or the condition for choosing it, so it is not a 5.

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 schema description gives clear usage context: the user_id must be non-empty, can be reused from prior user/author results, and the tool should not be used when user_id is an empty string. This effectively states when to use it and when not to, though it does not explicitly point to the profile_url alternative.

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 provide readOnlyHint=true and openWorldHint=true, establishing safe read-only behavior and external dependencies. The description adds the constraint '不要传回复项的 comment_id' and the ID-completion workflow, but these are more about parameter semantics and usage rules than new behavioral context (e.g., rate limits, side effects). Thus, it adds minimal extra beyond annotations, warranting a 3.

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 a single, tightly-packed sentence (in Chinese) that front-loads the core purpose and then provides actionable rules. Every clause adds value, with no fluff or repetition. It is efficient and well-structured for an agent to parse quickly.

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?

Given the tool has an output schema, detailed parameter schema, and annotations (readOnly/openWorld), the description sufficiently covers the essential ID resolution workflow and cardinal rule about comment_id. It does not explicitly mention pagination behavior, but that is thoroughly documented in the schema for page_token. The only minor omission is lack of mention of error handling or invalid-ID scenarios, but those are often left to the system. Overall, it is complete for effective use.

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 detailed descriptions for all three parameters: photo_id derivation, comment_id (including the note about not using reply ids), and page_token (opaque, must reuse exactly). The description itself does not add new semantic detail beyond what the schema already states, only restating the comment_id constraint, so it earns the baseline score of 3.

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 the tool fetches comment replies given a photo_id and a first-level comment_id, and explicitly instructs not to pass reply-level comment_ids. This distinguishes it from sibling tools that retrieve first-level comments (kuaishou_get_video_comments_by_photo_id/by_url) and other video-focused tools, leaving no ambiguity about its specific function.

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 gives explicit when-to-use instructions: use directly when a complete valid ID pair is provided, call the appropriate first-level comment tool when IDs are missing, request work location info from the user when needed, and never pass a reply comment_id. It names the alternative tools implicitly ('一级评论工具') and provides clear decision logic, which is more than typical guidance.

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, which is fully consistent with the description's '获取' (get). The description does not contradict annotations and adds minimal context beyond them. It does not describe any side effects, rate limits, or special behavior beyond what annotations imply. With annotations covering the safety profile, a score of 3 is appropriate—it meets the minimum but does not enrich the behavioral picture further.

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 a single, front-loaded sentence in Chinese that conveys the core purpose without any wasted words. It is appropriately sized for a tool with simple parameters and a clear role, and the key information (what it gets and how) is placed first. This is exemplary conciseness.

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?

Given that an output schema exists and the parameter schema covers pagination details, the description's brevity is acceptable. It captures the essential function and distinguishes the scope (first-level comments). However, it could have explicitly mentioned that it returns a paginated list or that page_token handles continuation, but that information resides in the schema. Overall, it is sufficiently complete for an agent to call correctly, with only minor additional context possible.

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 (photo_id and page_token) are already documented in detail in the schema. The tool description adds no additional parameter meaning beyond the schema. Since the schema handles the parameter semantics adequately, the baseline of 3 applies. The description itself does not mention parameters, but the schema does the heavy lifting, so no penalty.

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 the action (获取 = get), the resource (快手作品 photo_id 的一级评论列表 = first-level comment list for a Kuaishou work by photo_id), and the specific parameter (photo_id). It distinguishes from siblings like kuaishou_get_video_comments_by_url (by URL) and kuaishou_get_video_comment_replies_by_comment_id (replies) by explicitly mentioning '一级评论' (first-level). This is a specific verb+resource statement that leaves no ambiguity about the tool's purpose.

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 does not provide any explicit guidance on when to use this tool versus alternatives like kuaishou_get_video_comments_by_url or kuaishou_get_video_comment_replies_by_comment_id. It only states what it does, leaving the agent to infer selection criteria from the parameter (photo_id) and the tool name. There is no mention of exclusions, prerequisites, or alternative conditions, which is a significant gap for an agent deciding among multiple comment-related tools.

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 include readOnlyHint=true, so the read-only nature is covered. The description adds that it returns first-level comments and warns against using user profile links, which is useful context beyond annotations. However, it does not disclose pagination behavior, rate limits, or error handling, leaving gaps that the schema partially fills.

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 concise, with a clear main action followed by a constraint and a usage tip. It is front-loaded and each clause serves a purpose, though it is slightly redundant with the schema's url description, keeping it from being perfectly tight.

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?

Given the tool has an output schema, read-only annotations, and well-documented parameters, the description is largely complete for its complexity. It clarifies the input form and scope (first-level comments) but does not elaborate on pagination flow or response structure, which are reasonably covered by the schema and output schema.

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 input schema already covers both parameters with detailed descriptions (url and page_token), achieving 100% coverage. The description's parameter-related content (preserve original URL, exclude user homepage) largely duplicates what the schema says, so it adds minimal new semantic value beyond the structured fields.

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 the tool's function: fetching first-level comments based on Kuaishou video links, short links, or shared text. It also provides a specific exclusion (user homepage links) and distinguishes from the photo_id-based sibling by emphasizing URL entry, making the purpose unambiguous.

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 gives explicit usage guidance: do not pass user homepage links, and when querying comments keep the original URL/text and use the URL entry. It does not explicitly name alternative tools (e.g., the photo_id variant), but the context and input constraints convey when this tool is appropriate.

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, so the safety profile is covered. The description adds useful behavioral context by stating the tool supports not only videos but also images and albums, which is not obvious from the tool name alone. There is no contradiction with the read-only annotation.

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 a single, front-loaded sentence that conveys the tool's core function and content-type scope without any filler. Every phrase earns its place.

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 one required parameter, a fully descriptive schema, read-only/open-world annotations, and an output schema present, the description is complete for an agent to select and invoke this tool correctly. Nothing critical 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%, providing the baseline of 3. The parameter description adds value by explaining when to use a directly provided photo_id versus reusing one from existing Kuaishou result data, which is more than a bare type definition.

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 ('获取'/'get') and resource ('快手作品 photo_id' details), and clarifies that it covers video, image, and album works. The 'by_photo_id' identifier in both name and description distinguishes it clearly from sibling tools like kuaishou_get_video_detail_by_url.

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 makes clear this tool is for retrieving details when a photo_id is available, and the parameter description adds practical guidance: use directly if the user provided it, otherwise reuse a photo_id from prior Kuaishou result data. It does not explicitly name alternative sibling tools or state when not to use it, but the context is clear.

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, indicating this is a safe read operation. The description adds context about the input types (link, short link, share text) and the content types (video or image/album), but does not disclose any other behavioral traits such as error handling, pagination, or rate limits. Given the annotation coverage, the description provides adequate but not exceptional behavioral disclosure.

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 concise, comprising two sentences that front-load the primary action, then state the exclusion and the alternative. Every sentence carries essential information without redundancy, and the structure is clean and easy to parse.

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?

Given there is an output schema (so return values are already defined), the description covers the key inputs and exclusions. It mentions the tool handles both videos and image/albums, and directs to the photo_id alternative, which is sufficient for a one-parameter read-only tool. Minor omissions like error behavior are not critical given the annotations and output schema.

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% — the 'url' parameter is fully described in the schema with the same text as the tool description. The description adds no additional meaning beyond what the schema already provides, so the baseline of 3 applies. It does not clarify format requirements or edge cases beyond the 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 clearly states that the tool retrieves video or image/album details from a Kuaishou work link, short link, or share text, and explicitly excludes user profile links. It also references the alternative photo_id-based entry point, which distinguishes it from the sibling kuaishou_get_video_detail_by_photo_id. This makes the purpose unambiguous and distinct.

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 gives explicit instructions: use this tool when you have a URL, and if you already have a photo_id, use the photo_id entry point instead. It also warns not to pass user profile links, which implies that user-related tools (e.g., get_user_info_by_profile_url) are for that purpose. These directives effectively route the agent to the correct tool among the many siblings.

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?

Beyond the readOnlyHint annotation, the description discloses the polling behavior (wait at most 240 seconds) and instructs not to resubmit, which are non-obvious and crucial for correct usage. No contradiction with annotations.

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 sentence that front-loads the purpose and includes usage guidance, waiting behavior, and a constraint. Every clause earns its place with no 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?

For a one-parameter tool with a rich schema description, output schema, and clear annotations, the description provides all necessary context: when to use, how long to wait, and what to avoid. Nothing essential 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?

The schema description for job_id already explains its meaning, sources, and what not to pass, covering 100% of the parameter. The tool description echoes this without adding new semantics, so baseline 3 is appropriate.

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 '查询' (query) and resource '快手视频口播转文字任务状态' (Kuaishou video speech-to-text task status), which clearly distinguishes it from sibling tools that query videos, users, or comments. It also signals it is a status-check tool for a previously submitted job.

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 tells the agent when to use this tool (when a valid job_id is available) and when to use an alternative (submit tool return value). It also warns against resubmitting and sets a maximum wait time, providing concrete decision criteria.

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?

注解已包含readOnlyHint=true，描述未与此矛盾并补充了分页支持，但未提供更多行为细节（如返回结构、结果排序等）。由于注解已覆盖安全性，描述增加的内容有限，评分中规中矩。

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?

描述紧凑，两个句子传递了核心用途、排除条件和使用场景，信息密度高且无冗余。

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?

工具仅有2个参数且描述清晰，输出schema存在无需额外说明返回格式。描述覆盖了主要使用场景和翻页机制，但未提及返回字段或排序，在存在输出schema的情况下完整度足够。

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覆盖100%，参数keyword和page_token均有详细描述。描述本身重复了schema中的约束（keyword不要传链接等），未提供超出schema的额外语义，因此评分基于schema覆盖率的基准3。

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?

使用明确的动词"搜索"和资源"快手用户"，并清晰说明了用途：按搜索词查找用户。同时明确区分了与已有用户主页链接或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?

描述明确指出何时使用（按搜索词查找用户）和何时不使用（已有用户主页链接或user_id时改用对应用户资料或用户作品列表工具），并列出了keyword的禁止输入类型，提供了明确的替代路径。

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 annotations already establish read-only and open-world behavior. The description adds meaningful behavioral context beyond that, such as support for page_token pagination and the fact that searching is unnecessary when a direct identifier is already available. There is no annotation contradiction.

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 a single focused sentence with semicolon-separated clauses that front-load the purpose, then cover input restrictions, alternative routing, and pagination. There is no redundant or filler content.

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, the description fully covers when to use it, what to pass, what not to pass, which alternatives to choose, and how to paginate. Return format is not needed because an output schema exists.

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 the baseline is 3. The top-level description restates the keyword constraint and mentions pagination, but it does not add meaning beyond what the schema already documents for keyword and page_token.

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 starts with the specific action and resource: '搜索快手作品' (search Kuaishou videos), and states the trigger condition '用户需要按搜索词查找作品时使用'. It clearly differentiates from sibling tools like kuaishou_search_users and the detail/comment tools by restricting input to a search term rather than IDs or URLs.

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 explicit when-to-use guidance: only when searching by keyword. It also states exclusions: do not pass links, photo_id, or user_id, and says that if these identifiers already exist, the agent should directly use the corresponding detail or comment tools instead of searching first.

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 valuable behavior beyond annotations: it discloses a 240-second wait and the fallback of returning job_id when incomplete, along with pointing to a next query action. Annotations already indicate it's non-read-only and non-idempotent, so the description complements rather than repeats.

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 a single concise sentence that packs the core action, timeout, and fallback behavior without fluff. It is appropriately short 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?

The description covers the essential invocation semantics: how to submit, the wait, and the fallback job_id. With an output schema present and the sibling getter tool listed, the agent has enough context. It could explicitly mention the sibling for URL-based submission, but that's a minor omission.

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%, with the photo_id parameter described in the schema as '快手作品 photo_id；用户已提供时直接使用，否则可从包含 photo_id 的快手作品结果中复用', which provides sourcing guidance. The tool description itself adds nothing about the parameter, but since the schema covers it, the baseline 3 suffices.

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 the action: submitting a video speech-to-text task based on photo_id. It uses a specific verb (提交) and resource (视频口播转文字任务), and the photo_id basis distinguishes it from the sibling tool that uses video_url.

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 implies usage when a photo_id is available and mentions reuse from results, but it does not explicitly contrast with the sibling tool for video URL submission or the job query tool. The agent must infer from sibling names rather than receive direct routing guidance.

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 indicate this is not read-only, not idempotent, and not destructive. The description adds specific behavior: it waits up to 240 seconds and returns a job_id if incomplete, along with a next query action. This is valuable context beyond annotations, but it doesn't cover error cases, side effects, or what the job_id represents. Adequate but not rich.

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 a single sentence that front-loads the core action, then communicates the async behavior and result handling. Every word earns its place; there is no redundancy or filler. Excellent conciseness and structure.

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 an asynchronous submission tool with a follow-up query step, the description mentions the next action but stops short of naming the specific tool (e.g., kuaishou_get_video_speech_text_job). It also omits error scenarios or what triggers failure. Given an output schema exists and the tool is relatively simple, it's partially complete but leaves an agent to guess the exact workflow.

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 description of video_url is detailed (types of links, exclusion of profile links, alternative photo_id entry). The tool description itself adds no additional parameter semantics, so it relies entirely on the schema. Baseline 3 is appropriate given the high schema coverage.

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 the action (submit a video speech-to-text task) and the resource (via video URL). It's direct and unambiguous. However, it doesn't explicitly distinguish itself from the sibling kuaishou_submit_video_speech_text_by_photo_id, so it loses a point for not aiding sibling differentiation.

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?

There is no explicit statement of when to use this tool versus alternatives. It implies the next step (query) but doesn't name kuaishou_get_video_speech_text_job, nor does it contrast with the photo_id version. An agent must infer usage context from the schema description of video_url, which mentions using photo_id if available. This is insufficient guidance.

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?

Read-only behavior is already covered by readOnlyHint=true, and the description aligns with it by using '查询' (query). It adds the useful nuance that the balance applies to the current API key account, which is not in the annotations. No side effects or edge cases are mentioned, but for a simple balance query this is acceptable given the annotations.

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 that is front-loaded with the action and resource, containing no extraneous words. It includes both Chinese and English for clarity without redundancy, making it both concise and informative.

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?

Complete for a zero-parameter, read-only tool. An output schema exists, so return format is presumably specified there, and the description need not repeat it. All information an agent needs to call the tool correctly—its purpose and the scope (current API key)—is present.

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, so schema coverage is trivially 100%. The description has no need to elaborate on parameters, and the baseline of 4 for zero-parameter tools applies. The description correctly omits parameter details.

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 (查询/query) and resource (SocialDataX points balance) for the current API key account. Clearly distinguishes from all sibling tools, which are Kuaishou data retrieval operations, leaving no ambiguity about its function.

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?

No explicit when-to-use or alternatives are provided. The purpose is self-evident as a balance check, but there is no guidance on when it should be invoked (e.g., before consuming API calls) or any context about the current key being the active one. Usage is implied rather than stated.

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