SocialDataX TikTok MCP

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

Annotations already declare readOnlyHint=true, and the Chinese description reinforces that this is a query operation. The description adds context about the account-level API Key scope, but it does not disclose details such as response format, rate-limit implications, or whether the balance is cached or real-time.

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 compact sentence with the key information front-loaded. The bilingual repetition and enumeration of 'balance / remaining points / points' is slightly redundant but not harmful.

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 this is a zero-parameter read-only balance lookup, the description is complete. An output schema is present, so return values do not need to be described, and the annotations cover the safety profile.

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 zero parameters and schema description coverage is 100%, so there is nothing for the description to explain about inputs. The description still usefully clarifies that 'points balance' refers to remaining credits.

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, resource, and scope: querying the SocialDataX points balance for the current API Key account. It is fully distinguishable from the unrelated zhihu_ sibling tools even without inspecting schemas.

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 intended use is reasonably implied by the name and description, but there is no explicit guidance about when to check the balance, how it relates to other tools, or when this tool would not be appropriate. No alternatives are mentioned.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses pagination behavior, the need for a complete post_id/comment_id pair, how to source missing IDs, and the semantics of parent_comment_id and reply_to_comment_id in the response. It also adds the caution against using a reply-level comment_id as input, which is valuable operational context not covered by the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded with the core purpose, and every sentence contributes either to ID resolution, pagination, or field semantics. No filler or repetitive material is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the presence of an output schema, the description covers everything needed to call it correctly: how to obtain post_id and comment_id, when to ask the user, how to page, and how to interpret reply relationships. It also proactively prevents a likely misuse with the '不要传回复项自身的 comment_id' instruction.

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 three parameters in detail. The description adds meaningful clarification that comment_id must be a first-level comment, not a reply's own comment_id, and reinforces the pagination flow with page_token. It does not fully duplicate the schema and contributes extra semantic guidance.

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 states a specific verb and resource: '根据 TikTok 作品 post_id 和一级评论 comment_id 获取回复' (get replies for a first-level comment on a TikTok post). It explicitly distinguishes itself from the first-level comment tools by using '一级评论' and describing reply retrieval, clearly separating it from sibling tools like tiktok_get_post_comments_by_post_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 gives explicit routing instructions: use directly when a valid ID pair exists, call the corresponding first-level comment tool when IDs are missing, and ask the user when post locating information is absent. It also warns not to pass the reply item's own comment_id, providing clear when-to-use and 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.

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

Annotations already provide readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds scoping to first-level comments and pagination support, but these are also largely reflected in the schema. 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, front-loaded sentence that communicates the action, the key identifier, the result scope, and pagination. Every phrase earns its place with no redundant filler.

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 rich input schema descriptions, an output schema, and relevant annotations, the description covers the core behavior. A small gap remains: it does not explicitly address how this tool relates to URL-based or reply-based comment tools, though the name and '一级评论' hint at it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already provides detailed semantics for post_id and page_token, including how to obtain post_id and how to handle next_page_token. The description only restates these parameter names without adding information beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: '获取一级评论' (get first-level comments) by TikTok post_id, and mentions pagination via page_token. The term '一级评论' distinguishes it from sibling tiktok_get_post_comment_replies, and 'post_id' distinguishes it from URL-based comment tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: use this when you have a TikTok post_id and need top-level comments. However, the description does not explicitly state when to choose this over tiktok_get_post_comments_by_url or tiktok_get_post_comment_replies, nor does it name alternatives.

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

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

annotations 已声明 readOnlyHint=true，因此安全性方面由结构化信息覆盖。描述额外补充了“支持 page_token 翻页”和“只返回一级评论”的行为，但没有进一步说明结果数量限制、无评论时的行为等；在已有 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?

描述只有一句话，但完整包含了动作、资源、范围和分页能力，信息密度高且前置了核心用途。没有任何冗余或重复 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?

对于只有 2 个参数、有输出 schema、且已带 readOnlyHint 的只读工具，描述加上 schema 已覆盖调用所需的全部关键信息：URL 来源、一级评论范围、分页令牌规则。没有明显缺失的调用要素。

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 描述覆盖率 100%，url 和 page_token 的语义都已在 input schema 中详细说明，尤其是 page_token 的不透明令牌规则。工具描述本身只重复了翻页能力，未在 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?

描述使用具体的动词“获取”、明确的资源“TikTok 作品页面链接”和范围“一级评论”，清楚说明工具做什么。与 tiktok_get_post_comments_by_post_id 和 tiktok_get_post_comment_replies 相比，按 URL 和一级评论的表述足以区分，不需要打开 schema 即可判断。

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?

描述给出了使用场景：有 TikTok 作品页面链接且需要一级评论时使用，并提供翻页能力。但它没有明确说明与替代工具的边界，例如需要评论回复时应改用 tiktok_get_post_comment_replies，或者已有 post ID 时应改用 tiktok_get_post_comments_by_post_id；这些区分只能从工具名和“一级评论”中推断。

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds that both video and photo posts are supported, but it does not disclose further behavioral traits such as rate limits, authentication needs, or failure behavior. It does not contradict 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 one efficient, front-loaded sentence with no redundant wording. It conveys the verb, resource, and supported content types in minimal space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only lookup with a rich input schema, existing annotations, and an output schema, the description is complete enough for an agent to select and invoke the tool correctly. No critical information needed for basic use is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% parameter description coverage, including examples and an explicit instruction not to pass post_id instead of url. The tool description only restates that the lookup is URL-based and adds no extra semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('获取') and a specific resource (TikTok 作品详情), and explicitly scopes the tool to video and photo post URLs. This makes it easy to distinguish from sibling tools that fetch comments, user info, or post lists.

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 intended use is implied: use this when you have a TikTok post page URL and need post details. However, the description does not explicitly say when to prefer this over siblings like tiktok_get_post_comments_by_url or tiktok_get_user_info_by_profile_url, nor does it mention exclusion criteria.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so no safety contradiction exists. The description adds the '公开资料' (public data) scope, which somewhat clarifies behavior, but it does not disclose details such as rate limits, required authentication, or response shape. Given the annotations cover the core safety profile, this is adequate but not rich.

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 short sentence with no filler, front-loading the core purpose and input requirement. For a single-parameter read-only tool, this length is appropriately concise and every word contributes 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?

The tool has one required parameter, an output schema, and annotations indicating read-only/open-world behavior, so the description does not need to explain return values. The description is sufficient for a simple public-profile lookup, though it could slightly strengthen usage guidance by naming the sibling alternative for ID-based lookups.

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 describes profile_url with 100% coverage and includes an example link. The tool description merely refers to 'TikTok 用户主页链接', adding no new parameter meaning beyond what the schema provides. Thus the 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 uses a clear verb ('获取', 'get'), a clear resource ('用户公开资料', 'user public profile'), and specifies the input mechanism ('根据 TikTok 用户主页链接'). This directly distinguishes the tool from siblings like tiktok_get_user_info_by_tiktok_id, which operate on a TikTok ID rather than a profile URL.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when a TikTok user profile URL is available, but it does not explicitly state when to use it over alternatives or when not to use it. No guidance is given about choosing between this tool and tiktok_get_user_info_by_tiktok_id based on whether the caller has a URL or an ID.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only that the data is public ('公开资料'), but does not discuss auth needs, rate limits, or other behavioral traits. This is acceptable for a simple read-only lookup, but adds little 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, front-loaded sentence: it names the action, the resource, and the lookup key in a compact form. There is no filler, and the sentence is immediately informative.

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?

This is a one-parameter, read-only lookup with a rich parameter schema and an output schema, so the definition is mostly complete. The main gap is that the description does not explicitly route the agent to tiktok_get_user_info_by_profile_url for URL-based lookups, which is a natural alternative an agent should know about.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the parameter schema already explains tiktok_id thoroughly: it is the @ handle, where to source it, and that @/URLs should not be passed. The tool description itself adds no further parameter meaning, so the baseline 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 states a specific action (获取/retrieve), a resource (用户公开资料/public profile), and the lookup key (根据 TikTok 号/by TikTok ID). It does not explicitly contrast itself with tiktok_get_user_info_by_profile_url, but the name and the 'by TikTok ID' qualifier make the differentiation reasonably 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 implies when to use the tool: when you have a TikTok ID rather than a profile URL. However, it never names the URL-based sibling tool, and the only exclusion ('不要传用户主页链接') appears in the parameter schema, not in the tool description itself.

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

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

Annotations already cover the read-only and open-world nature of the operation, so the safety profile is clear. The description adds only that pagination via page_token is supported, which is also documented in the schema; it offers no additional context such as rate limits, data freshness, or result completeness. 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, front-loaded sentence that names the action, the resource, the input key, and the pagination behavior with no filler or redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a rich input schema, an output schema, and annotations covering read-only/open-world behavior, the core invocation context is sufficiently complete. The only meaningful gap is the absence of explicit routing to tiktok_get_user_posts_by_tiktok_id when a TikTok ID rather than a profile URL is available, but this is a minor omission for a simple list endpoint.

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%: both profile_url and page_token are already documented, with detailed handling rules for the opaque token. The description restates page_token pagination but adds no semantic 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?

The description uses a specific verb phrase ('获取作品列表' / get posts list) and identifies both the resource (TikTok user's posts) and the access path (profile URL). This clearly distinguishes it from sibling tools such as tiktok_get_user_posts_by_tiktok_id and tiktok_get_user_info_by_profile_url.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the main usage: call this tool when you have a TikTok profile URL and want that user's posts. However, it does not explicitly state when to prefer this over tiktok_get_user_posts_by_tiktok_id or other siblings, and it gives no exclusions or alternative routing guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the pagination behavior ('支持 page_token 翻页'), going beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single compact sentence that front-loads the purpose and adds the key pagination detail. There is no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With read-only annotations, an output schema, and fully documented parameters, the description plus schema is largely complete for a paginated list tool. A minor gap is the lack of explicit alternative-selection guidance, but it does not block correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already thoroughly documents tiktok_id format and page_token opaque-handling rules. The description adds no parameter-level meaning beyond naming pagination, so the baseline 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 states a specific verb and resource: '获取用户作品列表' (get user post list) by 'TikTok 号', and adds pagination behavior. It distinguishes itself from the sibling tiktok_get_user_posts_by_profile_url by identifying the input as the TikTok ID rather than a profile URL.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: use this tool when you have a TikTok ID rather than a profile URL. However, there is no explicit when-to-use/when-not-to-use guidance or named alternative, so the agent must infer selection from the tool name and description.

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

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

Beyond the readOnlyHint annotation, the description discloses long-polling behavior (up to 240 seconds) and guarantees that no reprocessing is triggered. This is valuable behavioral context that prevents duplicate submissions and sets wait expectations.

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 dense sentence front-loads the core action and resource, then packs in the key constraints: wait limit, no reprocessing, and no resubmission. No filler or redundant explanation.

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 a single well-documented parameter and an output schema present, the description covers the ID source, polling behavior, and side-effect absence. An agent has enough information to invoke the tool correctly without further inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema's job_id description already specifies valid sources and exclusions. The tool description restates this without adding new parameter-level meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete action—'查询TikTok视频口播转文字任务状态' (query speech-to-text task status)—and clearly ties it to job_id. This distinguishes it from the submit siblings and the other TikTok data-fetching tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says the tool is for continuing unfinished tasks, instructs the agent not to resubmit jobs, and points to submit-tool-returned job_id as valid input. This gives clear when-to-use and when-not-to-use guidance while naming the source tools.

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

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

Beyond the readOnlyHint=true annotation, the description discloses meaningful behavior: it returns video and image posts, filters out non-post results like user cards, and supports page_token pagination. It also warns that page tokens are opaque and must be passed back unchanged, which goes beyond the schema. Minor operational details like rate limits are absent, but the key behavioral profile is well covered.

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 compact and front-loaded with purpose, then moves to routing rules and capabilities. The long second sentence covers several distinct points without redundancy, though it could be split for readability. Every clause serves a purpose; no filler is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return-value details are already handled. The description covers when to use, when not to use, pagination rules, content_type filtering, and post-search reuse of share_url/post_id. It is fully sufficient for an agent to select and invoke this tool correctly in 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?

Schema description coverage is 100%, so the schema fully documents keyword, page_token, and content_type semantics. The description adds some contextual reinforcement (e.g., content_type filtering and page_token pagination), but most parameter meaning is already present in the schema. Baseline 3 is appropriate because the description does not significantly extend the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource pair, '搜索 TikTok 作品' (search TikTok posts), and states that it returns both video and image posts. It also differentiates itself from sibling tools by explicitly naming detail/comment tools for when a link or post_id is already available.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is explicitly conditioned: use when the user needs to find posts by a search term. It gives clear exclusions — if a post link exists, use detail or comment tools; if a post_id exists and comments are needed, use the comment-by-ID tool — and notes that no search is needed in those cases. This leaves no ambiguity about selection.

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

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

The description discloses important non-obvious behavior: the call waits up to 240 seconds and returns a job_id plus next-step query action if the job is not complete. This is useful beyond the annotations, though it does not detail success-path behavior or error conditions.

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 compact sentence carries the essential information: input identifier, wait limit, and non-blocking fallback with job_id. No filler or redundant repetition of schema details.

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 one-parameter submit tool with 100% schema coverage and an output schema, the description covers the key operational facts. It could be more complete by naming the polling sibling tiktok_get_video_speech_text_job or the URL submission alternative, but 'next query action' hints at the workflow.

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 documents aweme_id, including the requirement to pass it as a string, not convert to number, and the post_id alias. The description restates the post_id reuse without adding extra parameter-level meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear action and resource: submit a speech-to-text task for a TikTok video by aweme_id, and notes that a post_id can be reused. It does not explicitly differentiate from the sibling tiktok_submit_video_speech_text_by_url, so some differentiation relies on the tool name.

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 gives clear context for when to use the tool: when you have a TikTok video aweme_id or a content_type=video post_id. It does not explicitly say when not to use it or name the URL-based alternative, stopping short of full routing guidance.

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

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

Annotations already mark readOnlyHint=false and idempotentHint=false, so the agent knows this is a mutating, non-idempotent call. The description adds valuable behavioral detail: it waits up to 240 seconds, returns a job_id if incomplete, and hints at a follow-up query. This goes beyond the annotations and helps the agent anticipate latency and response.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, dense sentence that conveys the action, the wait behavior, and the return contract. Every clause earns its place, and the most important information (submit task) is front-loaded. No extraneous 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 role as a submission action, the description covers the essential contract: what it does, how long it blocks, and what it returns. It does not name the exact query tool for later retrieval, but the sibling 'tiktok_get_video_speech_text_job' and the phrase 'next query action' provide enough context. The presence of an output schema further covers return structure, so missing details are minor.

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?

With 100% schema description coverage, the video_url parameter is already well-documented in the schema. The description does not add new meaning about the parameter (e.g., URL format validation or required patterns). It stays at the baseline of 3 because the schema handles parameter explanation sufficiently.

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 (submit a speech-to-text task for a TikTok video), the resource (TikTok video via URL), and key behavior (waits up to 240 seconds, returns job_id). It distinguishes from the sibling by URL vs aweme_id through the tool name, and no ambiguity remains.

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 (submit a video transcription task by URL) but does not explicitly explain when to prefer this over the aweme_id variant, nor does it name the companion query tool. It mentions 'next query action' but doesn't specify the tool, making the guidance implicit rather than explicit.

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