SocialDataX 快手 Kuaishou MCP
Server Details
Kuaishou hot list, work search/details, comments/replies, profiles, transcript.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 14 of 14 tools scored. Lowest: 3.6/5.
All tools have clearly distinct purposes, organized by resource (user/video) and action (get/list/search/submit). URL-based vs ID-based variants are explicit and non-overlapping.
All tools follow a consistent pattern: kuaishou_<verb>_<resource>[_by_<identifier>]. Naming is uniform and predictable across the set.
14 tools is well within the optimal range for a focused data access API. Each tool covers a distinct operation without unnecessary bloat.
The tool set covers core CRUD-like access for users and videos, including search, comments, and speech-to-text. No obvious missing operations for the stated domain.
Available Tools
15 toolskuaishou_get_hot_search_listARead-onlyInspect
获取快手短视频热榜；当前不支持翻页。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | 快手短视频热榜条目。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds the pagination limitation, which is useful behavioral context. However, it does not disclose other traits such as data freshness, ordering, or potential truncation. With annotations covering the safety profile, a score of 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 in Chinese with no extraneous information. It is appropriately sized and front-loaded, earning its 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?
Given the tool has no parameters and an output schema is present, the description need not explain return values. It clearly states the purpose and the key limitation (no pagination), making it complete for a simple list 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?
The tool has no parameters, so the description does not need to add parameter semantics. Schema coverage is 100% (empty). Baseline for zero parameters is 4. The description does not repeat schema info, which 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 clearly states the tool gets the Kuaishou short video hot list ('获取快手短视频热榜'). It uses a specific verb and resource, and is easily distinguishable from sibling tools that focus on users, videos, or 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 includes a limitation ('当前不支持翻页' - currently does not support pagination), which provides some usage context. However, it lacks explicit guidance on when to use this tool vs alternatives (e.g., search tools), and does not specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kuaishou_get_user_info_by_profile_urlARead-onlyInspect
根据快手用户主页链接、短链接或分享文案获取用户资料；支持 live 主页和 fw/user 用户主页分享链接，成功时会返回可复用的非空 user_id；不要传作品链接。如果上一步结果已返回非空 user_id，可直接使用 user_id 入口。
| Name | Required | Description | Default |
|---|---|---|---|
| profile_url | Yes | 快手用户主页链接、短链接或分享文案；不要传作品链接。支持 live 主页或 fw/user 形式的用户主页分享链接；成功时会返回可复用的非空 user_id。如果上一步结果已返回非空 user_id，可直接使用 user_id 入口。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| bio | Yes | 用户简介；不可用时为空字符串。 |
| name | Yes | 用户名称。 |
| gender | Yes | 用户性别。 |
| user_id | Yes | 快手用户非空 user_id；可作为后续需要快手用户 user_id 的工具输入。 |
| avatar_url | Yes | 用户头像链接；不可用时为 null。 |
| kuaishou_id | Yes | 快手号；不可用时为 null。 |
| profile_url | Yes | 快手用户主页链接；不是作品分享页链接；可作为后续需要快手用户主页 URL 的工具输入；查询用户作品列表时需确认同一用户结果包含非空 user_id；不可用时为 null。 |
| follower_count | Yes | 粉丝数；不可用时为 null。 |
| following_count | Yes | 关注数；不可用时为 null。 |
| received_like_count | Yes | 获赞数；表示用户内容累计收到的点赞数；不可用时为 null。 |
| posted_content_count | Yes | 公开作品数；不可用时为 null。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds value by detailing the return of a reusable user_id and supported link formats, which are behavioral traits beyond annotations. No 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, dense sentence in Chinese that encapsulates the tool's purpose, supported inputs, output, and usage guidelines. It is front-loaded and contains no superfluous 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?
Despite simplicity, the description covers input format, output (user_id), constraints (no video links), and usage flow (switch to user_id). With schema and annotations, it provides complete context for effective tool 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 parameter description is identical to the tool description. The description adds no additional meaning beyond what the schema provides, meeting the baseline for high 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 user information from Kuaishou profile URLs, short links, or share text. It specifies supported link types (live and fw/user) and emphasizes it returns a reusable user_id. Implicitly distinguishes from sibling tool that uses 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?
Provides explicit guidance: use profile URLs, do not pass video links, and after obtaining a non-empty user_id, switch to the user_id-based tool. Although it does not enumerate all alternatives, it gives clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kuaishou_get_user_info_by_user_idARead-onlyInspect
根据快手用户非空 user_id 获取用户资料。
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | 快手用户非空 user_id；可从包含非空 user_id 的快手用户或作者结果中复用；如果上一步结果里的 user_id 为空字符串，不要使用 user_id 入口。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| bio | Yes | 用户简介；不可用时为空字符串。 |
| name | Yes | 用户名称。 |
| gender | Yes | 用户性别。 |
| user_id | Yes | 快手用户非空 user_id；可作为后续需要快手用户 user_id 的工具输入。 |
| avatar_url | Yes | 用户头像链接；不可用时为 null。 |
| kuaishou_id | Yes | 快手号；不可用时为 null。 |
| profile_url | Yes | 快手用户主页链接；不是作品分享页链接；可作为后续需要快手用户主页 URL 的工具输入；查询用户作品列表时需确认同一用户结果包含非空 user_id；不可用时为 null。 |
| follower_count | Yes | 粉丝数；不可用时为 null。 |
| following_count | Yes | 关注数；不可用时为 null。 |
| received_like_count | Yes | 获赞数；表示用户内容累计收到的点赞数；不可用时为 null。 |
| posted_content_count | Yes | 公开作品数；不可用时为 null。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds no new behavioral context beyond stating it's a get operation. 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?
Single sentence, efficient, and 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 a simple tool with one parameter and an output schema, the description is sufficient. It could be slightly more explicit about reuse context, but adequate.
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 a detailed parameter description. The tool description adds no extra semantic value 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 action (获取user资料) and resource (user profile via user_id). It distinguishes from sibling tool using profile URL by specifying the identifier.
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 guidance on when to use this tool versus siblings. The parameter description hints at usage conditions (non-empty user_id), but lacks explicit when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kuaishou_get_user_posted_videos_by_profile_urlARead-onlyInspect
根据可直接解析出非空 user_id 的快手用户主页链接、短链接或分享文案获取公开作品列表；不要传作品链接；只有 live/fw-user 主页链接时，先调用用户资料入口，成功后使用返回的非空 user_id 查询作品列表。如果上一步结果已返回非空 user_id，可直接使用 user_id 入口。
| Name | Required | Description | Default |
|---|---|---|---|
| page_token | No | 用户作品分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一用户作品分页链路，不能跨能力或用户复用。 | |
| profile_url | Yes | 快手用户主页链接、短链接或分享文案；不要传作品链接。该入口需要能直接解析出可复用 user_id 的主页链接；只有 live/fw-user 主页链接时，先调用用户资料入口，成功后使用返回的非空 user_id 查询作品列表。如果上一步结果已返回非空 user_id，可直接使用 user_id 入口。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页该用户发布的作品列表。 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多结果。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回。next_page_token 只能用于同一能力和同一分页链路，不能跨能力、作品、用户、评论或搜索链路复用；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the conditional behavior (fallback to user info tool) and acceptable URL types, adding context beyond the annotations (readOnlyHint, openWorldHint). It does not contradict 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 concise (two sentences) and front-loaded with purpose and constraints. Every sentence adds value without 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?
Given the tool has two parameters, output schema, and annotations, the description fully explains the tool's behavior, including conditional logic and prerequisites, making it complete for agent 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 coverage is 100%, so baseline is 3. The description adds value by explaining acceptable URL types and when to use the tool for profile_url, but does not significantly enhance parameter semantics beyond what the schema 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 retrieves a public video list from a Kuaishou user profile URL, short link, or share text. It specifies the verb 'get' and the resource 'videos' and distinguishes from video links and the sibling tool using 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?
The description provides explicit guidance: do not pass video links; for live/fw-user links, first use the user info tool and then the user_id entry; if user_id is already available, use the user_id tool directly. This clearly differentiates from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kuaishou_get_user_posted_videos_by_user_idARead-onlyInspect
根据快手用户非空 user_id 获取公开作品列表。
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | 快手用户非空 user_id；可从包含非空 user_id 的快手用户或作者结果中复用；如果上一步结果里的 user_id 为空字符串，不要使用 user_id 入口。 | |
| page_token | No | 用户作品分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一用户作品分页链路，不能跨能力或用户复用。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页该用户发布的作品列表。 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多结果。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回。next_page_token 只能用于同一能力和同一分页链路，不能跨能力、作品、用户、评论或搜索链路复用；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds that it retrieves 'public' works, and pagination behavior is detailed in page_token description. Sufficient for safety and mutability.
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 sentence precisely states the tool's function. Additional details are in parameter descriptions, keeping the main description lean 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?
Given low complexity, output schema presence, and rich parameter descriptions, the tool is well-documented. Covers core action, condition, and pagination. No missing critical context.
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?
100% schema description coverage. The description reinforces that user_id must be non-empty and provides detailed pagination rules beyond schema, adding meaningful context.
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 resource ('公开作品列表' - public works list) based on non-empty user_id. It distinguishes itself from sibling tools like kuaishou_get_user_posted_videos_by_profile_url, which uses profile URL instead.
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 parameter details explain when to use: when a non-empty user_id is available, and not when it's empty. Pagination rules are provided. Could be more explicit about alternatives, but sibling tools provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kuaishou_get_video_comment_replies_by_comment_idARead-onlyInspect
根据 photo_id 和一级评论 comment_id 获取评论回复。
| Name | Required | Description | Default |
|---|---|---|---|
| photo_id | Yes | 快手作品 photo_id；可从包含 photo_id 的快手作品结果中复用。 | |
| comment_id | Yes | 一级评论 ID；从一级评论结果 items[].comment_id 复制，用于获取该评论下的回复；不要传回复项的 comment_id。 | |
| page_token | No | 回复分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一作品下同一一级评论的回复分页链路，不能跨能力、作品或评论复用。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页评论回复列表。 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多结果。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回。next_page_token 只能用于同一能力和同一分页链路，不能跨能力、作品、用户、评论或搜索链路复用；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, and description adds no further behavioral context (e.g., rate limits, auth). No 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?
One short, clear sentence with no wasted words. Perfectly concise.
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 parameter descriptions are complete, the description is sufficient for a simple tool. Minor improvement could be mentioning pagination behavior in the description itself.
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 tool description does not add extra meaning beyond what the schema already provides for each parameter.
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 it retrieves replies to a first-level comment using photo_id and comment_id, distinguishing it from sibling tools that 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 main description does not explicitly state when or when not to use, but parameter descriptions provide guidance (e.g., not to pass reply comment_id). No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kuaishou_get_video_comments_by_photo_idARead-onlyInspect
根据快手作品 photo_id 获取一级评论列表。
| Name | Required | Description | Default |
|---|---|---|---|
| photo_id | Yes | 快手作品 photo_id；可从包含 photo_id 的快手作品结果中复用。 | |
| page_token | No | 分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一作品评论分页链路，不能跨能力或作品复用。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页一级评论列表。 |
| comment_count | Yes | 评论总数；不可用时为 null。 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多结果。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回。next_page_token 只能用于同一能力和同一分页链路，不能跨能力、作品、用户、评论或搜索链路复用；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. Description adds that it returns first-level comments, consistent with annotations and 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?
Single sentence, no unnecessary words, front-loaded with key action and resource.
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?
Adequate for a read tool with output schema; covers core purpose and parameters, but could mention pagination or alternative access more explicitly.
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%; description does not add parameter meaning beyond what schema 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?
Description clearly states it retrieves first-level comments using photo_id, distinguishing it from siblings that get comments by URL or replies.
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 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.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kuaishou_get_video_comments_by_urlARead-onlyInspect
根据快手作品链接、短链接或分享文案获取一级评论列表；不要传用户主页链接。如果上一步结果已返回 photo_id，可直接使用 photo_id 入口。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 快手作品页链接、短链接或分享文案；不要传用户主页链接。如果上一步结果已返回 photo_id，可直接使用 photo_id 入口。 | |
| page_token | No | 分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一作品评论分页链路，不能跨能力或作品复用。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页一级评论列表。 |
| comment_count | Yes | 评论总数；不可用时为 null。 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多结果。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回。next_page_token 只能用于同一能力和同一分页链路，不能跨能力、作品、用户、评论或搜索链路复用；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only. The description adds that it only retrieves first-level comments, a behavioral constraint not captured by annotations, but no further details on pagination or error states.
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-load the purpose, then add exclusion and alternative. No unnecessary words, well structured for quick comprehension.
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 presumably covering return format, the description adequately explains the tool's function and scope. Minor omissions like error conditions are acceptable given annotations and schema richness.
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 clear parameter descriptions. The description adds extra guidance on url (no user profile links) and hints at alternative usage via photo_id, slightly enhancing schema meaning.
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 first-level comments by video URL, short link, or share text, explicitly distinguishing it from the sibling 'get_video_comments_by_photo_id' tool and ruling out user profile 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?
Explicitly advises when to use (given video URL/share text) and when not to (user profile link). Also suggests an alternative path if photo_id is already available, providing clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kuaishou_get_video_detail_by_photo_idARead-onlyInspect
根据快手作品 photo_id 获取作品详情。
| Name | Required | Description | Default |
|---|---|---|---|
| photo_id | Yes | 快手作品 photo_id；可从包含 photo_id 的快手作品结果中复用。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| video | Yes | 播放资源；视频作品返回播放资源，图集作品为 null。 |
| author | Yes | 作品作者信息。 |
| images | Yes | 图集作品按顺序返回完整图片列表；视频作品为空数组。 |
| photo_id | Yes | 快手作品 photo_id；可作为后续需要快手作品 photo_id 的工具输入。 |
| share_url | Yes | 作品分享页链接；不是播放资源或封面资源链接；可作为后续需要快手作品 URL 的工具输入。 |
| like_count | Yes | 点赞数；不可用时为 null。 |
| topic_tags | Yes | 作品话题标签列表；无标签时为空数组。 |
| view_count | Yes | 播放数；不可用时为 null。 |
| description | Yes | 作者发布文本/作品文案，可能包含话题标签；不可用时为空字符串。 |
| share_count | Yes | 分享数；不可用时为 null。 |
| content_type | Yes | 作品内容类型；video 表示视频，image 表示图集。 |
| publish_time | Yes | 发布时间，秒级 Unix 时间戳；不可用时为 null。 |
| collect_count | Yes | 收藏数；不可用时为 null。 |
| comment_count | Yes | 评论数；不可用时为 null。 |
| cover_image_url | Yes | 封面图资源链接；不是作品分享页或播放资源链接；不可用时为 null。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, so the description need not repeat that. However, the description adds no additional behavioral context (e.g., rate limits, data freshness) beyond what is already in annotations, so minimal added value.
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 directly states the tool's purpose without any unnecessary words or repetition. It is front-loaded and 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 that an output schema exists, the description does not need to explain return values. The tool is simple with one parameter, and the description sufficiently covers what it does, though it could mention the output format or any important constraints (e.g., requires authentication).
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 covers 100% of parameters with a description for photo_id. The tool description adds the useful hint that the photo_id can be reused from other results, which provides practical context beyond the schema's technical 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 clearly states the verb (获取/get) and the resource (作品详情/video detail) using a specific identifier (photo_id). It implicitly distinguishes itself from sibling tools like kuaishou_get_video_detail_by_url, which uses a URL instead.
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. While the sibling list includes a similar tool by URL, no explicit usage context or exclusions are provided, leaving it to the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kuaishou_get_video_detail_by_urlARead-onlyInspect
根据快手作品链接、短链接或分享文案获取作品详情；不要传用户主页链接。如果上一步结果已返回 photo_id，可直接使用 photo_id 入口。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 快手作品页链接、短链接或分享文案；不要传用户主页链接。如果上一步结果已返回 photo_id，可直接使用 photo_id 入口。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| video | Yes | 播放资源；视频作品返回播放资源，图集作品为 null。 |
| author | Yes | 作品作者信息。 |
| images | Yes | 图集作品按顺序返回完整图片列表；视频作品为空数组。 |
| photo_id | Yes | 快手作品 photo_id；可作为后续需要快手作品 photo_id 的工具输入。 |
| share_url | Yes | 作品分享页链接；不是播放资源或封面资源链接；可作为后续需要快手作品 URL 的工具输入。 |
| like_count | Yes | 点赞数；不可用时为 null。 |
| topic_tags | Yes | 作品话题标签列表；无标签时为空数组。 |
| view_count | Yes | 播放数；不可用时为 null。 |
| description | Yes | 作者发布文本/作品文案，可能包含话题标签；不可用时为空字符串。 |
| share_count | Yes | 分享数；不可用时为 null。 |
| content_type | Yes | 作品内容类型；video 表示视频，image 表示图集。 |
| publish_time | Yes | 发布时间，秒级 Unix 时间戳；不可用时为 null。 |
| collect_count | Yes | 收藏数；不可用时为 null。 |
| comment_count | Yes | 评论数；不可用时为 null。 |
| cover_image_url | Yes | 封面图资源链接；不是作品分享页或播放资源链接；不可用时为 null。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the tool is known to be a safe, read-only operation. The description does not add any extra behavioral context (e.g., rate limits, permissions, or response format) beyond what the annotations provide, resulting in no additional value.
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, consisting of two clear sentences that are front-loaded with the core purpose and immediately followed by usage constraints. No superfluous information is present.
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 (readOnlyHint, openWorldHint), the description provides sufficient context for understanding the tool's purpose and constraints. It covers all essential aspects for an agent to use 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%, and the property description in the input schema is identical to the tool description. The description adds no new meaning beyond what the schema already specifies, so a 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 the tool retrieves video details from a URL (work link, short link, or share text). It distinguishes itself by specifying what not to pass (user page URLs) and mentions an alternative photo_id entry tool, differentiating it from siblings like kuaishou_get_video_detail_by_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?
The description provides explicit guidance on when to use this tool (when you have a video URL) and when not to (do not pass user page URLs). It also advises that if a photo_id is already available from a previous step, the agent should use the photo_id entry point instead, giving clear context for alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kuaishou_get_video_speech_text_jobARead-onlyInspect
查询快手视频口播转文字任务状态；可选长轮询当前 job，不触发重处理。
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | 口播转文字任务 ID。 | |
| wait_seconds | No | 可选长轮询等待秒数；0 表示只查询一次，最大 240 秒。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | Yes | 失败或过期时的稳定错误结构；非终态或成功时为 null。 |
| job_id | Yes | 任务 ID。 |
| status | Yes | 任务状态。 |
| message | Yes | 面向用户/AI 的状态说明。 |
| platform | Yes | 任务所属平台。 |
| source_id | Yes | 任务来源 ID。 |
| content_id | Yes | 平台内容 ID。 |
| transcript | Yes | 成功时的口播转文字结果；非终态或失败时为 null。 |
| is_terminal | Yes | 是否已终态。 |
| next_action | Yes | 非终态时建议的下一步查询动作。 |
| content_meta | Yes | 作品上下文信息，便于结合转写内容做口播分析。 |
| content_type | Yes | 内容类型。 |
| next_poll_after_seconds | Yes | 建议下次查询前等待的秒数；非终态时可用。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: optional long polling via wait_seconds and the important note that no reprocessing is triggered. This fully discloses key behaviors.
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 with key information front-loaded: purpose and behavioral note. 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 an output schema present, the description adequately covers purpose and key behavior. It could mention error handling or result interpretation, but is sufficient for a status query.
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%, so baseline is 3. The description clarifies the long-polling option (wait_seconds) and the no-reprocessing behavior, adding value beyond 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 queries video speech-to-text task status, with optional long polling, and explicitly notes it does not trigger reprocessing. This distinguishes it from sibling submit 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?
It is clear that this tool is for querying status by job_id, but it does not explicitly mention when to use it over alternatives or provide prerequisites. However, the sibling submit tools imply the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kuaishou_search_usersARead-onlyInspect
按自然语言关键词搜索快手用户；不要传作品链接，不要传用户主页链接、photo_id 或 user_id。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 搜索快手用户的自然语言关键词。传人物名、账号名、品牌名或机构名等关键词；不要传作品链接，不要传用户主页链接、photo_id 或 user_id。已有用户主页链接或非空 user_id 时改用需要快手用户主页 URL/user_id 的入口。 | |
| page_token | No | 用户搜索分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一用户搜索分页链路和同一关键词，不能跨能力、关键词或搜索链路复用。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页用户结果列表。 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多结果。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回。next_page_token 只能用于同一能力和同一分页链路，不能跨能力、作品、用户、评论或搜索链路复用；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds no behavioral details beyond what annotations and schema provide, such as pagination behavior or output characteristics.
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 with two short sentences, no wasted words, and front-loaded with the primary purpose.
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 existence of an output schema and annotations, the description is nearly complete for a search tool. It could mention pagination or result count, but overall it suffices.
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 description adds minimal new meaning to the parameters beyond what the schema 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 it searches Kuaishou users by natural language keywords and explicitly tells what not to pass (links or IDs), distinguishing it from sibling tools that require 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?
The description provides explicit when-to-use and when-not-to-use guidance, including the instruction to use alternative tools if a profile URL or user ID is available, and the parameter description reinforces this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kuaishou_search_videosARead-onlyInspect
按自然语言关键词搜索快手作品；不要传作品链接，不要传用户主页链接、photo_id 或 user_id。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 快手搜索关键词。传自然语言关键词或短语，例如品牌名、话题、人物名、内容需求；不要传作品链接、用户主页链接、photo_id 或 user_id。已有作品链接或 photo_id 时改用需要快手作品 URL/photo_id 的入口；已有用户主页链接或非空 user_id 时改用需要快手用户主页 URL/user_id 的入口。 | |
| page_token | No | 搜索分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一搜索分页链路和同一关键词，不能跨能力、关键词或搜索链路复用。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页作品结果列表。 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多结果。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回。next_page_token 只能用于同一能力和同一分页链路，不能跨能力、作品、用户、评论或搜索链路复用；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=true. The description adds behavioral context about natural language search and input restrictions, but does not detail all behaviors (e.g., pagination limits, result format). No 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, efficient sentence that front-loads the core action and includes critical usage constraints. No redundant 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 2 parameters, full schema coverage, annotations, output schema, and many siblings, the description is complete. It covers purpose, usage constraints, and hints at alternatives, without needing to repeat structured data.
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%. The main description adds marginal value by summarizing input restrictions ('natural language', 'don't pass links/IDs'), but the schema already provides detailed parameter descriptions. 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 clearly states the tool searches Kuaishou videos by natural language keywords, explicitly distinguishing from sibling tools that require URLs or IDs. It uses specific verb 'search' and resource '快手作品'.
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 parameter schema provide explicit when not to use (do not pass links/IDs) and when to use alternatives (use other tools for URLs/IDs). This guides the agent to select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kuaishou_submit_video_speech_text_by_photo_idAInspect
根据快手 photo_id 提交视频口播转文字任务；提交完成后最多短等 210 秒，未完成时返回 job_id 和下一步查询动作。
| Name | Required | Description | Default |
|---|---|---|---|
| photo_id | Yes | 快手作品 photo_id；可从包含 photo_id 的快手作品结果中复用。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | Yes | 失败或过期时的稳定错误结构；非终态或成功时为 null。 |
| job_id | Yes | 任务 ID。 |
| status | Yes | 任务状态。 |
| message | Yes | 面向用户/AI 的状态说明。 |
| platform | Yes | 任务所属平台。 |
| source_id | Yes | 任务来源 ID。 |
| content_id | Yes | 平台内容 ID。 |
| transcript | Yes | 成功时的口播转文字结果；非终态或失败时为 null。 |
| is_terminal | Yes | 是否已终态。 |
| next_action | Yes | 非终态时建议的下一步查询动作。 |
| content_meta | Yes | 作品上下文信息，便于结合转写内容做口播分析。 |
| content_type | Yes | 内容类型。 |
| next_poll_after_seconds | Yes | 建议下次查询前等待的秒数；非终态时可用。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses async behavior, timeout, and return of job_id for polling, providing good transparency about the tool's behavior.
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?
Single sentence contains all key info but is slightly dense; still concise 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?
Given output schema exists, description covers key aspects: what it does, async nature, timeout, and next steps. Lacks error handling details but sufficient for the tool 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?
Only one parameter 'photo_id' with 100% schema coverage. Description adds no extra meaning beyond the schema's 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?
Description clearly states the verb 'submit' and the resource 'video speech-to-text task by photo_id', distinguishing 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?
Description implies async workflow with a 210-second wait and fallback to job query, but does not explicitly state when to use this over the URL-based sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
kuaishou_submit_video_speech_text_by_video_urlAInspect
提交快手作品视频口播转文字任务；提交完成后最多短等 210 秒，未完成时返回 job_id 和下一步查询动作。
| Name | Required | Description | Default |
|---|---|---|---|
| video_url | Yes | 快手作品页链接、短链接或分享文案；不要传用户主页链接。如果上一步结果已返回 photo_id，可直接使用 photo_id 入口。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | Yes | 失败或过期时的稳定错误结构；非终态或成功时为 null。 |
| job_id | Yes | 任务 ID。 |
| status | Yes | 任务状态。 |
| message | Yes | 面向用户/AI 的状态说明。 |
| platform | Yes | 任务所属平台。 |
| source_id | Yes | 任务来源 ID。 |
| content_id | Yes | 平台内容 ID。 |
| transcript | Yes | 成功时的口播转文字结果；非终态或失败时为 null。 |
| is_terminal | Yes | 是否已终态。 |
| next_action | Yes | 非终态时建议的下一步查询动作。 |
| content_meta | Yes | 作品上下文信息，便于结合转写内容做口播分析。 |
| content_type | Yes | 内容类型。 |
| next_poll_after_seconds | Yes | 建议下次查询前等待的秒数；非终态时可用。 |
Tool Definition Quality
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 asynchronous nature (wait, job_id), which is key for a submission tool. Lacks details on auth or rate limits, but adequate for the operation.
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 core action. No unnecessary words; 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?
For a 1-parameter tool with output schema, the description covers the key flow. It could mention the related get job tool, but the hint about '下一步查询动作' partially addresses that. Missing comparison with the photo_id sibling.
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 a detailed description for 'video_url'. The tool description adds behavioral context but does not enhance parameter semantics. 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 clearly states the action: submitting a video speech-to-text task. It specifies the resource (Kuaishou work video) and the operation (转文字). The name distinguishes it from the sibling using 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?
The description provides context on behavior (wait time up to 210 seconds, returning job_id if not completed). The parameter description in the schema clarifies to use photo_id if available, indirectly guiding tool choice. However, no explicit when-to-use or alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!