Pauses an active uMouse meeting on a target device, exempting it from SDK disconnect checks while paused. Returns a meetingBusy event if another device already owns the global meeting session.
暂停会议（暂停期间豁免 SDK 断流裁决）。会议全局独占：另一台设备会议中时本指令被拦截（返回 meetingBusy 事件的 owner）。结果异步经 meetingCreated/meetingDestroyed 事件上报。
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | No | 目标设备 SN。单台在线可省略；多台在线必须显式指定（缺省时命令会被 SDK 拒绝）。识别超时的临时身份（usb-xxxx / ble-<mac>）仅本次连接会话内稳定，不要持久化。 |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden and discloses several non-obvious behaviors: pause exempts the session from SDK disconnect adjudication, the meeting is globally exclusive, interception returns a meetingBusy owner, and results are asynchronous via events. It does not mention permissions, idempotency, or what pause does to existing media streams.
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 the main action, then adds the important exclusivity and async-result details in a few dense clauses. There is no 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?
Given a complex stateful meeting operation with no annotations and no output schema, the description covers the critical operational constraints and async reporting behavior. It could be clearer about how pause results are confirmed, since meetingCreated/meetingDestroyed are lifecycle events rather than obviously pause-specific.
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 schema already has 100% description coverage for device_id, including when it can be omitted and the instability of temporary identifiers. The description does not add further parameter guidance, so 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 names a specific verb and resource: pausing a meeting (暂停会议). This is clearly distinguishable from the sibling meeting tools such as umouse_meeting_create, umouse_meeting_destroy, and umouse_meeting_resume.
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 explains a key context: a meeting is globally exclusive, and the command is intercepted if another device owns the meeting. However, it does not explicitly state when to prefer pause over destroy or resume, or give explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.