WeChat Channels videos, comments, users, transcripts, and Official Account article details.
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.
Average 3.9/5 across 14 of 14 tools scored. Lowest: 3.2/5.
Each tool has a clearly distinct purpose, with overlaps only for alternative input methods (e.g., by URL vs by ID) which are necessary for flexibility. Descriptions are specific enough to avoid confusion.
All tools follow a consistent 'wechat_verb_noun_by_qualifier' pattern with snake_case, making it easy to predict tool functionality from names.
14 tools is well-scoped for a WeChat Channels MCP, covering core data retrieval (users, videos, comments, speech-to-text) without unnecessary bloat.
Provides comprehensive read operations for videos, comments, and user info, plus speech-to-text submission and query. Missing write operations and user info by URL, but this aligns with a read-focused data interface.
wechat_get_hot_search_listA获取微信视频号热榜；当前不支持翻页。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| items | Yes | 微信视频号热榜条目 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that pagination is not supported, which is a useful constraint 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?
The description is a single, front-loaded sentence with no superfluous words. Every part of the sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and an output schema, the description is sufficiently complete. It mentions the lack of pagination, which is critical for agent expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema coverage is effectively 100%. The description does not need to elaborate on parameters, but it adds no extra value either. According to guidelines, 0 parameters baseline is 4.
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 the hot search list for WeChat video accounts, using a specific verb and resource. It distinguishes itself from sibling tools, which focus on MP articles, user info, or individual 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?
No guidance is provided on when to use this tool versus its siblings. There is no mention of alternatives, prerequisites, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wechat_get_mp_article_detail_by_urlA根据微信公众号文章链接或包含链接的分享文案获取文章详情和正文。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 微信公众号文章 / WeChat Official Account article 链接，或包含该链接的分享文案；例如 https://mp.weixin.qq.com/s/cyog0u9QpLFvdBsh9JR3_g。 |
| Name | Required | Description |
|---|---|---|
| sn | Yes | 公众号文章 sn 标识；不可用时为空字符串 |
| biz | Yes | 公众号文章 biz 标识；不可用时为空字符串 |
| idx | Yes | 公众号文章 idx 标识；不可用时为空字符串 |
| mid | Yes | 公众号文章 mid 标识；不可用时为空字符串 |
| title | Yes | 公众号文章标题 |
| account | Yes | 公众号账号信息 |
| image_urls | Yes | 正文图片链接，按页面顺序返回 |
| source_url | Yes | 规范化后的公众号文章链接 |
| description | Yes | 文章摘要；不可用时为空字符串 |
| content_html | Yes | 正文 HTML 片段 |
| content_text | Yes | 正文纯文本，已去除标签并压缩空白 |
| publish_time | Yes | 文章发布时间，秒级 Unix 时间戳；当前不可用时为 null |
| cover_image_url | Yes | 文章封面图片链接；当前不可用时为 null |
| linked_articles | Yes | 正文内链公众号文章列表 |
| finder_video_cards | Yes | 正文内嵌视频号卡片列表 |
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 it gets article details and body, but does not elaborate on error handling, rate limits, or authentication, which is acceptable given annotations but not additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core functionality with no redundancy or unnecessary detail, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple single-parameter tool with an output schema (not shown) and annotations, the description adequately covers the tool's purpose and input semantics, leaving little ambiguity for its usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds that the 'url' parameter can be a direct link or a sharing text containing the link, which enriches the schema description that already had high coverage (100%). It provides practical input flexibility.
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 article details and body from a WeChat Official Account article link or sharing text, distinguishing it from sibling tools that focus on different content types like videos and user info.
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 describes what the tool does but does not provide explicit guidance on when to use it versus alternatives, such as when not to use it or which sibling tools are better suited for other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wechat_get_user_info_by_urlA根据微信视频号视频链接或分享文案解析作者后获取用户信息。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 微信视频号视频链接，或包含该链接的分享文案；例如 https://weixin.qq.com/sph/ANxgB9MB8i，或“帮我看下这个视频 https://weixin.qq.com/sph/ANxgB9MB8i”。 |
| Name | Required | Description |
|---|---|---|
| bio | Yes | 用户简介；不可用时为空字符串 |
| name | Yes | 用户昵称；不可用时为空字符串 |
| gender | Yes | 用户性别 |
| user_id | Yes | 微信视频号用户 ID；不可用时为空字符串 |
| location | Yes | 用户资料地区；没有资料地区时为空字符串 |
| avatar_url | Yes | 用户头像链接；当前不可用时为 null |
| ip_location | Yes | 用户 IP 属地；没有 IP 属地时为空字符串 |
| original_content_count | Yes | 原创内容数量 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and openWorldHint=true annotations already covering safety, the description adds the nontrivial behavior that the tool parses the author from the URL/share text before fetching info. It doesn't discuss failure modes or output specifics, but the annotations lower the transparency burden and no contradiction exists.
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 one focused Chinese sentence that immediately states the input and action. There is no filler or repetition of the tool name, and every clause contributes to understanding the tool's function.
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 required parameter, rich schema coverage, safe-read annotations, and an output schema, the description is almost fully sufficient. It would benefit from a note on what happens if no author can be parsed from the URL, but this is a minor gap for a low-complexity lookup 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 single 'url' parameter has 100% schema description coverage, including the exact type and an example. The tool description adds the parsing step ('解析作者') but not additional parameter-level meaning; the schema already carries the semantic weight, so the 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 a specific action: parse the author from a WeChat Channels video link or shared text and retrieve user info. It distinguishes from sibling tools like wechat_get_user_info_by_user_id (by user ID) and wechat_get_video_detail_by_url (video details) by specifying the URL/share-text source and user-info result.
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 strongly implies the use case: when the agent has a WeChat Channels video link or share text and needs the author's user info. It does not explicitly name alternatives or exclusions, but the input requirement is clear and sibling tool names provide enough contrast for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wechat_get_user_info_by_user_idB根据微信视频号用户 ID 获取用户信息。
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | 微信视频号用户 ID；只支持以 v2_ 开头、以 @finder 结尾的账号 ID；从视频详情、用户发布视频列表、评论或评论回复结果中的 author.user_id 或 reply_to_user_id 复制；如果不是 v2_...@finder，不要传。 |
| Name | Required | Description |
|---|---|---|
| bio | Yes | 用户简介；不可用时为空字符串 |
| name | Yes | 用户昵称；不可用时为空字符串 |
| gender | Yes | 用户性别 |
| user_id | Yes | 微信视频号用户 ID；不可用时为空字符串 |
| location | Yes | 用户资料地区；没有资料地区时为空字符串 |
| avatar_url | Yes | 用户头像链接；当前不可用时为 null |
| ip_location | Yes | 用户 IP 属地；没有 IP 属地时为空字符串 |
| original_content_count | Yes | 原创内容数量 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to repeat that. However, the description adds no additional behavioral context such as permissions or rate limits. With annotations covering the safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key action and resource. It wastes no words, though it could potentially add a touch more context without becoming verbose.
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 the schema fully documents the parameter and an output schema exists, the description is minimally complete. It states the tool's purpose, but could benefit from mentioning that it fetches detailed user profile information.
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 the schema already documents the parameter fully. The description does not add any parameter semantics beyond what the schema provides, so the baseline score of 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (获取/get) and resource (用户信息/user info) with the method (by user ID). It is specific and distinguishes this tool from siblings like wechat_get_user_posted_videos_by_user_id, which retrieves user videos rather than user info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. There is no mention of prerequisites, use cases, or exclusions. While the parameter description in the schema details the valid user ID format, that is part of the schema, not the tool description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wechat_get_user_posted_videos_by_urlA根据微信视频号视频链接或分享文案中包含的视频链接，解析作者后获取用户发布视频列表。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 微信视频号视频链接，或包含该链接的分享文案；例如 https://weixin.qq.com/sph/ANxgB9MB8i，或“帮我看下这个视频 https://weixin.qq.com/sph/ANxgB9MB8i”。 | |
| page_token | No | 微信视频号用户发布视频列表分页令牌；首次请求留空，继续翻页时必须将上一次返回的完整 next_page_token 原样传入，作为 page_token 使用；只能用于同一微信视频号用户发布视频分页链路；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页用户发布视频列表 |
| next_page_token | Yes | 微信视频号用户发布视频列表分页令牌；首次请求留空，继续翻页时必须将上一次返回的完整 next_page_token 原样传入，作为 page_token 使用；只能用于同一微信视频号用户发布视频分页链路；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation. The description adds that the tool internally parses the author from the URL, which is useful context beyond annotations. No contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that precisely conveys the tool's core functionality. It is front-loaded and concise, with 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 presence of an output schema and full parameter descriptions, the description is fairly complete. It covers the main action but omits details about error handling or output structure, which are partially addressed by the 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 coverage is 100%, so the baseline is 3. The description does not add any parameter semantics beyond what the schema already provides (e.g., url format, page_token usage).
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: given a WeChat video channel video URL, it parses the author and retrieves the user's published video list. This distinguishes it from the sibling tool wechat_get_user_posted_videos_by_user_id, which uses a user ID instead of a URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you have a video URL) but does not explicitly exclude other cases or mention alternatives. It provides clear direction but lacks when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wechat_get_user_posted_videos_by_user_idA根据微信视频号用户 ID 获取用户发布视频列表，支持 page_token 翻页。
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | 微信视频号用户 ID；只支持以 v2_ 开头、以 @finder 结尾的账号 ID；从视频详情、用户发布视频列表、评论或评论回复结果中的 author.user_id 或 reply_to_user_id 复制；如果不是 v2_...@finder，不要传。 | |
| page_token | No | 微信视频号用户发布视频列表分页令牌；首次请求留空，继续翻页时必须将上一次返回的完整 next_page_token 原样传入，作为 page_token 使用；只能用于同一微信视频号用户发布视频分页链路；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页用户发布视频列表 |
| next_page_token | Yes | 微信视频号用户发布视频列表分页令牌；首次请求留空，继续翻页时必须将上一次返回的完整 next_page_token 原样传入，作为 page_token 使用；只能用于同一微信视频号用户发布视频分页链路；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, indicating a safe read operation. The description adds pagination behavior but does not disclose any additional behavioral traits such as rate limits, error handling for invalid user IDs, or data freshness. With annotations covering the core safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that covers purpose and pagination without any fluff. It is front-loaded and efficiently communicates the core functionality. Slightly longer descriptions with context could improve completeness but current level is good.
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 low complexity (2 parameters, output schema exists), the description is sufficiently complete for an agent to understand the primary use case. The pagination mechanism is clearly explained. However, it could mention that the tool returns published videos (implied) to be fully self-contained.
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 descriptions for both parameters. The tool description does not add meaning beyond what the schema already provides, so the baseline score of 3 is maintained. No enhancement from extra 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 action ('get user posted videos list') and the key identifier (user ID). While it does not explicitly contrast with the sibling tool by URL, the name and context make the distinction apparent. A slightly higher score would require explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage guidance through the detailed schema descriptions for user_id and page_token, including when not to pass certain values. However, it lacks explicit statements about when to use this tool versus alternatives (e.g., wechat_get_user_posted_videos_by_url) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wechat_get_video_comment_replies_by_comment_idB根据微信视频号一级评论 ID 获取评论回复。
| Name | Required | Description | Default |
|---|---|---|---|
| object_id | Yes | 微信视频号视频的 object_id，例如 14882122090270235141；获取评论时请与同一条视频的 object_nonce_id 一起原样传入。 | |
| comment_id | Yes | 微信视频号一级评论 ID，例如 14941641522352032263；从一级评论结果 items[].comment_id 复制，用于获取该评论下的回复；不要传回复项的 comment_id。 | |
| page_token | No | 评论回复分页令牌；首次请求留空，继续翻页时必须将上一页返回的完整 next_page_token 原样传回；只能用于同一微信视频号、同一一级评论的回复分页链路。 | |
| object_nonce_id | Yes | 微信视频号视频的 object_nonce_id，例如 12801331239707625908_0_39_0_0；获取评论时请与同一条视频的 object_id 一起原样传入。 |
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页评论回复列表；过滤后可能为空数组 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多评论回复。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回；next_page_token 只能用于同一微信视频号、同一一级评论的回复分页链路；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds no further behavioral details such as pagination behavior, rate limits, or explanation of open world semantics. It provides minimal added 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 a single, concise sentence in Chinese that conveys the essential purpose. It is appropriately sized, though it could benefit from additional context about which kind of comment ID is required (already covered in schema).
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 100% schema coverage, the description is adequate but could be more complete. It does not explicitly state that it only works for first-level comments (though the comment_id parameter does), nor does it warn about potential open world behavior.
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 including examples and usage notes. The tool description does not repeat this information, so the baseline of 3 is appropriate; the schema already carries the semantic load.
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 (获取/retrieve) and the resource (评论回复/comment replies) and specifies the key identifier (一级评论 ID/first-level comment ID). It is specific and distinguishes from sibling tools that retrieve 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 does not provide explicit guidance on when to use this tool versus alternatives. It lacks 'when-to-use', 'when-not-to-use', or references to sibling tools, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wechat_get_video_comments_by_object_idA根据微信视频号详情返回的 object_id 和 object_nonce_id 获取评论列表。
| Name | Required | Description | Default |
|---|---|---|---|
| object_id | Yes | 微信视频号视频的 object_id，例如 14882122090270235141；获取评论时请与同一条视频的 object_nonce_id 一起原样传入。 | |
| page_token | No | 评论分页令牌；首次请求留空，继续翻页时必须将上一页返回的完整 next_page_token 原样传回。 | |
| object_nonce_id | Yes | 微信视频号视频的 object_nonce_id，例如 12801331239707625908_0_39_0_0；获取评论时请与同一条视频的 object_id 一起原样传入。 |
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页评论列表；过滤后可能为空数组 |
| comment_count | Yes | 评论总数 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多评论。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回；next_page_token 只能用于同一微信视频号评论分页链路；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint; description adds no further behavioral context such as rate limits, auth, or return structure beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, to-the-point sentence with no unnecessary words; clearly front-loads the 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?
For a simple read tool with schema coverage and output schema, the description is adequate; could briefly mention pagination but not essential.
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; tool description adds no additional parameter meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool gets a comment list using object_id and object_nonce_id, distinguished from sibling wechat_get_video_comments_by_url which uses a URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies when to use (when you have the two IDs) but lacks explicit comparison to the URL-based sibling or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wechat_get_video_comments_by_urlA根据微信视频号视频链接或包含链接的分享文案获取评论列表。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 微信视频号视频链接，或包含该链接的分享文案；例如 https://weixin.qq.com/sph/ANxgB9MB8i，或“帮我看下这个视频 https://weixin.qq.com/sph/ANxgB9MB8i”。 | |
| page_token | No | 评论分页令牌；首次请求留空，继续翻页时必须将上一页返回的完整 next_page_token 原样传回。 |
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页评论列表；过滤后可能为空数组 |
| comment_count | Yes | 评论总数 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多评论。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回；next_page_token 只能用于同一微信视频号评论分页链路；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description is consistent. It adds that the input can be a URL or shared text, which is useful. However, no additional behavioral details like rate limits or how pagination works beyond what the schema covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no redundancy. The purpose is immediately clear 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?
Output schema exists, so return values are covered. The description covers input format variations and pagination token usage. It lacks mention of error conditions or scope (only for 视频号), but for a simple list tool this is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but the description adds clarity by explaining that the url parameter can include shared text containing the link (e.g., '帮我看下这个视频 https://...') and that page_token should be passed from previous response. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action '获取评论列表' (get comment list) and the resource '微信视频号视频链接或包含链接的分享文案' (WeChat video link or shared text containing the link). Among siblings, this distinguishes itself by using URL as input, unlike 'wechat_get_video_comments_by_object_id' which uses object 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?
No guidance on when to use this tool versus alternatives like 'wechat_get_video_comments_by_object_id'. No context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wechat_get_video_detail_by_encrypted_object_idA根据微信视频号搜索结果返回的 encrypted_object_id 获取视频详情。
| Name | Required | Description | Default |
|---|---|---|---|
| encrypted_object_id | Yes | 微信视频号搜索结果返回的 encrypted_object_id；如果来自搜索结果，请原样传入。 |
| Name | Required | Description |
|---|---|---|
| video | Yes | 视频资源信息；当前不可用时为 null |
| author | Yes | 作者信息 |
| images | Yes | 图文作品按顺序返回图片资源；视频作品为空数组 |
| object_id | Yes | 微信视频号详情对象 ID；不可用时为空字符串 |
| like_count | Yes | 点赞数 |
| topic_tags | Yes | 作品文案中的话题标签；无话题时为空数组；每项只返回 name |
| description | Yes | 作品描述；不可用时为空字符串 |
| ip_location | Yes | 视频发布时的 IP 属地；没有 IP 属地时为空字符串 |
| share_count | Yes | 转发/分享数 |
| content_type | Yes | 内容类型；视频返回 video，图文返回 image |
| publish_time | Yes | 发布时间，秒级 Unix 时间戳 |
| collect_count | Yes | 收藏数 |
| comment_count | Yes | 评论数 |
| cover_image_url | Yes | 封面图或图文首图缩略资源链接；当前不可用时为 null |
| object_nonce_id | Yes | 微信视频号对象 nonce ID；后续评论等能力需要复用时原样保留 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not add behavioral context beyond the annotations (readOnlyHint: true). Annotations already indicate no side effects, so the description's lack of additional disclosure is neutral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary information. It is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter tool and presence of an output schema, the description covers the key aspect of input source. It lacks explicit error conditions or prerequisites, but overall sufficient 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?
The input schema already fully describes the parameter with 100% coverage. The description adds no new meaning beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action '获取视频详情' (get video details) and the resource '根据微信视频号搜索结果返回的 encrypted_object_id'. It distinguishes from the sibling tool 'wechat_get_video_detail_by_url' by specifying the input source.
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 an encrypted_object_id from search results is available, but does not explicitly state when not to use or name alternatives. However, the sibling tools context provides differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wechat_get_video_detail_by_urlA根据微信视频号视频链接或包含链接的分享文案获取视频详情。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 微信视频号视频链接，或包含该链接的分享文案；例如 https://weixin.qq.com/sph/ANxgB9MB8i，或“帮我看下这个视频 https://weixin.qq.com/sph/ANxgB9MB8i”。 |
| Name | Required | Description |
|---|---|---|
| video | Yes | 视频资源信息；当前不可用时为 null |
| author | Yes | 作者信息 |
| images | Yes | 图文作品按顺序返回图片资源；视频作品为空数组 |
| object_id | Yes | 微信视频号详情对象 ID；不可用时为空字符串 |
| like_count | Yes | 点赞数 |
| topic_tags | Yes | 作品文案中的话题标签；无话题时为空数组；每项只返回 name |
| description | Yes | 作品描述；不可用时为空字符串 |
| ip_location | Yes | 视频发布时的 IP 属地；没有 IP 属地时为空字符串 |
| share_count | Yes | 转发/分享数 |
| content_type | Yes | 内容类型；视频返回 video，图文返回 image |
| publish_time | Yes | 发布时间，秒级 Unix 时间戳 |
| collect_count | Yes | 收藏数 |
| comment_count | Yes | 评论数 |
| cover_image_url | Yes | 封面图或图文首图缩略资源链接；当前不可用时为 null |
| object_nonce_id | Yes | 微信视频号对象 nonce ID；后续评论等能力需要复用时原样保留 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description does not add additional behavioral context beyond this, such as any potential side effects, permissions, or rate limits. Given annotations, the description is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys all necessary information. It is front-loaded and contains 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 tool's simplicity (one parameter, no nested objects), the presence of an output schema, and the annotations, the description is fully sufficient. It does not omit any critical information.
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 description for the 'url' parameter is detailed: it explains it can be a direct link or shared text containing the link, and it provides examples. This adds significant value beyond the schema's type and required flag.
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 video details) and the specific resource ('根据微信视频号视频链接或包含链接的分享文案' based on WeChat video channel video link or shared text containing the link). It distinguishes from sibling tools that retrieve details by encrypted object ID, comments, 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 implies usage when a video URL or shared text is available, but it does not explicitly state when to use this tool versus alternatives like wechat_get_video_detail_by_encrypted_object_id, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wechat_get_video_speech_text_jobA查询微信视频号口播转文字任务状态；每次最多等待 240 秒，不触发重处理。
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | 口播转文字任务 ID。 |
| Name | Required | Description |
|---|---|---|
| error | Yes | 失败或过期时的稳定错误结构；非终态或成功时为 null。 |
| job_id | Yes | 任务 ID。 |
| status | Yes | 任务状态。 |
| message | Yes | 面向用户/AI 的状态说明。 |
| platform | Yes | 任务所属平台。 |
| source_id | Yes | 任务来源 ID。 |
| content_id | Yes | 平台内容 ID。 |
| transcript | Yes | 成功时的口播转文字结果；非终态或失败时为 null。 |
| is_terminal | Yes | 是否已终态。 |
| next_action | Yes | 非终态时建议的下一步查询动作。 |
| content_meta | Yes | 作品上下文信息，便于结合转写内容做口播分析。 |
| content_type | Yes | 内容类型。 |
| next_poll_after_seconds | Yes | 建议下次查询前等待的秒数；非终态时可用。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known to be a safe read. The description adds valuable behavioral context beyond annotations: it explicitly states a maximum wait of 240 seconds and that no reprocessing is triggered. This is useful for an agent deciding whether to poll or resubmit. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads purpose, then adds two critical behavioral constraints (240s wait, no reprocessing). There is zero wasted text; every clause 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?
For a simple status-query tool with one parameter and an output schema, the description is largely complete. It mentions the key behavior (waiting, no side effects) and purpose. It doesn't explain error handling or polling patterns, but the output schema covers return values, and the simplicity of the tool does not require more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the only parameter job_id with the description '口播转文字任务 ID。', giving 100% coverage. The tool description does not add any additional meaning about the parameter beyond what the schema provides. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (查询/query) and resource (微信视频号口播转文字任务状态/WeChat Channels video speech-to-text task status). It distinguishes itself from sibling tools: there are submit tools for speech-to-text tasks, and this is the corresponding status query tool. The waiting and no-reprocessing details further clarify its role.
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 clear context: it is a status polling tool that waits up to 240 seconds and does not trigger reprocessing. This implies it should be used after submitting a speech-to-text task and not for resubmission. However, it does not explicitly name alternatives or give when-not-to-use guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wechat_search_videosA搜索微信视频号视频，返回视频列表和下一页分页令牌。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | 微信视频号搜索关键词，例如 露营、周末带娃；不要传链接或分页 token。 | |
| sort_type | No | 搜索排序方式，可选：all（不限，默认）、time_descending（最新）、collect_count_descending（最热/最多收藏排序）。如无明确排序需求，保持 all。 | all |
| page_token | No | page_token 是不透明分页令牌。首次请求留空；继续翻页时必须将上一次返回的完整 next_page_token 原样传入，作为 page_token 使用；只能用于同一微信视频号搜索分页链路、同一关键词和同一筛选条件的下一页，不能跨能力、关键词或筛选条件复用；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 | |
| duration_range | No | 视频时长筛选，可选：all（不限，默认）、under_5_min（5 分钟以下）、between_5_and_20_min（5-20 分钟）、over_20_min（20 分钟以上）。如无明确筛选需求，保持 all。 | all |
| Name | Required | Description |
|---|---|---|
| items | Yes | 当前页搜索结果中的视频列表，已过滤直播、合集和相关搜索卡片；当前页过滤后可能为空数组 |
| next_page_token | Yes | 下一页不透明分页令牌；为空表示没有更多结果。继续翻页时必须将返回的完整 next_page_token 原样作为 page_token 传回；next_page_token 只能用于同一微信视频号搜索分页链路；不得修改、截断、缩写、脱敏、掩码、省略、规范化、重组或自行生成，不得用省略号替换中间内容。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that it returns a video list and pagination token, which is consistent and provides additional operational context. 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?
The description is a single, focused sentence with no wasted words. Parameter descriptions are thorough but separate. The overall structure is clean 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?
The tool has a complete input schema, output schema, and detailed parameter descriptions. The description is minimal but covers the core function. It could mention relationships to sibling tools, but that is not critical given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have detailed Chinese descriptions covering usage constraints (e.g., keyword not being a link), enum options, default values, and pagination token handling. Schema description coverage is 100%, and the descriptions add significant meaning beyond schema definitions.
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 precisely states the tool searches for WeChat video account videos and returns a list with pagination tokens. It is distinct from sibling tools like wechat_get_hot_search_list (hot searches) and wechat_get_video_detail_by_url (single video detail), making the purpose clear.
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 instruct when to use this tool versus alternatives. However, parameter hints (e.g., keyword should not be a link or token) provide some implicit guidance. No explicit when-to-use/when-not-to-use is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wechat_submit_video_speech_text_by_encrypted_object_idAInspect根据微信视频号 encrypted_object_id 提交视频口播转文字任务；提交完成后最多短等 240 秒，未完成时返回 job_id 和下一步查询动作。
| Name | Required | Description | Default |
|---|---|---|---|
| encrypted_object_id | Yes | 微信视频号搜索结果返回的 encrypted_object_id；如果来自搜索结果，请原样传入。 |
| Name | Required | Description |
|---|---|---|
| error | Yes | 失败或过期时的稳定错误结构；非终态或成功时为 null。 |
| job_id | Yes | 任务 ID。 |
| status | Yes | 任务状态。 |
| message | Yes | 面向用户/AI 的状态说明。 |
| platform | Yes | 任务所属平台。 |
| source_id | Yes | 任务来源 ID。 |
| content_id | Yes | 平台内容 ID。 |
| transcript | Yes | 成功时的口播转文字结果；非终态或失败时为 null。 |
| is_terminal | Yes | 是否已终态。 |
| next_action | Yes | 非终态时建议的下一步查询动作。 |
| content_meta | Yes | 作品上下文信息，便于结合转写内容做口播分析。 |
| content_type | Yes | 内容类型。 |
| next_poll_after_seconds | Yes | 建议下次查询前等待的秒数；非终态时可用。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses asynchronous behavior with a 240-second wait, the return of job_id and next query action if incomplete. It lacks details on the completion case, error handling, or authentication, but provides essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence in Chinese covers purpose, input, behavior, and output. Every part is essential, no redundancy, and front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (async submission) and the existence of an output schema (which explains return values), the description provides adequate context. It mentions the wait and fallback result but could be clearer about the direct result on completion.
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 new meaning beyond the schema's explanation, so it meets the baseline without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: submitting a video speech-to-text task using the encrypted_object_id from WeChat video channels. It specifies the input source and distinguishes from the URL-based sibling tool by explicitly mentioning 'encrypted_object_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 when to use this tool: when you have an encrypted_object_id from search results. The sibling tool wechat_submit_video_speech_text_by_video_url is an alternative for URL-based usage. However, it does not explicitly state conditions or exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wechat_submit_video_speech_text_by_video_urlAInspect提交微信视频号视频口播转文字任务；提交完成后最多短等 240 秒，未完成时返回 job_id 和下一步查询动作。
| Name | Required | Description | Default |
|---|---|---|---|
| video_url | Yes | 微信视频号视频链接，或包含该链接的分享文案；例如 https://weixin.qq.com/sph/ANxgB9MB8i，或“帮我看下这个视频 https://weixin.qq.com/sph/ANxgB9MB8i”。 |
| Name | Required | Description |
|---|---|---|
| error | Yes | 失败或过期时的稳定错误结构；非终态或成功时为 null。 |
| job_id | Yes | 任务 ID。 |
| status | Yes | 任务状态。 |
| message | Yes | 面向用户/AI 的状态说明。 |
| platform | Yes | 任务所属平台。 |
| source_id | Yes | 任务来源 ID。 |
| content_id | Yes | 平台内容 ID。 |
| transcript | Yes | 成功时的口播转文字结果；非终态或失败时为 null。 |
| is_terminal | Yes | 是否已终态。 |
| next_action | Yes | 非终态时建议的下一步查询动作。 |
| content_meta | Yes | 作品上下文信息，便于结合转写内容做口播分析。 |
| content_type | Yes | 内容类型。 |
| next_poll_after_seconds | Yes | 建议下次查询前等待的秒数；非终态时可用。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: the tool may wait up to 240 seconds and returns a job_id with a query action if the task is not completed. This transparency is adequate for a submission tool, though no annotations exist to contradict.
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, no extraneous information. The purpose and key behavioral details are front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description doesn't need to detail return values. It mentions the job_id and next query action, which is sufficient for a single-parameter tool with clear semantics.
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 does not add extra meaning beyond the schema's parameter description, which already describes the video_url. Hence, no additional value from 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 it submits a task for converting WeChat video speech to text, distinguishing from sibling tools like wechat_get_video_speech_text_job (query) and wechat_submit_video_speech_text_by_encrypted_object_id (different input). The verb 'submit' and resource 'video speech text task' are 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?
Provides clear context for when to use: submitting a speech-to-text task with a video URL. Mentions behavior after submission (wait up to 240s, returns job_id if incomplete). However, does not explicitly state when not to use or mention alternatives like the encrypted object ID variant.
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.
No comments yet. Be the first to start the discussion!