Skip to main content
Glama
DevinChen2014

SocialDataX 小红书 Xiaohongshu XHS RedNote MCP

by DevinChen2014
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

xhs_get_video_speech_text_job

Read-only

Check the status of a video speech-to-text job by job_id. Resume unfinished transcription tasks by polling up to 240 seconds without reprocessing or submitting duplicates.

Instructions

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

Input Schema

NameRequiredDescriptionDefault
job_idYes口播转文字任务 ID；用户已提供时直接使用，否则使用提交工具返回的 job_id；不要传 note_id 或笔记链接。

Output Schema

NameRequiredDescriptionDefault
errorYes失败或过期时的稳定错误结构；非终态或成功时为 null。
job_idYes任务 ID。
statusYes任务状态。
messageYes面向用户/AI 的状态说明。
platformYes任务所属平台。
source_idYes任务来源 ID。
content_idYes平台内容 ID。
transcriptYes成功时的口播转文字结果；非终态或失败时为 null。
is_terminalYes是否已终态。
next_actionYes非终态时建议的下一步查询动作。
content_metaYes作品上下文信息，便于结合转写内容做口播分析。
content_typeYes内容类型。
next_poll_after_secondsYes建议下次查询前等待的秒数；非终态时可用。

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.6
    • changedInput schema / properties / job_id / description
      Previous value: -"口播转文字任务 ID。"New value: +"口播转文字任务 ID；用户已提供时直接使用，否则使用提交工具返回的 job_id；不要传 note_id 或笔记链接。"
    • removedInput schema / properties / wait_seconds
      Removed value: -{
-  "default": 0,
-  "description": "可选长轮询等待秒数；0 表示只查询一次，最大 240 秒。",
-  "maximum": 240,
-  "minimum": 0,
-  "type": "integer"
-}
  2. First observedv0.1.5

TDQS

A4.1/5.0
Behavior4/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses the blocking wait behavior ('每次最多等待 240 秒' - wait up to 240 seconds each time) and the idempotency traits (no re-processing, no re-submission). These are valuable behavioral details not captured by annotations. It does not describe what happens on timeout, but the output schema covers return structure.

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

Conciseness4/5

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

The description is a single, well-structured sentence that front-loads the primary action and then adds usage, timeout, and exclusion guidance. It is dense but not verbose, with every clause earning its place. A 4 reflects that it is efficient while slightly dense; could be split for readability but is far from under-specified.

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

Completeness4/5

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

Given there is an output schema, the description adequately covers the essential operational context: when to use, the blocking wait, and explicit prohibitions against resubmission and re-processing. It implies repeated calls are allowed ('每次最多等待' - each time). No critical information for correct invocation is missing, making it complete enough.

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?

The input schema has 100% coverage and already thoroughly explains the job_id parameter, including instructions on sourcing it from the user or submission tool and not passing note_id. The description essentially repeats this without adding new semantics. Baseline 3 is correct 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.

Purpose5/5

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

The description clearly states the action: '查询任务状态' (query task status) for a specific resource, the job_id. It explicitly mentions it is used to continue unfinished tasks, which distinguishes it from the sibling submission tools (e.g., xhs_submit_video_speech_text_by_note_id). The purpose is unambiguous and specific.

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

Usage Guidelines4/5

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

The description provides clear when-to-use context: '用于继续未完成任务' (used to continue unfinished tasks). It also gives exclusions: '不要重复提交任务' (do not resubmit tasks) and '不触发重处理' (do not trigger re-processing), implicitly steering the agent away from the submission siblings. However, it does not explicitly name the alternative submission tools, so a 4 is appropriate rather than 5.

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

Deploy Server

Other Tools