watch_stability

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

With no annotations, the description carries the full disclosure burden. It does surface one real behavioral trait — that once stability is reached the tool automatically prompts the user to reproduce — which is useful and non-obvious. But it omits whether configuration persists, whether omitted fields stay unchanged, whether concurrent watches are supported, and whether deviceId must be connected; for a stateful watcher plus config mutation that is a large gap.

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 sentence with the resource first and the configurable knobs parenthesized, so the key information is front-loaded. It is not padded, though the parenthetical packs two ideas (fields and side effect) that would read better split.

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?

Three parameters at 0% schema description coverage, no annotations, and no output schema, so the description is the only source of truth. It covers intent and the auto-prompt side effect but leaves the required deviceId, defaults, return shape (current config vs. ack), and lifecycle of the watch unexplained.

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 0%, so the description must compensate. It does gloss 'auto 开关' and '静默窗口秒数' onto the auto and stableSeconds params, which adds meaning the schema lacks. But the required deviceId is never mentioned, and the 3–120 second bounds, defaults, and the semantics of omitting a field are unexplained.

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 the resource (会话稳定判定) and the controllable knobs (auto, silent-window seconds), so an agent knows roughly what domain the tool covers. However, it presents itself as both 查看 and 配置 without saying how a read call differs from a write call, and '会话稳定判定' is a fuzzy construct. Nothing distinguishes it from siblings like prompt_reproduce, even though the auto-prompt behavior it mentions overlaps with that tool.

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 statement of when to call this versus alternatives, no prerequisites, and no note on the relationship to sibling prompt_reproduce despite the explicit mention of auto-prompting the user to reproduce. It reads as a status/config blurb rather than routing guidance.

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