SocialDataX 快手 Kuaishou MCP
Server Details
快手/Kuaishou hot list, work search/details, comments/replies, creator profiles, works.
- 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 11 of 11 tools scored. Lowest: 3.6/5.
Each tool targets a specific resource and action (e.g., hot search, user info by URL or ID, video comments by photo ID or URL). While there are duplicate entry points (by URL and by ID), the descriptions clearly distinguish when to use each, leaving no ambiguity.
All tools follow a consistent pattern: prefix 'kuaishou_' followed by a verb phrase (e.g., 'get_hot_search_list', 'get_user_info_by_profile_url'). The naming is uniform and predictable, with no mixing of styles.
With 11 tools, the set is well-scoped for a platform-specific server. Each tool covers a distinct operation without redundancy, and the count feels appropriate for the domain of retrieving Kuaishou data.
The tool set provides comprehensive read operations: hot search, user info, user videos, video details, comments, comment replies, and search. Minor gaps exist (e.g., no pagination for hot search, missing follower/following data), but the core workflows are covered.
Available Tools
11 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?
The annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that the tool retrieves 'public works list,' confirming read-only behavior, and explains pagination via page_token (first request empty, subsequent requests pass next_page_token). This adds useful context beyond the annotations, such as the type of content returned and pagination mechanics.
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 long, both essential: the first states the core purpose with constraints, and the second offers a practical alternative. It is efficiently front-loaded with no redundant 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 presence of an output schema (not shown but indicated) and good annotations, the description covers input types, constraints, and pagination. It does not address rate limits or error handling, but the output schema likely details return values. Overall, it is sufficiently complete for the tool's purpose.
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 descriptions for both parameters. The description enhances understanding by specifying that profile_url accepts links, short links, or share copy but not work links, and advises using the user_id entry if available. For page_token, the description reiterates pagination usage, adding value beyond the schema's basic 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?
The description clearly states the tool retrieves a list of public works based on a Kuaishou user's profile URL, short link, or share copy. It explicitly distinguishes from alternatives by advising not to pass a work link and suggesting the user_id entry when available, which differentiates it from sibling tools like kuaishou_get_user_posted_videos_by_user_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (with profile URL, short link, or share copy) and when not to use it (do not pass work link; if user_id is available, use the user_id entry). This clear direction helps an agent select the correct tool among siblings.
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 and openWorldHint, so the description's simple statement adds minimal behavioral context beyond what is obvious. It does not contradict annotations but does not elaborate on non-obvious 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?
The description is a single, efficient sentence that is immediately understandable. There is no unnecessary wording, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, presence of output schema, and good annotations, the description is largely complete for its purpose. However, the lack of usage guidelines somewhat detracts from completeness.
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 adds practical context for the user_id parameter (reuse from user results) and page_token (first request vs. continuation). This goes beyond the schema alone.
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 public video list based on Kuaishou user user_id'. It uses a specific verb ('get') and resource ('user posted videos'), and the sibling tool with profile_url differentiates this variant.
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 guidance is provided on when to use this tool versus alternatives (e.g., the sibling tool using profile_url). There is no mention of prerequisites or preferred scenarios.
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 the description confirms a read operation. The parameter comment for comment_id adds behavioral context by warning not to pass reply IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward reply-fetching tool, the description, annotations, and input schema together provide complete context. Output schema exists, so return values are not needed in the description.
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 detailed parameter descriptions. The tool description itself adds no extra semantic value beyond the schema, 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 retrieves comment replies using photo_id and first-level comment_id, which distinguishes it from sibling tools that get top-level comments or video details.
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 comments provide guidance: comment_id must be a first-level comment ID, not a reply ID. However, it does not explicitly compare to sibling tools or state when to prefer this one.
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 declare readOnlyHint=true and openWorldHint=true. The description adds that only first-level comments are returned, which is key behavioral info not in annotations. Missing details like comment ordering or rate limits, but acceptable given read-only nature.
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, direct sentence with no unnecessary words. It is appropriately sized and front-loaded with the 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?
The description covers the essential purpose and parameter hints. With an output schema present, return values need not be expanded. However, it lacks mention of potential error cases or result limits. Still sufficient for a straightforward list retrieval.
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 descriptions for both parameters (photo_id and page_token). The description adds no new parameter meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves first-level comments (一级评论列表) using photo_id, clearly specifying the resource and identifier. It distinguishes from siblings 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?
The description provides no guidance on when to use this tool versus alternatives, such as kuaishou_get_video_comments_by_url or when pagination is needed. No context on prerequisites or exclusion criteria.
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, so the tool's safety profile is clear. The description adds no further behavioral details beyond stating it gets a list of comments. No mention of rate limits, pagination behavior beyond the page_token parameter, or response structure. The description adds minimal 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 two concise sentences with no wasted words. It front-loads the core purpose and includes a crucial usage tip, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with two parameters and an existing output schema, the description is complete. It covers input types, exclusions, and alternatives. The annotations handle transparency, so no further elaboration is needed.
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 for the 'url' parameter repeats the tool description, and 'page_token' has its own description in the schema. The tool description does not add new semantic information beyond what the input 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 retrieves top-level comments from Kuaishou video links, short links, or share text. It explicitly distinguishes itself by noting not to pass user profile links and mentions the alternative usage via photo_id, setting it apart from sibling tools like kuaishou_get_video_comments_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: avoid user profile links, and if a photo_id is already available, use the photo_id entry instead. This effectively tells when to use this tool versus alternatives, fulfilling the guidelines dimension.
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 | 播放资源；无可播放 play_url 时为 null。 |
| author | 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 | 作品内容类型。 |
| 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 safety profile is clear. The description adds no behavioral details beyond stating the action, such as rate limits or failure modes.
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, front-loaded, no unnecessary words. Efficiently conveys the 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 the simple tool (one parameter, output schema exists, annotations present), the description is largely complete. It could briefly mention how to obtain a photo_id, but the schema already addresses that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a detailed parameter explanation. The tool description does not add additional context beyond what the schema provides, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves video details using a photo_id. It distinguishes from sibling tools like kuaishou_get_video_detail_by_url by specifying the identifier 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?
No guidance on when to use this tool versus alternatives (e.g., by URL). The description lacks context for selecting the appropriate method based on available identifiers.
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 | 播放资源；无可播放 play_url 时为 null。 |
| author | 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 | 作品内容类型。 |
| 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. Description adds behavioral details: accepts multiple URL types, excludes user profile URLs, and suggests photo_id alternative. 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?
Two concise sentences. First states purpose and acceptable inputs, second gives negative directive and alternative. 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 single parameter, full schema coverage, output schema present, and annotations, the description is complete. It provides input constraints and usage context without needing to explain returns.
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%, baseline 3. Description adds value by clarifying that the url parameter can be a link, short link, or share text, and explicitly excludes user profile links, which goes beyond the schema 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 verb '获取' (get) and resource '作品详情' (video details), specifying multiple input types (link, short link, share text). Distinguishes from sibling by warning against user profile links and suggesting alternate photo_id entry.
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 when to use (for video links) and when not to (do not pass user profile link). Provides alternative: use photo_id entry if available, which directly references a sibling tool.
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 already provide readOnlyHint and openWorldHint. The description adds context that it's a search operation constrained to keywords, reinforcing safe usage. 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 very short, with a single sentence plus a negative instruction. It is front-loaded and efficient, but could be slightly more structured (e.g., separate sections for do's and don'ts).
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 (2 params, output schema exists), the description covers the essential: what to input, what not to input, and by extension when to use. No gaps remain for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description summarizes the keyword parameter's constraints but does not add new meaning beyond the schema's detailed explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '按自然语言关键词搜索快手作品' (search Kuaishou videos by natural language keywords), specifying the verb (search) and resource (videos). It distinguishes from sibling tools like user info and video detail retrievers, which do not perform keyword search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells what not to pass (links, photo_id, user_id) and implies when to use: for natural language queries. The keyword parameter schema further elaborates on correct inputs and alternatives for different cases.
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!