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.1/5 across 11 of 11 tools scored. Lowest: 3.3/5.
Each tool targets a specific resource and action (e.g., user info, videos, comments) with clear distinctions. The two variants for user info and videos (by URL vs user ID) are clearly differentiated and avoid ambiguity.
All tools follow a consistent pattern: 'kuaishou_<verb>_<object>_by_<parameter>' using snake_case. Verbs are either 'get' or 'search', and objects are descriptive, making the naming predictable and easy to understand.
With 11 tools covering hot search, user data, videos, comments, and search, the server is well-scoped for a data extraction API. The number is appropriate—neither too few nor too many—for the domain.
The tool set covers core CRUD-like operations for retrieving Kuaishou data: hot list, user info, posted videos, video details, comments, replies, and search. Minor gaps exist, such as lack of pagination for hot search and absence of user follower/following data, but the set is largely complete for typical extraction tasks.
Available Tools
14 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 declare readOnlyHint and openWorldHint. The description adds a key behavioral trait: no pagination support. 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?
Two short sentences, front-loaded with the purpose. Every word is necessary and no repetition.
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 no parameters and existence of output schema, the description is complete. It informs the agent of the function and a critical 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?
Input schema has zero parameters, so description adds no param info, which is unnecessary. Schema coverage is 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?
The description clearly states the tool's purpose: '获取快手短视频热榜' (get Kuaishou short video hot list). It is distinct from sibling tools which focus on user info, specific videos, etc.
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 that pagination is not supported, but does not explicitly state when to use or alternatives. Given the clear name and purpose, usage is implied.
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
根据快手用户主页链接、短链接或分享文案获取用户资料；不要传作品链接。如果上一步结果已返回 user_id，可直接使用 user_id 入口。
| Name | Required | Description | Default |
|---|---|---|---|
| profile_url | Yes | 快手用户主页链接、短链接或分享文案；不要传作品链接。如果上一步结果已返回 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 的工具输入；不可用时为 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 provide readOnlyHint and openWorldHint. The description adds behavioral context by specifying acceptable input types (homepage link, short link, sharing text) and restricting video links.
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 main purpose. No 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 output schema exists, the description adequately covers input constraints and usage context. Sibling tools are listed for alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already described. The description repeats the same information with the additional warning, but does not add significant new semantics 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?
Description clearly states the tool gets user info from a Kuaishou profile URL, short link, or sharing text. It distinguishes itself from the sibling tool by specifying that if user_id is already available, use the user_id entry 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?
Explicit guidance provided: do not pass video links, and advises using the user_id entry when user_id is already available. This tells the agent when to use this tool and when to use an alternative.
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 的快手用户或作者结果中复用。 |
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 的工具输入；不可用时为 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=true and openWorldHint=true, covering the safety profile. The description adds no further behavioral traits beyond confirming a read operation. It doesn't disclose any limitations or side effects, so it's adequate but not enhanced.
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, succinct, and front-loaded. No wasted words. Perfectly conciseness for a simple get tool.
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 clear parameter documentation, the description is adequately complete. It covers the essential purpose. Could optionally mention that user_id can be extracted from other results, but that is already in the parameter description. 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?
Schema description coverage is 100% (one parameter with description). The tool description adds no additional meaning beyond the schema's parameter description, which already explains user_id and its reuse. 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 action (获取用户资料 - get user profile) and the resource (by user_id). It distinguishes from the sibling tool 'kuaishou_get_user_info_by_profile_url' which uses profile_url instead of user_id, so the purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly provide usage guidelines, such as when to use this tool versus alternatives. The parameter description hints at reusing user_id from results, but no direct comparison or exclusions are given. Adequate but lacks explicit guidance.
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，可直接使用 user_id 入口。
| Name | Required | Description | Default |
|---|---|---|---|
| page_token | No | 用户作品分页令牌。首次请求留空。继续翻页时必须将上一页返回的完整 next_page_token 原样作为 page_token 传回；page_token 是不透明分页令牌；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。只能用于同一用户作品分页链路，不能跨能力或用户复用。 | |
| profile_url | Yes | 快手用户主页链接、短链接或分享文案；不要传作品链接。如果上一步结果已返回 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?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds minimal behavioral context beyond that (e.g., it gets public videos). It does not mention pagination behavior, rate limits, or any side effects, but annotations carry the safety profile burden.
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 that front-load the main purpose and key constraints. No redundant or 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?
With output schema present, the description doesn't need to detail return values. It covers purpose, usage conditions, and a key constraint (no video links). Missing explicit mention of pagination but schema handles that. Adequate for a paginated 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?
Schema coverage is 100%, so baseline is 3. The description adds some value for profile_url by emphasizing it's not for video links, but largely repeats the schema description. Page_token details are only in the schema. Marginal added value over 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 it retrieves a list of public videos from a Kuaishou user's profile URL, short link, or share text. It distinguishes from the sibling tool that uses user_id by explicitly mentioning an alternative entry point.
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, and if user_id is already available, use the user_id entry instead. This clearly tells the agent when to use this tool versus the sibling user_id-based 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_posted_videos_by_user_idARead-onlyInspect
根据快手用户 user_id 获取公开作品列表。
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | 快手用户 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 declare readOnlyHint=true and openWorldHint=true, so the tool is known to be read-only with possibly changing results. The description adds that user_id can be reused from other results, but does not disclose additional behavioral traits like rate limits or data freshness beyond what annotations and schema provide.
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 effectively communicates the tool's purpose without superfluous words. It is well-structured 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 the existence of an output schema, the description need not detail return values. It conveys the core purpose and input, but could be slightly more explicit about the scope (only public videos) and the requirement that user_id is a Kuaishou user ID. Overall, it is fairly 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 input schema has 100% description coverage, so the schema already documents both parameters. The description adds minor context for user_id (reusable from other results), but does not enhance meaning for page_token beyond the detailed schema description. Baseline 3 is appropriate as description adds limited value over 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 obtains a list of public videos posted by a Kuaishou user using their user_id. It specifies the verb (获取), resource (公开作品列表), and input (user_id), distinguishing it from siblings that use 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?
The description implies the tool is for retrieving public videos by user_id, and the sibling tool kuaishou_get_user_posted_videos_by_profile_url offers an alternative by profile URL. However, there is no explicit guidance on when to choose one over the other, nor any mention of when not 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_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, so the description carries less burden. It accurately describes the read operation but adds no further behavioral context beyond what annotations imply.
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, front-loaded with the key action and resources. 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 the tool's simplicity, existence of output schema, and clear annotations, the description is complete enough. It covers the essential purpose and the schema handles parameter details.
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 baseline is 3. The description repeats the schema's meaning without adding new information about parameter format or constraints.
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 comment replies for a given photo_id and top-level comment_id. It distinguishes itself 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 schema hint at its purpose. The input schema provides guidance on not passing reply comment_ids, which helps correct usage.
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_idBRead-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 declare readOnlyHint=true and openWorldHint=true. The description adds no additional behavioral context such as authentication requirements, rate limits, or the fact that it returns only top-level comments.
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 wasted words, and clearly conveys the main function. Could be slightly more structured but is 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?
For a simple retrieval tool with output schema and good annotations, the description covers the essential purpose. It lacks explicit clarification that it only returns top-level comments, but this is implied by '一级评论'.
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 schema descriptions are adequate. The tool description does not add further meaning to the parameters beyond what the schema already provides, meeting baseline expectations.
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 '获取' (get), resource '一级评论列表' (first-level comment list), and identifier 'photo_id'. Distinguishes from sibling tools like kuaishou_get_video_comment_replies_by_comment_id which handles 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. It does not mention that it only provides top-level comments or that for replies one should use a different tool.
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 indicate readOnlyHint=true and openWorldHint=true. The description adds the constraint about profile links and the photo_id alternative but does not disclose additional behavioral traits like rate limits, pagination behavior, or error handling. With good annotation coverage, 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 two sentences, front-loaded with the primary purpose. It is concise and efficient, though could be slightly more structured with bullet points for clarity.
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 (not shown), the description sufficiently covers input requirements and usage context (URL vs photo_id). It is complete for this moderately complex tool with pagination.
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 description repeats schema info for the url parameter without adding new meaning. The page_token parameter is fully explained in the schema. Thus, description adds no extra value beyond schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '获取' (get) and resource '一级评论列表' (first-level comment list) for Kuaishou video URLs, short links, or sharing text. It distinguishes from sibling tools like kuaishou_get_video_comments_by_photo_id by specifying the input type.
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 says not to pass user profile links and provides guidance to use photo_id if available. This gives clear when-to-use and when-not-to-use instructions.
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。 |
| 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 description does not need to restate those. However, the description adds no additional behavioral context beyond what annotations provide, such as potential caching or performance 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 a single, front-loaded sentence with zero wasted words. It efficiently conveys the core purpose 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 that an output schema exists and annotations cover read-only and open-world behavior, the description is adequately complete for a simple get-detail-by-ID tool. It does not need to elaborate on return values or constraints beyond what is already structured.
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 one parameter fully described. The tool description does not add any additional meaning beyond what the parameter's description already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (获取 get) and resource (作品详情 video details) and identifies the key identifier (photo_id). It distinguishes the tool from its sibling kuaishou_get_video_detail_by_url by specifying the use of 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 implies usage when you have a photo_id, but does not explicitly state when to use this tool over alternatives like the URL-based variant. No when-not or prerequisites are mentioned, leaving the agent to infer the distinction.
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。 |
| 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 indicate readOnly and openWorld hints. The description adds context about acceptable input formats (url, short link, shared text) and a constraint (not user profile links), which enhances transparency 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 concise sentences that efficiently convey the tool's purpose, input requirements, and usage guidance. 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?
For a single-parameter tool with output schema available, the description sufficiently covers the essentials. It tells the agent what to input and what not to input, and hints at an alternative path. Could mention output specifics but not necessary given output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description's parameter text is identical to the schema. The description adds no new meaning beyond what the schema already provides, so 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, short link, or shared text, and explicitly distinguishes from user profile links. It also notes the alternative photo_id entry point, which differentiates it from sibling tools 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?
Provides clear guidance on what inputs to avoid (user profile links) and when to use a sibling tool (if photo_id is available). This gives the agent context for selection, though it doesn't cover all sibling comparisons.
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。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | Yes | 失败或过期时的稳定错误结构；非终态或成功时为 null。 |
| job_id | Yes | 任务 ID。 |
| status | Yes | 任务状态。 |
| message | Yes | 面向用户/AI 的状态说明。 |
| platform | Yes | 任务所属平台。 |
| source_id | Yes | 任务来源 ID。 |
| transcript | Yes | 成功时的口播转文字结果；非终态或失败时为 null。 |
| is_terminal | Yes | 是否已终态。 |
| next_action | 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?
Annotations already declare readOnlyHint=true. The description adds that it doesn't trigger reprocessing or long wait, providing additional behavioral detail 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 sentences with no waste; first sentence states purpose, second adds behavioral constraint. 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?
For a single-parameter query job with output schema present, the description covers purpose, behavioral constraint, and usage guidelines adequately.
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 clear parameter description. The tool description does not add extra semantics beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb (query/查询) and resource (video speech text job status), and distinguishes from sibling tools that submit jobs or query other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that this tool only queries the current job and does not trigger reprocessing or long wait, guiding when to use and implying alternatives for triggering.
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 and openWorldHint, but the description adds critical behavioral constraints: it explicitly forbids passing certain input types (links, IDs) that would be invalid. This adds value beyond 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?
The description is concise (two sentences) with no filler. It immediately states the core action and then provides critical negative usage instructions, making it efficient for an AI agent.
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 search functionality and pagination, the description covers the essential purpose and input constraints. The output schema presumably handles return value details. The sibling tools are numerous, and the description sufficiently differentiates this tool from them.
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 does not need to add parameter details. It repeats the input constraints found in the schema, but does not introduce new semantic information 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 the tool's function: searching for Kuaishou works using natural language keywords. It also explicitly distinguishes from siblings that use URLs or IDs by instructing not to pass those, aligning with the sibling tool names.
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 not to use this tool and directs to alternatives when having a work link/photo_id or user profile link/user_id. The schema parameter descriptions reinforce this, making usage intent clear.
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 提交视频口播转文字任务；提交完成后最多短等 15 秒，未完成时返回 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。 |
| transcript | Yes | 成功时的口播转文字结果；非终态或失败时为 null。 |
| is_terminal | Yes | 是否已终态。 |
| next_action | 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?
With no annotations, the description discloses the asynchronous nature, maximum wait time, and return of job_id, but lacks details on authentication, rate limits, or destructive effects.
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 covering purpose and key behavioral notes without unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description adequately covers submission and polling behavior, though it could mention auth requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the description adds minimal extra meaning beyond the schema's description, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits a speech-to-text task using photo_id, and distinguishes from the sibling tool that uses video_url via the tool name and context.
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 the wait behavior and job polling, giving implicit usage context, but does not explicitly state when to use this tool vs the video URL version.
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
提交快手作品视频口播转文字任务；提交完成后最多短等 15 秒，未完成时返回 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。 |
| transcript | Yes | 成功时的口播转文字结果；非终态或失败时为 null。 |
| is_terminal | Yes | 是否已终态。 |
| next_action | 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?
With no annotations, the description carries full burden. It discloses async behavior: wait up to 15 seconds, returns job_id and next query action if not completed. This is good transparency for a submit 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?
Single sentence that concisely covers submission, wait time, and fallback behavior. No wasted words, front-loaded with core 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 one parameter and existence of output schema, the description covers the essential behavior. Could be more specific about the query action, but it's sufficient for an agent to infer next steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema parameter description is detailed, so baseline is 3. The tool description does not add parameter info, but it is not necessary given the rich 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 it submits a speech-to-text task for Kuaishou videos, distinguishing it from sibling tools like submission by photo_id or querying job status. The verb 'submit' and resource 'video speech text' are 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 you have a video URL and mentions waiting up to 15 seconds then querying. It does not explicitly exclude alternatives or state when not to use, but context from siblings suggests using submit_by_photo_id if you have a photo_id.
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!