mc_watch

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

With no annotations provided, the description carries the full behavioral burden and succeeds: it discloses the auto-mount/auto-unmount lifecycle, full-session runtime, event queue writes on wake, MCP log notifications being hints only, and the fact that MCP cannot push messages into the agent's context. It also lists default wake conditions and notes that log archives include non-queued events like teleports and item pickups.

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 dense but front-loads the core purpose and an important operational warning. Every major sentence adds information, though the action-mode details appear after the behavioral overview rather than at the very top.

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 tool with no output schema and no annotations, the description covers lifecycle, wake behavior, queue semantics, notification limitations, and configuration routing. It does not describe the exact return shape of status or log, but it provides enough context to call the tool correctly.

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 the schema already documents `action` and `reason`; baseline would be 3. The description still adds meaning beyond the schema by explaining that status shows status/config and that log includes non-queue events such as teleports and pickups, which clarifies the action semantics.

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 opens with the specific resource and control concept ('看门狗控制') and immediately enumerates the action modes: status, arm, disarm, log. It also distinguishes related siblings by name, explicitly routing event retrieval to `mc_events` and tuning to `mc_config`.

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 gives explicit action-level guidance: status is the default and shows status/config, arm manually mounts, disarm closes, log shows recent event archive. Critically, it explains the pull model and tells the agent to actively use `mc_events` to receive wake events, with `mc_config` for adjusting wake conditions.

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