SocialDataX 快手 Kuaishou MCP

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

Annotations already declare readOnlyHint and openWorldHint. Description adds the pagination limitation, which is useful but minimal beyond 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?

Two short, efficient sentences with no redundant information, each earning 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?

For a zero-parameter, read-only tool with output schema and annotations, the description adequately covers purpose and a key 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, so the description need not explain them. The existence of an output schema compensates for lack of return value description.

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?

Clearly states verb '获取' (get) and resource '快手短视频热榜' (Kuaishou short video hot list), distinguishing it from sibling tools focused on user info, videos, and comments.

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?

Indicates it's for getting the hot list and explicitly notes lack of pagination support. While it doesn't list alternatives, the sibling set makes the tool's role obvious.

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 description correctly aligns with a safe read operation. It adds value by disclosing that the tool returns a '可复用的非空 user_id' (reusable non-null user_id), which is helpful for downstream steps. No contradictions.

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 clear, front-loaded sentences with no redundancy or extra information. Every sentence serves a purpose: defining the tool, listing supported inputs, stating output, and giving usage guidance.

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 one parameter, explicit input restrictions, output schema exists (not shown), and close sibling alternatives, the description is complete. It covers what the tool does, what inputs to avoid, what to expect as output, and when to switch to a different tool.

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% (parameter description mirrors tool description). The tool description clarifies valid input types (live主页, fw/user链接) and explicitly forbids '作品链接' (video links), adding context beyond the schema's generic description. This aids correct parameter selection.

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 verb '获取' (get) and the resource '用户资料' (user info) from a profile URL. It specifies supported URL types and explicitly excludes '作品链接' (video links), distinguishing it from sibling tools that operate via user_id or other inputs.

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?

Provides explicit guidance on when to use this tool versus alternatives: '不要传作品链接' (do not pass video links) and '如果上一步结果已返回非空 user_id，可直接使用 user_id 入口' (if previous step returned non-null user_id, use the user_id entry instead). This directs the agent to an alternative sibling tool.

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. Description adds no additional behavioral context beyond basic function. No disclosure of error handling or data freshness.

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?

Description is one sentence with no wasted words. Additional context in parameter description is helpful but could be integrated for better 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?

With output schema present and simple single-parameter input, the description sufficiently covers the tool's purpose. Lacks mention of output format or error states, but output schema compensates.

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 covers parameter fully, but description adds valuable guidance: reusing user_id from previous results and warning against using empty user_id strings.

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?

Description clearly states '获取用户资料' (get user profile) using a non-empty user_id. Distinguishes from sibling tools like kuaishou_get_user_info_by_profile_url which use a profile 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?

Implies usage when user_id is available, but does not explicitly state when not to use or provide alternative suggestions. No exclusion criteria mentioned.

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 readOnlyHint and openWorldHint. Description confirms it returns public works and explains input restrictions. Does not contradict annotations, but adds moderate behavioral context beyond them.

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 paragraph but efficiently covers purpose, conditions, and alternatives. It is front-loaded with the main action. Slightly dense but still concise for the information provided.

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 output schema exists, description is complete. It covers input semantics, usage constraints, and alternative workflows. No gaps for selecting or invoking the 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 coverage is 100%, but description adds significant value: for page_token, it explains proper usage (first request empty, subsequent copy full token, no modifications); for profile_url, it describes acceptable link types and when to use alternatives.

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 it gets a list of public works (videos) from a Kuaishou user's profile URL that can parse a non-empty user_id. It explicitly distinguishes from the sibling tool by advising to use the user_id entry if already available.

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?

Provides explicit when-to-use (profile URLs that directly parse user_id), when-not-to-use (work links, live/fw-user links without prior user info call), and alternatives (use user_id entry or call user info 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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds no further behavioral context (e.g., rate limits, data freshness, pagination limits). Since annotations cover 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?

The description is a single sentence that is concise and front-loaded with the essential action. No unnecessary words or repetition; every word 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?

Given that output schema exists and parameter schema is thorough, the description is minimally adequate. However, it could benefit from mentioning that it only retrieves public videos or clarifying the scope of the list.

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 parameter descriptions for user_id and page_token. The tool description adds no additional meaning beyond the schema, meeting 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 specifies the verb '获取' and resource '公开作品列表', and distinguishes from the sibling tool 'kuaishou_get_user_posted_videos_by_profile_url' by emphasizing using non-empty user_id. It is clear and specific.

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 user_id is known (versus profile_url), but does not explicitly state when to use or avoid this tool, nor mention alternatives. Guidance is only implied.

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. The description adds no additional behavioral context beyond the read operation. It doesn't mention rate limits, authentication, or other effects, but annotations suffice.

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, clear sentence is concise and front-loaded. It effectively communicates the core function without unnecessary 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?

Given the presence of an output schema and full parameter descriptions, the description sufficiently covers the essentials. It is complete for a simple retrieval tool with clear inputs.

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 adds value by explaining where to obtain photo_id and comment_id (e.g., from video results and first-level comments). The page_token usage is already well-documented in 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 it retrieves comment replies using photo_id and first-level comment comment_id. This distinguishes it from sibling tools like 'kuaishou_get_video_comments_by_photo_id' which get top-level comments.

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 explicitly state when to use this tool versus alternatives, but the name and context imply it is for fetching replies of a specific first-level comment. No explicit when-not or alternative guidance is provided.

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 clear. The description adds no additional behavioral context beyond what the schema provides (e.g., pagination handling is in schema but not description). Acceptable but minimal.

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 is front-loaded and wastes no words. It effectively communicates the core purpose. Could potentially include a brief mention of pagination but remains efficient.

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 presence of an output schema and detailed parameter descriptions in the schema, the description is adequate for the tool's simplicity. It covers the essential purpose but does not mention pagination or result limits, which are important for usage. Slightly incomplete.

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 parameters are fully documented in the schema. The tool description does not add any new semantic information about parameters beyond the schema, which is expected given full coverage. Baseline score 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 clearly states 'get first-level comment list based on photo_id', specifying the action and resource. It implicitly distinguishes from sibling tools like 'kuaishou_get_video_comment_replies_by_comment_id' by mentioning '一级评论' (top-level comments), but does not explicitly differentiate from 'kuaishou_get_video_comments_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 implies that this tool is for retrieving comments by photo_id, but does not explicitly state when to use it versus alternatives or provide any exclusion criteria. No guidance on when not to use it is given.

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 readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety; however, it adds no extra behavioral context (e.g., rate limits, data freshness) beyond what is implied by 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?

Two sentences, front-loaded with key information, 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?

Given the output schema exists and the tool is simple, the description is complete; it includes crucial context about what not to use and the alternative tool.

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 covers both parameters fully (100% coverage), but the description adds value by clarifying the exclusion of profile links and the alternative entry via photo_id, which goes 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 the tool retrieves top-level comments by video URL, and explicitly distinguishes from the sibling tool kuaishou_get_video_comments_by_photo_id by mentioning the alternative when photo_id is available.

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 instructs not to pass user profile links and to use the photo_id entry if available, providing clear guidance on when and how to use this tool versus alternatives.

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=true annotation already indicates a safe read operation. The description adds no new behavioral context beyond the operation itself (e.g., rate limits, authentication, or return behavior), but it is consistent with the annotations and does not omit any critical traits for a simple read 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?

The description is a single, focused sentence that front-loads the tool's primary function. It is concise with no redundant information, 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 one-parameter tool with an output schema, the description adequately covers the core purpose. It lacks explicit comparison with the by_url sibling, but the tool name and param description provide enough context for correct use in most cases.

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 schema already documents the photo_id parameter. The tool description itself adds no parameter semantics beyond what the schema provides, meeting the baseline for 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 tool retrieves video/work details based on the photo_id. The verb '获取' (get) and resource '作品详情' (work detail) are specific, and the by-photo_id parameter distinguishes it from the sibling by_url tool.

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 use when a photo_id is available, but does not explicitly compare with the sibling kuaishou_get_video_detail_by_url or provide exclusion criteria. The parameter description does hint at reusing photo_id from previous results, which is light 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?

注释已声明 readOnlyHint=true 和 openWorldHint=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?

工具复杂度低（单参数），且有输出 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 中 url 参数的描述与工具描述完全一致，覆盖率为100%，工具描述未在 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?

描述明确使用动词“获取”和资源“作品详情”，并具体说明支持快手作品链接、短链接或分享文案，与同类工具（如 photo_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?

描述直接说明“不要传用户主页链接”，并给出明确的替代方案：“如果上一步结果已返回 photo_id，可直接使用 photo_id 入口”。这为代理提供了何时使用本工具及何时改用其他工具的具体指导。

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，描述额外提供了'等待240秒'的超时行为和'不触发重处理'的无副作用保证，补充了注解未覆盖的行为细节。

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?

工具只有一个参数且 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?

参数 job_id 在 schema 中已有描述（'口播转文字任务 ID'），覆盖率为100%，描述未对参数增加额外语义，但保持了术语一致性。

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?

描述以'查询'开头，明确说明查询的是'快手视频口播转文字任务状态'，与提交任务的兄弟工具形成区分，且'不触发重处理'进一步限定行为。

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?

描述未显式说明何时使用（如在提交任务后轮询），但'每次最多等待 240 秒'暗示这是一个轮询型状态查询，与提交任务工具配合使用。缺少明确的替代工具排除说明。

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 readOnlyHint and openWorldHint. The description does not add behavioral details beyond what annotations provide, such as rate limits or data freshness.

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 extremely concise: a single sentence with a brief clarification. Every word is purposeful and front-loaded with the main action.

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 presence of an output schema and annotations, the description covers the essential purpose, prohibitions, and usage context. No important gaps remain for a search tool.

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 parameter explanations. The tool description largely repeats the keyword constraint and does not add significant new semantic information 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 the tool searches Kuaishou users by natural language keyword, with explicit exclusions of links and IDs, distinguishing it from sibling tools that use profile URLs or user IDs.

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?

Provides explicit guidance on when not to use (do not pass links, photo_id, or user_id) and when to use alternative tools (when a profile URL or non-empty user_id is available).

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, reducing the burden on description. The description adds behavioral context by specifying that input must be natural language (not links/IDs) and includes detailed page_token handling instructions (e.g., no modification, reuse restriction). 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 extremely concise—two short sentences that front-load the core purpose and immediately provide critical usage constraints. Every word adds value; there is no redundancy or 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?

Given the presence of an output schema and annotations covering readOnly/openWorld, the description adequately covers usage, exclusions, and pagination rules (via page_token description). It lacks a brief note on what the output represents (e.g., list of videos), but the output schema likely covers that. For a search tool, it is mostly complete.

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 schema already fully documents both parameters. The description adds no new meaning beyond the schema's own descriptions; it only restates the exclusion of certain input types, which is already present in the keyword parameter's description. Thus, baseline score 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 clearly states '按自然语言关键词搜索快手作品' (search Kuaishou videos by natural language keywords) and explicitly lists excluded inputs (links, IDs), making the purpose unmistakable and distinct from siblings like kuaishou_search_users or video detail tools that accept URLs/IDs.

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 forbids passing video links, user profile links, photo_id, or user_id, and implies that for such inputs, one should use other tools (e.g., kuaishou_get_video_detail_by_url). This provides clear when-to-use and when-not-to-use guidance, fully leveraging sibling tool differentiation.

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?

No annotations are provided, so the description carries the burden. It discloses the async nature, maximum wait time, and fallback job_id. It does not mention permission requirements or side effects, but for a submission tool, this is adequate.

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 includes purpose and behavioral notes. It is front-loaded and wastes no 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?

Given one parameter with clear schema, an output schema available, and a simple async submission task, the description covers all necessary information: what it does, the wait behavior, and the result structure.

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 sole parameter photo_id is described in the schema with sufficient guidance on its source. Schema coverage is 100%, so the description does not need to add more. Baseline score 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 clearly states it submits a video speech-to-text task using photo_id, specifying the wait period and return of job_id. It distinguishes from sibling tools like kuaishou_get_video_speech_text_job and kuaishou_submit_video_speech_text_by_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 explains what happens after submission: wait up to 240 seconds, and if incomplete, get job_id for later polling. However, it does not explicitly contrast with using the URL-based alternative, but the name and context make the distinction 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?

Without annotations, the description fully discloses the async behavior: maximum 240-second wait, return of job_id and next query action if incomplete. However, it doesn't explicitly state what happens on immediate success.

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 concise sentences, front-loaded with the action, no redundant information. Every sentence adds value.

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 simplicity (one parameter, async submission), the description covers use case, input restrictions, and expected outputs (job_id, next action). An output schema exists for return details, so completeness is high.

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 only parameter (video_url) has a schema description. The tool description adds specific guidance on acceptable URL types (share links, short links, copy text) and excludes user homepage links, enhancing 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 submits a speech-to-text transcription task for a Kuaishou video, specifies the input type (video URL), and distinguishes from the sibling tool using photo_id by mentioning the alternative.

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?

Provides explicit guidance: use for video URLs, avoid user homepage links, and if a photo_id is available, use the alternative tool. This helps agents choose correctly.

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