Retrieve live session details, including AI summaries and full transcripts, by topic ID and live ID for reviewing or analyzing recorded broadcasts.
获取直播详情，包含 AI 摘要（post_summary）和完整原文转写（post_media_text）。需要 topic.live.read scope。
| Name | Required | Description | Default |
|---|---|---|---|
| live_id | Yes | 直播 ID（来自 list_topic_lives 的 live_id，优先按字符串原样传入） | |
| topic_id | Yes | 知识库 ID（来自 list_topics 的 topic_id 字段） |
Changes observed during successful MCP inspections.
v1.10.1Input schema / properties / live_id / descriptionPrevious value: -"直播 ID（来自 list_topic_lives 的 live_id 字段）"New value: +"直播 ID（来自 list_topic_lives 的 live_id，优先按字符串原样传入）"Input schema / properties / live_id / typePrevious value: -"number"New value: +[
+ "string",
+ "number"
+]Input schema / properties / topic_id / descriptionPrevious value: -"知识库 ID（alias id）"New value: +"知识库 ID（来自 list_topics 的 topic_id 字段）"v1.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose the two key return components (post_summary, post_media_text) and the required topic.live.read scope, which is real added value. It says nothing about response size, whether a transcript can be truncated or missing, or what happens when the scope is absent — meaningful gaps for a read that can return full transcripts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler: the first scopes the content, the second states the auth prerequisite. Nothing is wasted, though the second sentence could be merged or placed after the content description for slightly better flow.
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 two-parameter read with no output schema, the description adequately covers what comes back (summary + transcript) and the permission needed. The remaining gap is minor: no note on transcript availability or size, which matters for a tool returning full text.
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 both parameter descriptions already state provenance and expected type, so the schema does the heavy lifting and the baseline of 3 applies. The description adds no parameter-level meaning — the field names it mentions (post_summary, post_media_text) are return values, not inputs.
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+resource ('获取直播详情') and enumerates the payload (AI summary + full transcript), so an agent knows exactly what it retrieves. It does not explicitly distinguish itself from the sibling list_topic_lives, leaving that separation implicit.
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 only implied: 'detail' versus the sibling 'list' suggests this is the second-step fetch after enumerating lives. There is no explicit when-to-use, no exclusions, and no stated precondition such as needing a live_id obtained from list_topic_lives (that hint lives only in the schema).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.