Capture transient Toast or overlay events while executing a UI click or no action, with optional selector and regex filter.
执行动作同时捕获瞬时 Toast/弹层（Monitor 接线；action=click 可带 selector；expect 为正则过滤）
| Name | Required | Description | Default |
|---|---|---|---|
| pkg | No | ||
| action | No | click | |
| expect | No | text/desc 命中正则，缺省收全部瞬态 | |
| timeout | No | ||
| selector | No |
Changes observed during successful MCP inspections.
v0.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It hints at 'Monitor 接线' (Monitor wiring) but never explains what is returned, how captured popups are surfaced, what happens on timeout, or any side effects of the click action. This is a significant gap for an action-performing 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?
A single dense sentence with the core purpose front-loaded, followed by parenthetical parameter hints. No wasted words, though the packed parentheticals slightly reduce readability.
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 annotations, no output schema, and 5 parameters at 20% coverage, the description is too thin. It omits the meaning of pkg and timeout, the return shape, and any behavioral guarantees, leaving an agent under-informed for correct invocation.
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 only 20% (only 'expect' is documented), so the description must compensate. It usefully clarifies that action=click can carry a selector and that expect acts as a regex filter, covering three of five params. However, 'pkg' and 'timeout' receive no explanation in either the schema or the description.
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 and resource: execute an action while capturing transient Toast/popup layers. This distinguishes it reasonably from siblings like events.snapshot, events.tail, and events.wait, which deal with ongoing event streams rather than transient UI popups. It is clear but does not explicitly name which sibling it replaces.
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?
No explicit when-to-use or when-not-to-use guidance, and no alternatives are named despite many closely related siblings (events.wait, events.tail, ui.wait_for). Usage must be inferred from the parenthetical hints about action=click and the expect regex.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.