Waits up to 25 seconds for a voice session result, clearly reporting pending vs. final text and stop reason so callers can continue in rounds.
等待语音会话结果（有界等待，单次 ≤25s；更久以分轮续等）。pending 与终态明确区分；终态返回最终文字 text、结束原因 stopReason、会议关麦确认与音频段边界事实。仅返回 agent-reply 会话的文字。
| Name | Required | Description | Default |
|---|---|---|---|
| wait_ms | No | 本次等待毫秒数 | |
| session_id | Yes | umouse_voice_start 返回的会话 ID |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It usefully discloses bounded wait behavior, pending versus terminal state distinction, terminal return fields (text, stopReason, mute confirmation, audio segment boundary facts), and that only agent-reply session text is returned. It does not explicitly state side-effect or ack semantics, but it is substantially transparent for a wait tool.
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 purpose front-loaded and supporting details packed into parentheses and semicolons. It is dense but contains no filler, with only a minor readability cost from packing many facts together.
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 no output schema and no annotations, the description still explains terminal return values and wait-state behavior well enough to invoke the tool correctly. It could be more complete by describing the pending response shape and how this tool relates to ack/inbox/wait_voice siblings.
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 session_id and wait_ms are already documented in the schema. The description reinforces the ≤25s bound and adds a useful agent-reply-only restriction relevant to choosing session_id, but does not add meaningfully more about wait_ms beyond what the schema already says.
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?
States a specific verb-resource pair: wait for a voice session result, with bounded wait semantics. It is clear on its own, but it does not distinguish itself from the very similarly named sibling umouse_wait_voice, so it falls short of a 5.
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 says waits are bounded to ≤25s and that longer waits should use multiple rounds, which implies usage after a voice session exists. However, it never explicitly says when to use this tool versus umouse_wait_voice, umouse_voice_status, or umouse_voice_inbox, nor does it mention prerequisites or ack lifecycle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.