SocialDataX TikTok MCP

tiktok_get_video_speech_text_job

Read-only

根据用户提供的有效 job_id，或 submit 工具返回的 job_id 查询 TikTok 视频口播转文字任务状态；用于继续未完成任务，每次最多等待 240 秒，不触发重处理，也不要重复提交任务。

Input Schema

TableJSON Schema

Name	Required	Description	Default
`job_id`	Yes	口播转文字任务 ID；用户已提供时直接使用，否则使用 tiktok_submit_video_speech_text_by_url 或 tiktok_submit_video_speech_text_by_aweme_id 返回的 job_id；不要传 post_id、aweme_id 或视频链接。

Output Schema

TableJSON Schema

Name	Required	Description
`error`	Yes	失败或过期时的稳定错误结构；非终态或成功时为 null。
`job_id`	Yes	任务 ID。
`status`	Yes	任务状态。
`message`	Yes	面向用户/AI 的状态说明。
`platform`	Yes	任务所属平台。
`source_id`	Yes	任务来源 ID。
`content_id`	Yes	平台内容 ID。
`transcript`	Yes	成功时的口播转文字结果；非终态或失败时为 null。
`is_terminal`	Yes	是否已终态。
`next_action`	Yes	非终态时建议的下一步查询动作。
`content_meta`	Yes	作品上下文信息，便于结合转写内容做口播分析。
`content_type`	Yes	内容类型。
`next_poll_after_seconds`	Yes	建议下次查询前等待的秒数；非终态时可用。

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All SocialDataX TikTok MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, though several are pairs differentiated only by input type (URL vs ID) such as get_post_comments_by_url/by_post_id and get_user_info_by_profile_url/by_tiktok_id. These pairs are described clearly so an agent can tell them apart, but the similarity could cause occasional misselection.

Naming Consistency4/5

The naming generally follows a consistent pattern of tiktok_ + verb + resource + explicit by_* suffix, with clear verbs like get, search, and submit. However, the socialdatax_get_points_balance tool breaks the 'tiktok_' prefix convention, and the speech text tools mix 'job' and 'by_' in less uniform ways, creating minor inconsistencies.

Tool Count5/5

With 13 tools, the server covers a comprehensive set of TikTok data operations (user info, posts, comments, replies, search, speech transcription, and account balance) without becoming unwieldy. Each tool serves a distinct need, and the count is well within the ideal range for a focused API integration.

Completeness4/5

The tool surface covers major workflows like fetching user info, posts, comments, replies, searching, and handling speech-to-text jobs. The primary gap is the lack of a get_post_detail_by_post_id tool when post_id is available, which would complement the existing comment and search tools and could be needed for direct post lookups.

Resources

Need Help?